I've tried researching this dozens of ways, and I've found posts that address pieces of what I'd like to do, but not the whole thing. I tried posting this on the Drupal forums as well, but my post hasn't shown up yet. I'm pretty new to Drupal and am afraid of corrupting my current site in the process.
Current setup:
I have a primary domain with several addon domains at HostGator
I want to convert one of my addon domains (call it addon.net) to a Drupal site
To test Drupal, I created a subdomain of addon.net (cmstest.addon.net) and used QuickInstall to set it up as a Drupal site
Current folder structure in HostGator:
/home1/[username]
cmstest.addon.net (contains Drupal files)
public_html
addon.net (contains html files)
What I'd like to accomplish:
I want to convert addon.net to a multi-instance Drupal site so I can have a test environment without having to maintain configuration and database changes in multiple places.
I don't want to lose the html files for the current addon.net site - if I have to back those up somewhere else just for reference, that's fine.
Ideally, I'd like to retain my current instance of Drupal as the main one and convert it to multi-instance, so I don't have to reconfigure everything from scratch.
If possible, I'd also like to retain the existing cmstest.addon.net domain as my test environment
I realize this is a lot of things, and I may have made things more difficult for myself by using QuickInstall rather than doing this manually. If it's much easier to start fresh with a manual install for addon.net and reapply all my changes once, that's still worth it if I can have a multi-instance setup with a test site moving forward.
Point all of the addon domains to the same folder in cPanel & then use standard Drupal multi-site installation techniques for the routing, i.e. the default domain plus individual folders and settings.php files for each of the subdomains.
Root: sites/default/settings.php
Domain: sites/example.com/settings.php
Subdomain: sites/sub.example.com/settings.php
Run the multi-site installation sharing the same core files, themes, & modules using this addressing format for the folders in /sites with unique settings.php files & MySQL databases (or table prefixes). You can also add unique /modules & /themes folders for each site if required.
Related
I'm using a multisite setup in Drupal 7. I'm wondering if it's possible to limit where a site can look for which modules to use. For example, there are a lot of modules I'd like to be able to use across all sites (../sites/all/modules/). But I would like Site A to have access to modules/custom/siteA, but not modules/custom/siteB.
Is this possible or do I have to share all modules across all sites?
You're thinking of it the wrong way; going depth first instead of breadth first. This is one of the "benefits" to going multisite.
In Drupal 7, you should be able to put any modules you want only to appear to a specific site into it's sites/site-name/modules/ directory; site-name being whatever directory you mapped the sites/sites.php file to go to for the given URL. I think you should already have a settings.php file in your sites/site-name directory. Just add the modules folder and dump them in. I'm not really sure how to handle it further, or how to install site-specific modules from the site GUI (if that's possible.)
I only put benefits in quotes because I've never been a fan of going multisite, but plenty of people have been more than happy to and it's worked out great for them.
this is quite easy. Suppose there are two sites you have created with multisite installation.
Site A (root site)
Site B
The modules that are common will be placed in sites/all/modules directory. But you can define some modules to appear in the site B only by placing the same in
sites/SiteB/modules.
I hope, it is making sense for you. Otherwise feel free to ask your queries.
All the Best!!
Goal: We have a Magento installation which contains a lot of sensitive data. We're looking to host a Wordpress installation.
Problem: Since we're installing third-party modules on Wordpress, we don't want any security issues in Wordpress to be able to compromise Magento.
I've spoken to a couple of my friends, and also had a think back to how it's been implemented in the past, but I wanted another opinion.
Since the wordpress directory will reside inside of the magento directory, would it be sufficient to chown the files inside of wordpress to a new user ("user-wp"), and then to chroot the user-wp user to the wordpress directory? Magento would then still have access to all of the Wordpress files, but not vice-versa.
Any other suggestions on how to go about implementing this would be more than appreciated! Somebody also suggested configuring a separate vhost.
Using a subdomain like blog.site.com would probably be the easiest way to set this up. All you would have to do is add a new VHost for the WordPress installation.
I don't think Chrooting would provide much security. You may also run into WordPress Plugin issues with such a configuration.
The setup is tricky. You would have to go and modify the PHP-fpm process pool and users it runs with. Then assign one pool to Magento and another to WordPress. Additionally you will also want to serve static assets & uploads from the Webserver itself.
And when you change this config you have to retest your Magento install to make sure things you didn't break anything accidentally.
Too much hassle, just use the subdomain. :)
I am confused as to how I can use Drupal to create multiple sites for a WAMP or LAMP installation.
I currently have everything setup and Drupal setup in the following directories:
/var/www/drupal-7.12
c:/wamp/www/drupal-7.12
When I access these folders from the browser I am able to modify and create content for my webpage.
It would appear to me that the default Drupal folder is the only one I can create my website in.
My question is: if I have multiple sites that I need to create with this one Drupal installation, how can I achieve it?
For example:
c:/wamp/www/mysite1
c:/wamp/www/mysite2
Thanks!
This document will explain a bit on how to run multiple sites from the same code base http://drupal.org/documentation/install/multi-site.
If your sites will share some common elements like users, this might also be helpful: http://drupal.org/node/201673
There may be more documentation written on the subject at Drupal.org, but most of what I can tell can be found in the following files. Be sure to read the comments in these files.
[Drupal Root Directory]/sites/example.sites.php
and
[Drupal Root Directory]/sites/default/default.settings.php
In general, the way Drupal 6 worked is that you needed to create subdirectories for each of your sites in the the sites directory. So that you would have a directory structure that looks like:
sites/default
sites/example-1.com
sites/example-2.com
etc.
I would imagine that D7 keeps this same structure, but I haven't yet It looks like the sites.php file provides a mapping of domain names and site directories that you can use to map. Drupal, will default to sites/default if it can't find an appropriate match.
While it's targeted toward linux, this might be a good place to find multisite info as well:
http://drupal.org/node/1114158
I am having a website redesigned. The designers plan to use Wordpress as the CMS and want a development copy to work with. Thing is, I now have Wordpress installed to run a blog (only) on a subdirectory of my current site.
Soooo...question is: Can I create a subdomain, install Wordpress on there, point it at a separate (new) schema on MySQL and have them use that for the development work? I know I can physically do this, but will anything about running the the WP install scripts on the subdomain screw up the existing production install on the main domain?
The install itself should not create any problems. Personally, I always develop WP sites in their own subdomain, allowing me to do away with the wordpress/ subdirectory.
The most significant hurdle will come when you are ready to move the development site to a new domain and/or place in the directory hierarchy. Although the theme files and their associated CSS, JS, etc., files should be using relative-path references, the database itself may contain hundreds of fully qualified URLs that reference the development domain and/or directory.
There are a number of WordPress plugins that address this problems. The one I am most familiar with is BackupBuddy from ithemes.com. (I'm not a shill, just a satisfied customer.) BB is useful both for performing scheduled backups (full or database-only), but it is also very useful during development and during deployment. There is an included script, importbuddy.php, than can not only take a .zip of a full backup and restore the site, it can also move the site from one directory and/or domain to another.
Note: BackupBuddy is not free, but it is released under GPLv2. You are paying for the support necessary to keep it tracking changes in the WP ecosystem. If you are doing any serious WP work then it is money well-spent. You might suggest this to your designers.
Yes you can do it. It doesn't matter. You can install your new blogs to any directory or subdomain (actually they're directories, too). Also you can use new MySQL databases for them, or you can use same database for your all WP installations (by editing wp-config.php manually), thereby you'll have same content for your all WP blogs.
Technically, yes you can do it.
However, if you have a live domain with public people using it, you are best not developing on either the same domain or server, because:
Mistakes happen. You can break the database or other code.
While you develop, you can affect performance of the server.
Develop on a local machine, or a completely different server, and when you are happy with it, push the code live onto the production server.
if you are planning to make a test copy of the current install on a subdomain which includes separate source code and database the answer is NO it will not affect your current installation.
I have a new client that I am converting over to Drupal from Wordpress. We have two domains with the same name but different TLDs i.e. .com & .org. We have decided to start by setting up the site first under the .com so we have a live site to play with during the development.
So we currently have a wordpress site running on the .org and drupal (on a new host) running on the .com domain.
So two questions:
Can and How do you configure Drupal to work for both the .com and the .org ?
Can and How do you change the base domain drupal is configured with after the site is live ?
If you aren't using Drupal's multisite system (that is, the site information is being put into sites/default instead of sites/example.org or sites/example.com), this is really easy: do nothing. There is no step 2. Drupal will handle any domain thrown at it: just use your web server's name-based handling to determine which domains to accept.
If you are using Drupal's multisite system, it's a little harder:
Rename the sites folder (so from sites/example.com to sites/example.org).
Drupal's files table hardcodes the files directory it uses, so you're going to need to change all the paths in it. Run UPDATE files SET filepath = REPLACE(filepath,'example.org','example.com') on the database.
The other place to change the path is under Site Configuration -> File system.
The final place you're going to need to change paths is going to be on the settings page for your theme if you decided to use a custom logo or favicon.
Once you've changed all the paths, rebuild the cache under Site Configuration -> Performance.
This should cover most cases. Check with the third-party modules you're using to see if they also hardcode filepaths. If the modules are using the API correctly, they should've been handled in steps 2 and 3.
Because of all the hardcoded file paths, I highly recommend not using multisite unless you really need to. If you are only running one site in a Drupal install, just stick the site in sites/default.