WordPress Multisite allows a single WordPress installation to host multiple sites – with each site running on a separate domain name (when using domain mappings). The Multisite “network” uses the same WP directory/files (including the themes and plugins within), WP database, and WP configuration file (wp-config.php).
To enable WordPress’s Multisite, or “network of sites”, follow these simple step-by-step instructions:
First, install WordPress using the parent website’s domain name, which is the domain name specified as the
ServerName in the website’s VirtualHost files. This domain name is usually not related to the sites/domains that will be part of Multisite (unless you are planning to NOT use domain mappings and are going to use sub-domains instead).
Requirements for Multisite and Domain Mappings
These are the main reasons for the dreaded “can’t enable multisite” issue people are having…
When You Cannot Create a Multisite Network
To be able to enable WordPress’s Multisite feature, the website (or more specifically its HTTP and SSL VirtualHosts) MUST be running on the standard/default ports of 80 (HTTP) and 443 (SSL). Multisite is not able to function with WordPress accessed on non-standard ports.
When You Cannot Choose a Domain-based Install
Because your install is in a directory, the sites in your WordPress network must use sub-directories.
To be able to use a different domain name for each separate network site (or to even just use sub-domains) –
Issue #1. You must install (extract) the WordPress files directly into the website’s DocumentRoot directory.
If you have installed WordPress into a sub-directory under the DocumentRoot, the domain option will NOT be available for you to select. And the same applies if the URL to your WordPress installation contains a path in it (e.g., http://www.example.com/wordpress/).
When extracting the WordPress files…
– Do NOT place the files in:
+ DO (instead) place the files in the parent “\webroot” folder:
* The above “\webroot” path is WampDeveloper Pro’s DocumentRoot structure for each new website; if you are using another WAMP on Windows, or are using Linux, update for the path difference.
Issue #2. You must not install WordPress under the domain name of “localhost” or “127.0.0.1”.
I’ve heard there are ways around this, but why mess around with it? Make up a domain name for the parent WordPress install – it does not have to be real (registered) nor even valid – you can simply resolve the domain name used back to the local system (to IP 127.0.0.1) in your system’s Hosts file with a singe line:
127.0.0.1 fictitious.domain.name1 additional.aliase additional.aliase 127.0.0.1 fictitious.domain.name2 additional.aliase additional.aliase 127.0.0.1 fictitious.domain.name3 additional.aliase additional.aliase
Enable Multisite Feature
Edit file \wp-config.php and insert line:
define( 'WP_ALLOW_MULTISITE', true );
The above configuration will enable/show the following menu items…
Navigate to: Tools > Network Setup
Make sure to select the “Sub-domains” option – as the only other choice is “Sub-directories”, which we do not want! But don’t worry, the Domain Mapping plugin will map the “Sub-domains” paradigm to full domains.
To repeat, irregardless of whether you are going to use different domain names or want the sub-domains restriction, select the “Sub-domains” option.
Re-check the "Network Details" info (the default domain name as specified above, Sites Network title, Sites Network admin email address).
Then click “Install”.
Verify that the displayed configuration additions or changes are made automatically to the wp-config.php and .htaccess files – which are located in the WordPress’s directory (and if not, just make the edits manually with a copy/paste).
Install Domain Mapping Plugin
Install the “WordPress MU Domain Mapping” plugin so you can use different domain names for your sites (otherwise you’ll only be able to create sub-domains of a base domain name).
Update ServerAlias in Website’s VirtualHost Files
Open the website’s HTTP and SSL VirtualHost files, and add your list (space separated) of Multisite-hosted domain names into the ServerAlias directive. And make sure that any ServerAlias-to-ServerName redirects are commented-out (otherwise all the sites will redirect to the parent website’s domain name).
If you do not have a specific list of all the sites’ domain names, you can use a star (
*) as the ServerAlias value to assign all domain names to this VirtualHost. Just note that if you do this, this will effectively hide all additional VirtualHosts created in the future (as they will not be reachable).
Update Domain Names’ DNS Records
Don’t forget to do this!
If you are publicly hosting these sites (e.g., this is not a local development box), you’ll need to make sure to set up the proper DNS records (using the domain name Registrar’s Control Panel), so requests using these domain names are able to reach the server.
1. [Sites] If the parent website’s domain name is real and is related to the other sites, add to each domain name’s DNS records a “
CNAME” record that resolves to the parent website’s domain name (which is the ServerName value, located in the website’s VirtualHost files). Otherwise use a “
A” record that resolves to the server’s public IP address.
2. [Parent Website] If real, absolutely make sure that the parent website’s domain name (ServerName) has a “A” record that resolves to the server’s public IP address.
3. [Only if using sub-domains] Add to the base domain name (which is likely the parent website’s ServerName) a wildcard (“*”) Host (“host” in DNS-speak is the “sub” part in “sub.domain.name”) a “
A” record that resolves to the server’s IP address.
1. If the Multisite-hosted domains are not yet registered, or this is for local use (or using internal names), make sure to resolve all the sites’ domain names to IP 127.0.0.1 via the Hosts file:
127.0.0.1 www.domain1.name domain1.name 127.0.0.1 www.domain2.name domain2.name ...
2. Clear your Browser’s cookies and cache.