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 away1 – 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?
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 so2, 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 network3 and the latter
contains instruction for creating a multisite network4.
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.
different types of network have different server requirements3, 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)3; a requirement
for subdomains to work correctly3. 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 module5 (it was already in place). Each and every item of this list will have a significant impact of the whole process.
I can’t stress enough how critical it is to read Before You Create A Network
in full3. 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 server6.
Here is a tricky one that I didn’t fathom completely back then (see Let’s Encrypt). Probably because most tutorials on Multisite were published before 2017 – the year Google started to flag unsecure websites – they purely and simply omitted to mention SSL certificates. Even the codex4 was, and still is, rather sparing on that matter:
Follow your DNS & Web Server settings to configure
and install an SSL certificate for each subdomain
and master domain.
Let me clarify my problem. When I installed my SSL certificate, I did not configure WordPress properly. Explicitly, both the Site Address (URL) and WordPress Address (URL) fields were still using the http:// URL rather than https://. Now, once WordPress Multisite is in place, you cannot edit these two fields anymore, at least for your main site. If you want to, you have to edit manually your database – something best avoided.
I don’t comprehend the intricacies of this issue. My guess, however, is that it is preferable to install the SSL certificate before turning your installation into WordPress Multisite. That is why I would recommend to:
Set your SSL certificate (and configure WordPress properly) before continuing with the Multisite installation!
In addition to these preliminary steps, there were other recommendations in the codex3.
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 active7; 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).
This step is to
enable the Network Setup menu item4, 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 code8:
/* 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 …
Too often, you will see2 that
you have to configure wildcard subdomains (when choosing subdomains). That is not correct! You can, but you don’t have to. This is required only when you want to have
on-demand domain-based sites3, meaning you allow end users to create new sites on demand. A functionality I was not interested in!
You can create a multisite network in which only you,
the administrator, can add sites.
As explicated in the codex, there are several ways to configure properly a domain-based network. Configuring wildcard subdomains is one of them, but it is not the only method. In particular, you can also create
addon domains or subdomains in cPanel3. As I would create all sites in the network myself – a small handful of websites to be precise – creating subdomain manually for each site is not a hindrance.
More importantly, while the former method (wildcard subdomains) may be easier because it allows WordPress to handle all your subdomains instead of your web host, it has a potential caveat:
it would redirect [your existing subdomains] to your home page9.
If you already use subdomains, you probably do not want use a wildcard; as it would inadvertently redirect your existing subdomains.Kevin Muldoon
Granted, I was not in this situation, yet, the alternative method (i.e. creating subdomain manually for each site) was self-evident at the time.
… as expected, I had the following warning:
Warning! Wildcard DNS may not be configured correctly!
As explained in the codex4, 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.
# BEGIN WordPress
NEW CODE HERE
# END WordPress
# BEGIN WordPress
NEW CODE HERE
# END WordPress
Which of these methods is the correct one? Honestly, I don’t know10. 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…
1 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. ^
2 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. ^
3 See Before You Create A Network. ^
4 See Create a Network. ^
5 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. ^
6 Let me reiterate my issue with some sources of information2. 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 way3. 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. ^
7 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. ^
8 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 tutorials2 that omit it altogether. ^
9 Kevin Muldoon (2014) The Complete Guide To Creating A WordPress Multisite Installation. Elegant themes. ^
10 However, as explained before8, 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. ^