Last updated 21 April 2016. Created on 18 December 2008.
Edited by hansfn, saurabh.dhariwal, peterx, Garry Egan. Log in to edit this page.

You want site1.example.org, site2.example.org, and site3.example.org on the same server, or virtual private server, using one copy of Drupal and a separate database for each site. You are using Cpanel. The first site will take whatever time you need to upload and install Drupal. The second and subsequent sites will take 5 minutes each. This example uses Drupal 6. Drupal 7 appears to be the same.

Drupal 6 and 7

The cPanel part of this page is the same for Drupal 6 and Drupal 7. I use exactly the same procedure for Drupal 7 multisite. Please add a comment if you do find a difference for Drupal 7 or a new release of cPanel.

Contents:

First site

I assume you have the first site set up. You used WHM to create a database account for site1.example.org then went into Cpanel for site1.example.org to set up email and install Drupal. You now have site1.example.org working with Drupal 6.

When you created site1.example.org, you created a user for the account and I will assume the user is named site1. Use the MySQL Databases option or the wizard. I use the MySQL Databases option. You create a database named drupal and cpanel shows a database named site1_drupal. You create a user named drupal for the database and Cpanel displays user site1_drupal. You then connect user site1_drupal to database site1_drupal with all privileges.

You use the Cpanel Email Accounts page to create some email accounts for site1.example.org including one named boss. You will use boss (at) site1.example.org as the email address when you create the administration account during the Drupal installation.

When installing Drupal, you create directories /sites/default/ and /sites/default/files/ plus file /sites/default/settings.php. You set the permissions to 777 then run the installation step then set /sites/default/settings.php back to 644. You will repeat this step once for each new site.

Second site

Go into Cpanel on site1.example.org and park domain site2.example.org on site1.example.org. While you are there, park site3.example.org on site1.example.org. If you run into a limit on the number of parked domains, you can go back into WHM to increase the limit. You want a database per domain so while in WHM, increase the limit on the number of databases.

Create a database and database user for site2.example.org, perhaps user site2 connected to database site2. Repeat for site3.example.org with user site3 connected to database site3.

Go into Email Accounts and create boss (at) site2.example.org plus boss (at) site3.example.org.

You probably used FTP to upload Drupal 6 to site1.example.org. I will assume FTP. There is a file manager in Cpanel that does similar things to Filezilla and other FTP programs. Go into /sites/ and create directory site2.example.org. While in /sites/, create directory site3.example.org.

Create directories /sites/site2.example.org/files/ and /sites/site3.example.org/files/ with permission 777.

Copy /sites/default/default.settings.php to /sites/site2.example.org/ and rename the file to settings.php then give it permission 777. Copy /sites/default/default.settings.php to /sites/site3.example.org/ and rename the file to settings.php then give it permission 777.

Do you notice how you are repeating part of the original installation? Yeah, it gets boring if you have 2000 sites.

Visit http://site2.example.org/ and up pops the Drupal 6 installation process, exactly the same as happened with site1.example.org. Answer the same questions. Use the right database name, database user name, and password.

Visit http://site3.example.org/ and up pops the Drupal 6 installation process, exactly the same as for site1.example.org and site2.example.org.

Third site

Done! You could do ten at a time if you can keep track of all the passwords. Replace your Drupal Beginner t-shirt with the Drupal Do It In My Sleep t-shirt.

Themes

Put standard themes in /sites/all/themes/ to let every site use the themes. Site specific custom themes go in a /themes/ directory within the site, e.g., /sites/site1.example.org/themes/ for site1.

Modules

You have a separate database for every site so you can activate different modules for each site. Put the modules in /sites/all/modules/ then let each site switch them on or off.

Update notifications

Drupal automatically checks for code updates unless you turn off update notifications. You have only one copy of the code so switch off update notifications for all sites after the first.

Ok, darumaki pointed out the case where different sites use different modules. This might be fine if every site was using the same modules, however, a typical multi-site setup usually involves each site using different modules, therefore, it should not be advised to turn off updates on the other sites, because updates only checks the modules that are enabled and not all the modules in the module directory. You could turn on every single module in your base domain, to get update notifications, or you could turn on updates in just those domains with something different.

The same consideration applies to themes because theme updates are detected and notified the same as module updates. The main saving from turning off updates is when you set up 3550 identical sites for the 3550 members of a professional association. They want separate databases for client privacy but they all get the same modules and features as specified by their association.

Maintenance

You have one copy of the code so put all the sites offline before updating the code. You have a database for every site so run update.php on every site before switching the sites back online.

Which site goes first?

The first site is locked in place while any other sites are parked on top. Use a throwaway site for the first site.

When I registered petermoulding.com, I registered the .biz and some other variations for experiments. I used the .biz domain name as the base site for the multisite setup because the .biz domain name will not be visited by anyone but me. Each time I load a new theme into /sites/all/themes/, I can activate it in site1.example.org for testing. When one of the added on sites becomes too busy for the server, I can move the added on site without disturbing the other sites.

The first site is also the default site your customers will see when there is a setup failure in Drupal or Apache. Put contact information on the first site so people can report failed Web sites.

cPanel interface

Cpanel provides several themes and each theme shows different combinations of buttons. I use crimson_smoke for these screen shots.

Domains

Go to the domains section to park your new domain, site3.example.org, to your existing domain, site1.example.org. Do not use Subdomain or Addon domain for this part of the setup.

Subdomains

You add subdomains in the form x.example.com. For domain site3.example.org, you might add forums.site3.example.org and shop.site3.example.org. First you would park site3.example.org on site1.example.org and create site3.example.org in Drupal following the instructions on this page then you would look at adding forums and shop to site3.example.org. Adding subdomains should be covered in another page because there would be considerations around sharing user ids across the domains.

The following image shows the Cpanel subdomain page. You can add, edit, and delete subdomains. If you leave the document root field empty, the result will be similar to parking a domain and should let you use multisite. Multisiting forums.site3.example.org next to site3.example.org would require public_html/sites/forums.site3.example.org/settings.php, another database, and a way to share the login.

Addon domains

Addon domains are similar to parked domains but add more complications. Do not use Addon domains for the procedure in this page, use Parked domains.

The following image shows the Cpanel domain addon page. Notice the password field. Addon domains have a subaccount type arrangement you might use if you want to delegate administration to someone else. You could put several domains in one WHM account using separate subdirectories and give each site administrator separate FTP access. The separate FTP access does not work with multisite because they all share the same directories. Instead use Parked domains and control uploading of files using a Drupal module.

If you insist on using Addon domains instead of Parked domains then set Document root to public_html/. Drupal multisite is based on all page requests from all sites going to the same public_html/index.php.

Parked domains

You can park domain egjhnbhniu.com on example.com and Drupal can separate the two if they have separate multisite settings. You use Parked domains without redirection. A request for egjhnbhniu.com/food/turnip goes to public_html/index.php then Drupal looks for public_html/sites/egjhnbhniu.com/settings.php and uses the database from the settings file. If public_html/sites/egjhnbhniu.com/settings.php is missing, Drupal uses public_html/sites/defaults/settings.php and you see a page from example.com.

The following image shows the simple Cpanel domain parking page. It is simple because their are no passwords or document root settings. This is all you need for multisite.

Redirects

A redirect sends one domain to somewhere on another domain. egjhnbhniu.com could be redirected to example.com/test-sites/egjhnbhniu/. A common use is for personal Web sites. You create example.com/~george then, for your birthday, grandma buys george.com for you. You can redirect george.com to example.com/~george. When visitors visit george.com, they see example.com/~george so do not redirect, add george.com as a subdomain with a document root of ~george.

Drupal in a subdirectory

When you install Drupal in /home/example/public_html/, site3.example.org is in /home/example/public_html/sites/site3.example.org/ and you access Drupal as http://site3.example.org/. If you install Drupal in a subdirectory, for example /home/example/public_html/drupal-6.13/, you can access Drupal as http://site3.example.org/drupal-6.13/.

An alternative is to change the way you park the domain. Put /drupal-6.13 the Domain Root setting. Set Domain Root to /public_html/drupal-6.13 and access Drupal as http://site3.example.org/.

Drupal lookup documentation

There are lots of questions about the Drupal lookup sequence to get from a domain name to a settings.php file. The Drupal documentation is in INSTALL.txt under the heading MULTISITE CONFIGURATION. The following list is the lookup sequence from Drupal 6.12 INSTALL.txt for www.sub.example.com/site3.
sites/www.sub.example.com.site3/settings.php
sites/sub.example.com.site3/settings.php
sites/example.com.site3/settings.php
sites/www.sub.example.com/settings.php
sites/sub.example.com/settings.php
sites/example.com/settings.php
sites/default/settings.php

Note that Drupal will not look in sites/sub/settings.php or sites/site3/settings.php.

SSL certificates for multiple sites

See Can we add SSL certificate to an add-on domain?.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

olisb’s picture

if you are 'importing' an existing Drupal into a multisite you might find you get your multisite working but your images are not showing up, read this post: (it took me ages to work this one out!)

You probably need to update the 'files' table in your MySQL database (via PHP MyAdmin), so that the new urls look in the right place for the files.

I ran:

UPDATE `files` SET `filepath` = REPLACE(`filepath`, "sites/default/files/", "sites/SITEDOMAIN.com/files/");

Which fixed it. Hope that helps!

peterx’s picture

Good suggestion. Before you copy the stand alone example.com into a multisite, update both the stand alone site and the multisite to the same release of everything so they tables are the same format. If the copied site uses older modules, you can probably copy then run update.php to catch up. If the copied site uses newer versions of modules, the copied site might have table formats that are not compatible and update.php will not revert the table backwards.

You can also have problems where the copied example.com has modules in sites/example.com/modules that are the same as modules sites/all/modules or themes in sites/example.com/themes that are the same as themes in sites/all/themes. You want them at the same level before the copy and to delete them after the copy. The system table identifies where everything is. The example.com system table places modules and themes in sites/all. After the copy, a visit to the themes or modules administration page will update the system table. You then have problems deleting the module or theme in sites/example.com/.

If you are copying example.com out of a multisite into a stand alone server because of increased traffic, you can create the new server using example.net then copy sites/example.com as sites/example.com. example.com will then remain an add on site in a multisite but without any other site competing with traffic. You do not have to change anything in example.com because it has the same relationship to example.net as it had to the previous base site.

I think copying into a multisite and copying out of a multisite deserve their own child pages if there are any more points to cover.

taite11’s picture

"Go into /sites/ and create directory cjm.net.au." - Note that this had to be lower-case for me. I originally had some letters capitalized and it did not work.

peterx’s picture

Always a trap for people new to Linux and Unix. The common Linux file systems treat ExampleFile as a different file to examplefile. The same applies to the file part of a URL. Fortunately the standard for URLs defines domain names as not case sensitive.

When you create the domain name, keep everything as standard lower case so that directory names are lower case and the entries in the Web server config are lower case. You can publish the domain name of your URL in mixed case. The following links both work because the Internet domain handling translates to lower case.
petermoulding.com
PeterMoulding.com

When we have semantic file systems, upper case will be treated for what it really is, a presentation aspect of the file name instead of part of the file name.

parijke’s picture

Hi, I exactly followed the steps, but when i rename the default.settings.php to settings.php, going to the parked domain (ie www.seconddomain.com) ends up in a redirect loop.

I have created the parked domain with cpanel without any redirects, so it points to /public_html/

What did I do wrong?

parijke’s picture

Hi, I exactly followed the steps, but when i rename the default.settings.php to settings.php, going to the parked domain (ie www.seconddomain.com) ends up in a redirect loop.

I have created the parked domain with cpanel without any redirects, so it points to /public_html/

What did I do wrong?

peterx’s picture

If exampleb.com is parked on examplea.com and examplea.com is redirecting, you might get an error.

You might get an error if example.com redirects to www.example.com and www.example.com redirects to example.com. When you enter www.example.com, Drupal looks for sites/www.example.com then sites/example.com. example.com could then be redirecting back to www.example.com in the Web server.

Go into cPanel then Redirects. Are there any redirects set? There can be a redirect for ** All Public Domains** causing a loop.

emilianodelau’s picture

Peter, I followed your 5-minute instructions to set up Drupal multisites but I get a permission denied or a internal server error message. Any suggestions?

peterx’s picture

Permission denied on what? What were you trying to do?

Your Web hosting service might stop you performing certain actions. If your cPanel account was set up by a reseller, the reseller might not let you perform some actions. You might hit a quota limit for the number of add-on or parked domains.

If you register a domain name then try to park it immediately, the registration might not be public and you have to wait a few minutes or a few hours. .com, .net, and .org are usually instant. Some of the other registries can take overnight.

If your domain uses the domain name servers supplied by the registry, you might not be allowed to update the servers from the cPanel function. You might have to use a special DNS update page at the registry.

When you switch a domain name DNS entry to a new DNS, the new value takes a while to seep through all the DNS caches around the world. 5 minutes is typical. Sometimes it is overnight.

l_o_l’s picture

If I try to browse to the new created map + settings.php at http://firstsite.com/cms/sites/secondsite.com/
I get this reply:
Forbidden
You don't have permission to access /cms/sites/secondsite.com/ on this server

Maybe its only accessible by a linked domain and not directly ?
I did not yet link a domain name to the newly created map, because I want to move an existing domain. Therefore I must first create and fill the new website before I can transfer the domainname.

So question is: how can I setup the new website without needing to link a domain name. Or is something else wrong ?

Thank you for any light on this

peterx’s picture

Hello Gijs1, I tested http://example.com/sites/secondsite.com/ and received page not found.
I tested http://example.com/sites/secondsite.com/settings.php and received the blank page you would expect from the PHP script.

Permission problems can vary across hosting company depending on how they configure your account. I use FTP most of the time and have no problems until I try to use FTP to delete a file created by the Drupal Web site or by the cPanel file upload. Apache usually runs as nobody and files created by Drupal end up with the nobody permission. FTP runs under your administration account and can usually read but not delete files created by nobody. Files created by the cPanel file administration page have permissions that depend on the configuration of cPanel by the hosting company.

If you upload using cPanel, you can set the file permissions in the file management page. If you use FTP, use the FTP permissions options to set permissions.

zeta1600’s picture

Peter, I tried almost all the how-tos on multisite. Your Park Domain was the only one I could get to work or understand. Thanks.

I have a question. What do I need to do if the parked domain is currently under development and how would I take that live?

peterx’s picture

Do you you want other people to test the site before it goes live? Do you want a test site after the current site is live? You ongoing development testing might require a different site. The site could be another site under multisite or a separate account under WHM. Multisite creates problems when you try to test new core code. A separate site under WHM gives you the most freedom.

WHM is the parent of cPanel and gives you some DNS control. You get WHM on top of cPanel when you move up from the most basic hosting account to one that allows "reselling". The reselling part lets you create separate accounts and those accounts can be test versions. This gives you the most control and is the minimum I recommend.

Your next decision is about names. If you are building example.com, your test site could be test.example.com or example.net. You can park both on your test site. When your test site is approved to go live, you can create a new account and assign test.example.com or example.net to the new test site.

I usually have a test site for my use then a QA site where the customers can test changes then the production Web site the public can see. The Quality Assurance site is public but a completely different name. Experimental modules for http://petermoulding.com are sometimes developed on http://ka.tl. ka.tl can then be a subset of petermoulding.com requiring only whatever is needed to test code.

cPanel with multisite lets you test changes to the database and the theme but not major code changes because the code changes break both sites. Moving up to WHM gives you complete separation to test code changes. This 5 minute cPanel page applies to each account under WHM and can be used for the test account, the QA account, and the production account. Steping through all the possible combinations for onging work under WHM would take 105 minutes.

zeta1600’s picture

Peter, thanks for the thought provoking answer. I will have to do some thinking through your suggestions.

I do have whm. What I understand you saying is in whm create a test account, let say test.com. Park it in the multisite. Work on it until it's ready to go live. Then, when that site is ready, remove the parked domain, test.com and park the main domain lets say final.com. Is that right? That would be a great solution. The question running though my mind right now is, when does drupal know the site name has changed?

peterx’s picture

Each WHM account has a separate everything.

  1. Create WHM account A containing example.com.
  2. Develop and test example.com.
  3. Example.com becomes your live site.
  4. Create WHM account B containing example.net.
  5. Copy the database from example.com to example.net using backup/resore or PHPMyAdmin export then import.
  6. Example.net is now your test site.

You are not changing where the main domain points. You are not moving the database. Your first site becomes the live site. You then create a copy for testing code changes. When the code changes are complete, you reapply the code changes to the production site.

If any of your tests fail, you can delete the test account and start again. You can create as many copies as you like for different experiments. If you have several contractors working on the project, you can give them a copy each. They should only be able to change their own copy and not be able to upset the production site.

Within a WHM account, you can use the cPanel techniques used on this page.

If you did decide to replace example.com with example.net, you could remove example.com from the parked list in one account then park example.com on the other account. The change would be quick but there could be a lot of cached DNS information out on the net for 24 hours or more. What you would do is change the DNS time to live a day or two before the change, make the change, then restore the DNS time to live after the change.

zeta1600’s picture

I almost can't believe how easy this set up is. Peter, last night, even before I saw this response. I did the setup as I understood it ... and it worked perfectly!
This is what I did. I created parked test.com, configured it. Meanwhile, I have final.com as an addon domain. This created a final.com directory at public_html. I just inserted an html file as a temporary landing page.
After I finished test.com, I removed it from the park domain. I also removed final.com from addon domain, then added it as a parked domain.
Then, this is where I believe drupal recognized to connect everything... I went to sites/test.com and changed it to sites/final.com. I don't even think I changed anything else... and viola!
Thanks again for this very easy way to create multisite!!!!!! I'm FREE, I'm finally FREE!

dylanrao’s picture

If I'm migrating a drupal site from a multisite do I have to move to another multisite setup or can I go standalone?

I haven't used a multisite setup before but when I import my database over my standalone install I loose access to my entire drupal installation. That's why I'm looking at these multisite instructions. However I have 1 issue, my site is live so I can't create a multisite with my final domain.

I have a cPanel account setup for finaldomain.com but I think I have to throw that away. Would it work if I:

  1. setup my cPanel account as separatedomain.com & Installed drupal
  2. parked finaldomain.com and test.finaldomain.com on the account
  3. create sites/finaldomain.com and redirect test.finaldomain.com to that directory for attempting the migration
  4. then simply point my finaldomain.com A record to this server to go live

OR:

  1. setup my cPanel account as separatedomain.com & Installed drupal
  2. parked finaldomain.com and test.finaldomain.com on the account
  3. create sites/test.finaldomain.com for attempting the migration
  4. then simply cp test.finaldomain.com as finaldomain.com to go live
peterx’s picture

When I want examplea.com and exampleb.com on multisite, I create example.com as the default site then add examplea.com and exampleb.com as additional sites. It is then easier to move both. The new site could have examplec.com as the base site. You then move examplea.com or exampleb.com as an additional site without changing the directory structure for examplea.com or exampleb.com.

In multisite, every site has a unique database and a unique settings file to point to the database. If you move the database but not the settings file, you will lose access to the database or access the wrong database.

The system table in the database points to the location of all the modules and they have to be the same. Browse the system table to see what is stored there. One way to reduce the problem is to switch off all optional modules before the move but do not uninstall them. It is the uninstall that deletes the data. When you build the new site, you switch on the modules, Drupal reads their new location, and creates new entries in the system table.

jimbur’s picture

I had the same problem... I followed the steps identified above (many thanks, wonderful directions! ;) but resulted in the same redirect loop described. I finally found the answer on another thread and figure this is likely the cause... using the Softaculous installer for Drupal found on hosting sites using cPanel works great for your first site, but they have removed the install.php file from their package. Grab a copy from another Drupal install and place it in the root directory of your Drupal site and the redirect loop error goes away. Here is the link for more details... https://www.drupal.org/node/1093464