Setting up WordPress Multisite

Previously on the CogitActive Saga:
The benefits of the Multisite feature – its amazing management capabilities, in particular – convinced me.

The easiest way to install WordPress Multisite is, well, to install WordPress Multisite directly. As explained in my Installing WordPress post, there are several ways to install WordPress. One of them – the semi-automatic method – involves using an auto-installer, such as Softaculous. Not only this approach makes it easy to install WordPress with just a few clicks, but it also allows installing WordPress Multisite right away¹ – instead of a regular WordPress installation. All you have to do is to check the Enable Multisite (WPMU) option during the process. That is it!

If you follow The CogitActive Saga (that is if you have read the aforementioned post), you may know that I did not use this method. To make a long story short, I ended up using SiteGround Setup Wizard inadvertently (SiteGround being my hosting provider). This way offers very few options to customize the installation – Enabling Multisite is definitively not one of them. Hence, I had a regular WordPress pre-installed on my hosting account. So, how to turn a regular WordPress installation into WordPress Multisite?

Preamble

Multisite is a feature already built into WordPress (since version 3.0), but disabled by default. All you need to do is to enable it. There are many tutorials explaining how to do so², but you should trust only one source of information: the WordPress codex. Specifically, there are two important articles: Before You Create A Network and Create a Network. The former outlines some requirements to consider before you begin creating a multisite network³ and the latter contains instruction for creating a multisite network⁴.

If you want to set up a WordPress Multisite, you should read BOTH articles! This post is not a substitute for them; it only relates my own experience.

In particular, different types of network have different server requirements³, and my configuration may differ from yours. Especially, I was considering the Multisite feature to build several websites – not to create a full-blown network per se (see Multiple installations vs WordPress Multisite?). This also means that I was not interested in allowing end users to create new sites on demand. In addition, my WordPress installation was less than a month old – it was actually a brand new website. Furthermore, it was running from the root of [my] webfolder (i.e. public_html)³; a requirement for subdomains to work correctly³. Last, but not least, SiteGround’s servers are optimized for WordPress. Meaning, for instance, that I didn’t have to access the server configuration to install and enable Apache’s mod_rewrite module⁵ (it was already in place). Each and every item of this list will have a significant impact of the whole process.

Preliminary steps

I can’t stress enough how critical it is to read Before You Create A Network in full³. This article covers several requirements for a WordPress Multisite network (as briefly touched upon above), but also additional considerations that I have addressed in my three previous posts:

Specifically, I decided to go for a domain-based network, I chose a Pretty Permalink structure, and opted to use File Manager to edit files on the server⁶.

In addition to these preliminary steps, there were other recommendations in the codex³.

Unless this is a fresh install and you have nothing to lose, please backup your database and files.

While I skipped the backup part (given my fresh WordPress installation), I complied with the second advice. I deactivated the one and single plugin that was active⁷; a precautionary measure to avoid any conflict.

Time for Action

Turning my regular WordPress installation into WordPress Multisite was relatively straightforward. It was essentially a three-step process (see below). Again, I want to stress that this post is not a substitute for the instructions provided in Create a Network. Now, if you need more guidance, you may consider watching this video from wpmudev. Granted, it is not the most recent (uploaded in 2013), but it remains one of the best video tutorial available (even if it describes a subdirectories installation rather than a subdomains installation).

Allow multisite

This step is to enable the Network Setup menu item⁴, and requires you to add a line of code in the wp-config.php file. The latter contains your website’s base configuration details, among other things, and is located in the root of your WordPress file directory, namely public_html in my case.

I accessed my cPanel, clicked on the File Manager icon (located in the Files section), selected the Home Directory (not that it matters as each option would have brought me to public_html anyway) and checked the Show Hidden Files (dotfiles) option before to click on Go.

Because the file to modify is one of the most important files in WordPress, I downloaded it to my computer (as a backup) before to edit the original live on the server. To do so, I selected the correct file, clicked on the Edit button and simply added the following code⁸:

/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );

Following the codex instructions, I added these two lines just above this:

/* That's all, stop editing! Happy blogging. */

I saved my change and closed the editor window (in File Manager).

Install a network

I let File Manager opened and came back to my WordPress dashboard, refreshed my browser, and I could indeed navigate to Tools > Network Setup to access the Network Setup screen.

There was a notice about mod_rewrite, but this was not a concern as explained earlier in this post.

Note: Please make sure the Apache mod_rewrite module is installed as it will be used at the end of this installation.

In the Addresses of Sites in your Network section, I selected Sub-domains. In the Network Details section, which was pre-filled, I just changed the title of my network. I pressed the Install button and …

… as expected, I had the following warning:

Warning! Wildcard DNS may not be configured correctly!

As explained in the codex⁴, the installer checked for wildcard subdomains. As I did not need this (see box above), I followed the codex advice and ignored the warning.

Enable the network

For the last part of the process, the instructions were on the Create a Network of WordPress Sites screen. It started with an invitation to backup your existing wp-config.php and .htaccess files. This time, I didn’t take into account the unless this is a fresh… restriction and backed up both files (i.e. downloaded them on my computer using File Manager).

The next step was to add some lines of code to the wp-config.php file in the same location as before. Using File Manager again, I simply copied the code and pasted it below the previous addition, saved my changes and closed the editor.

The last step consisted in replacing other WordPress rules in the .htaccess file with the one provided. This was maybe the less straightforward part of the whole process. First, you should be careful, as there are several .htaccess files. Second, if you did not check the Show Hidden Files (dotfiles) option when you opened File Manager, you will not find any. Last, but not least, how to distinguish WordPress rules from other lines of code? For that matter, I had to rely on tutorials. The problem is that I found three different methodologies. The first consisted in deleting everything that was present before to copy the new block of code. The second was to replace just the lines in between “# BEGIN WordPress” and “# END WordPress”. The third was keeping an additional coding component.

REPLACE EVERYTHING

# BEGIN WordPress

NEW CODE HERE

# END WordPress

Method 3

# BEGIN WordPress
<IfModule mod_rewrite.c>

NEW CODE HERE

</IfModule>
# END WordPress

Which of these methods is the correct one? Honestly, I don’t know¹⁰. I first implemented the second method (and it worked), but few minutes later (after the setup process being completed) I opted for method 3 (i.e. I wrote the two lines of code back). In both cases, my Multisite installation was working fine.

Anyway, after completing these steps, I logged in again using the link provided.

I was now the Network Super Admin (and still the original site Admin). My first action as the Super Admin was to Network Activate the plugin that I had initially de-activated.

To be continued…

¹ The only issue with this approach, however, is that your Multisite installation will apparently default to the subdirectories configuration. See A domain-based or path-based network for more information on the network structure. Now, it is possible to switch to a domain-based network afterward. ^
² After going through many tutorials, I finally reached these two articles from the WordPress codex. Regrettably, Google algorithm does not rank these two pages the way they deserve. Anyway, reading them made me realize two things. Number one, pretty much everything I read before was just a waste of time. Most of the articles on the matter simply packed the same information (as provided by the codex) in a not-so-different way, when not just coping and pasting it. Second, and more problematic, the information was sometimes not accurate (or oversimplified) and the instructions were misleading. As already stated in the “Evaluation of sources” section of my How to podcast? post, reliability is an important factor to take into account when evaluating sources of information. ^
³ See Before You Create A Network. ^
⁴ See Create a Network. ^
⁵ WordPress uses mod_rewrite for its permalink structure, and also for multisite networks. This module is indeed listed in the “Server Requirements” section of Before You Create A Network. ^
⁶ Let me reiterate my issue with some sources of information². Often, you will see that you need to use an FTP client to edit the files during the Multisite creation process – no alternative method being proposed. However, the WordPress codex clearly states that this task can be achieved using FTP, or using the File Manager in cPanel, or in some other way³. For this very task – in particular, if you are a newbie and you don’t already have an FTP account – the second option (File Manager) is without a doubt a better solution. ^
⁷ SiteGround installs a slightly customized version of WordPress (when using the Setup Wizard). Thus, it comes with the Jetpack plugin in addition to the two plugins normally bundled with each WordPress installation (Hello Dolly and Akismet). Furthermore, this extra plugin is activated by default, while the other two are not. ^
⁸ The first line, which begins with /* and ends with */, is just a comment. It is not doing anything per se, meaning that it is not executed as part of the program. Its only purpose is to be read by humans and can be used to label neatly what the following line of code is doing. Because it is not essential, yet a good practice, you will often see tutorials² that omit it altogether. ^
⁹ Kevin Muldoon (2014) The Complete Guide To Creating A WordPress Multisite Installation. Elegant themes. ^
¹⁰ However, as explained before⁸, commenting your code is an important part of staying organized. Now, commenting rules differ from one language to another, and in the .htaccess file, each line of comment begins with #. Hence, removing the two lines of comment (method 1) was inconsequential, but removing everything is a different story (you may have extra code beyond the WordPress rules). As for deciding in between the two other methods, there is a StackExchange question related to this issue: Is Checking For mod_rewrite Really Necessary? It is up to you to figure out what is best and to add your insight in the comments below. ^