WordPress 3 (or 4) Multi-Site Installation, on Shared Hosting, Even with Existing Web Sites

You will need (well, okay, I urge you to get) a new domain name to run WordPress next to your web site; currently .info domains are very inexpensive. This new domain name should point to your /public_html. For example, if an error in a theme prevents your site from displaying, you would really want the WordPress Admin pages working properly, using the default WordPress theme.

If you are doing like I recommend, Move your existing primary domain name so instead of pointing to /public_html it is an add-on domain. (Have your host’s technical support modify the DNS settings. They can put a place-holder domain name, if needed temporarily, for your Primary Domain for your account.)

Wildcard DNS is another change, see below. Unfortunately, you may not be able to do this until these DNS changes have taken effect. If you do this before other DNS changes, you will likely have to delete the wildcard subdomain, and re-install it.

If you have a blog using a recent earlier version of WordPress, use the Tools, Export feature to make a file with your WordPress database that can easily be brought into the new WordPress. (There are also importing tools for bringing in posts from other blog software.)

Note for Version 3.0: There is a glitch with Category and Tag imports. I had, for example, a Tag “Internet Marketing” and a Category “Internet Marketing”. These had different internal names: the Tag slug was “internet-marketing”, and the Category slug was “internetmktg”. When importing, “oops, internet-marketing is taken, oops, internet-marketing-2 is taken, ah internet-marketing-3 is free. The Categories became “internet-marketing-2”, “internet-marketing-3”, “internet-marketing-4”, etc., all with the name “Internet Marketing”.

Try changing the Category Names to be UNIQUE, including unique to the Tags you have, before you export, while still being descriptive for search engines (perhaps abbreviate the tag/category you use least). Then you can change the Category Name to look better, after importing.

If you need it, there are WordPress plug-ins for helping rename categories and tags.

The multi-site feature expect a URL like domain.com (or domain.info, domain.us, etc) or any subdomain.domain.com, but Not with any domain.com/subdirectory. (Updated, Older versions didn’t allow subdomain installation.)

Blogs will be addressed with URLs like programming.domain.com, opera.domain.com, basketball.domain.com or they can be Mapped to other “Networks” that you define, like programming.otherdomain.com, opera.thirddomain.com and basketball.otherdomain.com. [I’m not mentioning setup of “subfolder mode”, only “subdirectory mode” of WordPress. Subfolder mode works great, but I’m only giving examples in a few places.]

You have to be able to access WordPress from the Internet, even if you are using WordPress to manage blogs for other domains. Having only a “place-holder name” for the Primary Domain for the account, won’t work. (If you have a place-holder for the primary domain, you can Park your new WordPress domain, through CPanel, and that will work.)

There may be a way to have a way to make .htaccess redirects to a folder work while having the multiple-site subdomains work, but I haven’t seen it documented anywhere. Don’t try; just install WordPress in /public_html, with its own new domain name. (Update: you can now install WordPress in the root of your account, /public_html, or the root of a subdomain or Add-on domain.)

(Obsolete, Subdomains or Add-on Domains work) Note: If you try installing WordPress in a subdomain, e.g. wordpress.mydomain.com, you will get errors like “Warning! Problem updating http://opera.wordpress.mydomain.com. Your server may not be able to connect to sites running on it. Error message: Couldn’t resolve host ‘opera.wordpress.mydomain.com’”.

Do not move the folders for any add-on domains, subdomains, or for your FTP users, as these must be in /public_html. (Make a list, from CPanel: Addon Domains, Subdomain, and FTP Manager.) Also leave folders that are not part of your main site (for example, if you have a folder where you are just backing up some files).

You may have to copy/move the files yourself (some hosting companies will move the files for you, some won’t). FileZilla, a very popular, free, cross-platform (Windows, OS-X, Linux) FTP program, lets you move files between folders on the server, with simply drag-and-drop, without having to download/delete-from-server/upload.

If your site isn’t busy (can be down a few minutes without much disruption to visitors), move the files. Moving them is quicker, more reliable, easier than copying. (You don’t have to worry about dropped connections interrupting a copy, and then having to verify all files copied.) Moving also should leave file dates unchanged, unlike uploading which changes dates to the upload date. So, after creating your add-on domain, move the folders for your web site to the add-on domain’s folder. Then you can copy the folders to your computer and upload them to the old locations, so they are found if needed in the old location.

Note: If your site is getting visitors, so having it be down for a while (from a few minutes, to rarely up to 3 days) won’t be acceptable, copy your files to the add-on folder, instead of moving them. Copying them to your computer and uploading them to the new folder lets your site function while the DNS changes are propagating through the Internet.

Leave the files in the original location for several days, to make sure all users are accessing the new location, and then delete them from /public_html.

Move or copy the folders and files from /public_html to the add-on domain’s folder (for example, I moved www.lernerconsult.com from /public_html to /public_html/lernerconsulting ).

After you’ve moved /public_html/cgi-bin/ you should make a new cgi-bin folder in /public_html (it’s likely expected to be there.)

Don’t move these files:

• .htaccess since most of the settings in it belong in /public_html. You can move the lines that are specific to your add-on domain (e.g. “Redirect Permanent” lines) into a .htaccess file in the add-on folder.
• Custom error pages. Usually there will be a 404.php (could be 404.html), and maybe also 300.php, 400.php, 401.php, 403.php, 406.php, 410.php, and 500.php). Copy these instead of moving them.

Once your existing domain name is pointing to the add-on domain, test that your web site is working.

• Copy a test web page to the new location, with a unique name (any name that isn’t in the old location, such as test.html), so you can verify the DNS change to the new location, has spread through the Internet. Keep occasionally trying the test.html until you see it display (it may take up to two days for the changes to spread).
• You should check that all scripts work, and all files that are Included show on your pages (for example, your site menu, or footer, or Twitter script). Unfortunately, many scripts reference specific server locations, instead of locations relative to the Site Root; those scripts would need to have the file locations adjusted, usually in a configuration file.

Don’t delete files from /public_html until your site is working normally, from the new location, or visitors will get errors about “missing” files.

Don’t set up wildcards for your subdomains, even though it appears you could. A sub-sub-domain maps to /public_html (sanfrancisco.california.mydomain.com maps to /public_html/sanfrancisco, not to /public_html/california/sanfrancisco, so simply make sanfrancisco.mydomain.com). Other software can use this; WordPress doesn’t.

Make wildcard entries by going to Subdomains in CPanel, and enter * (asterisk) for the subdomain name. (If you don’t use CPanel, then in the DNS area of your web hosting account, add a subdomain with a value of *)

Then give it a few minutes for the change to make it’s way through your host’s servers. Test it works, by uploading a simple test html file to /public_html, and browsing to a made-up subdomain (one that has not actually been defined), for example asdf.yourdomain.com/test.html.

If you get an error message when you try browsing to the made-up subdomain, such as “Oops! Firefox could not find asdf.lernerconsult.com“, then the wildcard DNS change hasn’t reached your host’s other servers yet.

Note: when I changed my “primary domain” on my hosting account, all my subdomain entries had to be re-done, including the wildcard subdomains. Delete the subdomain entries (doesn’t delete the files, just the pointer) using Subdomains in CPanel, and re-create them. You won’t be able to delete “subdomains” that are for your add-on domains, even though they show here.

Note: Some web hosting companies don’t have CPanel set up to allow Wildcard DNS through the Subdomains page. Those companies will require changes made manually, by technical support. One page that explains how to do it is http://ma.tt/2003/10/wildcard-dns-and-sub-domains/

Other hosting companies won’t allow wildcard DNS at all. Switch to another host, if you want multiple blogs. LunarPages is great, SiteGround is excellent, and has technical support that knows WordPress even at the level of troubleshooting plugin issues.

If you are on a VPS or dedicated account, you also need a wildcard record in the vhost entry for that web account. This is in the etc/conf/httpd/httpd.conf file in Apache: ServerAlias *.yourdomain.com.

Turn on PHP5 using CPanel, PHP, or by editing your your /public_html/.htaccess (notice the leading period in that file name). Copy this text (the lines wrap, 2 lines, starting with AddHandler and with AddType):
AddHandler application/x-httpd-php5 .php5 .php4 .php .php3 .php2 .phtml
AddType application/x-httpd-php5 .php5 .php4 .php .php3 .php2 .phtml

Edit your /public_html/wp-config.php file, adding this line:

define('WP_ALLOW_MULTISITE', true);

The recommended place is above the line: /* That's all, stop editing! Happy blogging. */ You will now see additional menu items.

Give the domain name that is mapped to your /public_html, without “http://www” (e.g. lernerconsulting.info).

Path to current site is /

Edit your .htaccess and wp-config.php files as WordPress instructs you to.

• WordPress MU Domain Mapping: Essential. Map any blog on a WordPress MU website to another domain. By Donncha O Caoimh.

Other Multi-Site plugins I’m using:

• (Obsolete, hasn’t been updated, do not use ancient plugins) Multipost MU: Allow a WordPress multi-site administrator to duplicate individual posts or pages to multiple blogs at once. Gives checkboxes on your edit screen, specifying which other blogs to publish on.
• WPMU Global Search: Adds the ability to search through blogs into your WordPress 3 installation.
• YD WPMU Site-wide options: Makes selected WPMU plugin settings site-wide. Change to a setting of your main blog can now be automatically replicated to all blogs. Centralized management of your plugin options. Try it, see if it’s helpful or not for you. There are a bewildering number of options, displayed with their WordPress-Internal names (not what the plug-ins would display on screen), so you likely will not know what some of these are for…

Install the plugin in the usual way into the regular WordPress plugins folder. (My Sites, Network Admin, Dashboard, then Plugins, Add New. Search Term: domain mapping. Find “WordPress MU Domain Mapping”, in the description it will say “By Donncha O Caoimh.” Click “Install Now”.

Move sunrise.php from /public_html/wp-content/plugins/wordpress-mu-domain-mapping to /public_html/wp-content/ . (If there is a sunrise.php there already, from another plugin, you’ll just have to merge them as best you can.)

Edit /public_html/wp-config.php and uncomment or add the SUNRISE definition line. If it does not exist please ensure it’s on the line above the last “require_once” command.
define( 'SUNRISE', 'on' );

Move domain_mapping.php from /public_html/wp-content/plugins/wordpress-mu-domain-mapping/ to /public_html/wp-content/mu-plugins/ (create that folder if needed). [Note: The plugin’s readme.txt says to ignore this instruction in the Domain Mapping Tutorial written by a user, but I did and it is working.]

Note: Moving domain_mapping.php means that in Plugins, Installed Plugins, you will not find the plugin in the main plugins list, which is good; you don’t want to ever disable it. Click “Must-Use” at the top of the screen to see it.

Note: The plugin readme.txt talks about setting ANAME and CNAME records.

If you are installing on your own server, having to configure your own DNS, follow these instructions (or the more detailed instructions in the OttoPress link).

If you are installing on a shared hosting account, most shared hosting providers don’t give you access to setting ANAME or CNAME records; your hosting provider will do it for you, or you do the equivalent by going into CPanel and Add-On Domains.

In the Domain Mapping Configuration section of the screen, set the Server CNAME domain to the domain pointing to your /public_html, without leading http://www. (for example, lernerconsulting.info). Or, instead of the CNAME, set the Server IP Address or IP addresses (comma deliminated) of your server.

In the Domain Options section, I have Permanent redirect checked, User domain mapping page checked, and others unchecked.