WordPress multisite

Multisite is an excellent and somewhat hidden feature of WordPress. Its concept suggests that there are other ways to use WordPress and there are many of them.

A typical WordPress installation corresponds to one website. For example, if you want to create a separate blog for your company website, you need to install another WordPress. In this case, multisite mode would help you.

What are the advantages of multisites

The main benefit is the ease of administration. The installation is a bit unusual (you have to enter the settings, then the other controls appear), but on the other hand the administration is really uncomplicated. Within a short period of time, you can create a new website with users.

Websites do not have to be used only as blogs or as „one website = one purpose“ (i.e. one website will be a presentation, the second a blog, the third an e-shop, the fourth for gaming). Scenarios for using a network of websites can be as follows:

• language versions of the company’s website
• developer or test websites
• user sections (each website is one content section and the user is granted access after meeting the entry conditions)

What are the disadvantages of multisites

The main disadvantages can be seen immediately by the average user –  first of all, the separation of individual websites. Images are uploaded to the directory of each specific website and are not directly accessible from other websites. There is no easy way to transfer template and widget settings. The situation can be solved by using plugins, but it is not as easy as a regular WordPress installation.

When you measure a website using analytics, it depends on where you place the tracking code. The plugins are common, so you would have to filter your analytics results by website, which is true even if you use one template for multiple websites on your network. If each website has its own template, it may have the original tracking code in it.

The plugin developer must consider whether and how his plugin will work in this environment. Some plugins can complicate the situation considerably, e.g. WPML running on a single website on the network will work, but managing it will be quite challenging (especially in terms of translated strings).

Another fact is that if you have a development (test) website on your network, you cannot easily remove plugins because it would affect the entire network, including live (production) websites.

When is multisite useful and when is it not?

First of all – multisite is only beneficial if at least some of the following circumstances or conditions are met:

• there are several sites, at least three or four; we can also work with multisites that have two sites,
• websites already have something in common, e.g. one design with minor variations or users,
• websites should have something in common, such as configuration, i.e. the purpose is to save time and energy on administration and maintenance.

What shouldn’t bother you then:

• only a small number of plugins support special features for multisites, most plugins work within individual websites and do not know that the website is part of a network,
• some plugins for export, import, backup and other technical support do not support multisite or such an add-on costs quite a lot of money,
• multisite is difficult to migrate (it can be done, you just have to know what you’re doing),
• there is not only one way to run a multisite, it is quite a complex and complicated system that can work in different configurations,
• plugins are enabled at the site level if they do not support multisite mode, which means manual intervention on the site is required,
• one plugin can exist only once in the network, so it cannot be debugged in the network, because its malfunction will endanger all sites that use it.

Complications in practice

I will list here some problems and situations I have encountered or created myself 🙂 . And then of course I fixed them. The problems are not related to multisite not working as it should, but always to the fact that I forgot something or didn’t realize a certain context.

Domain for the main website

If you want to have individual websites on subdomains, for example bodie.yoursite.com and doyle.yoursite.com, then you need to have the main domain yoursite.com.

It is not enough to have, for example, pros.yoursite.com and assume that this will create the administration of the entire network.

This is because the necessary cookies are valid for one domain and cannot be used for another domain, which is typically the case for cross-site scripting (XSS), which no browser will allow. This is logical –  a cookie cannot authorize access to another domain.

You need to know this from the beginning, because it’s hard to redo after installation.

Cyclic redirection to registration

If the multisite still redirects you to the registration page (too many redirects) instead of letting you log in to the site, then you are making mistake

• either in the .htaccess settings or nginx.conf,
• or paths for individual sites, usually after migration – database table error

Certificates & aliases

It’s a bit different on every hosting. If they don’t have direct multisite support in the service application, then you have to ask support to set it up.

Tell them that WordPress multisite is on (sub)domains (otherwise you shouldn’t need their help installing it into directories). Usually the support operator creates aliases to the subdomains,

• i.e. symlinks or directories pointing to the main installation directory, or
• sets up an alias in the web server configuration

Crucially, you must specify which two-level domains to include in the certificate. Subdomains are covered by wildcard (asterisk *), there is no problem there. In one multisite you can have websites on second (.com) and third domain level (subdomains).

The correct domain for the web – domain mapping

Once you have working certificates and https, change the homeurl of the websites to the target URL. After this step, start inserting or importing data into the sites.

Otherwise, you will end with paths like xttps://bodie.yoursite.com/ (if you are on a subdomain) or xttps://yoursite.com/bodie/ (if you installed to directories), but actually you want to have i.e. xttps://bodiedoyle.com. The subdomains are used for internal/technical purposes only.

This is not a redirect – the addresses are directly saved in the database, which is exactly what we want. We don’t want to add redirects when they are not needed – so don’t even use any plugin for that.

Sending e-mails and user access

If the multisite website is not ready (the website is not published) and publicly accessible, i.e. running in the service mode with help of some plugin, then transactional emails are usually not sent to the new user after registration.

If you sent the user directly to the login URL, they would not be able to log in because they did not confirm the registration in the email (which did not arrive). Therefore, it is a good idea not to insist on sending emails if you want to invite the user to an unfinished website.

It’s also a good idea to add users at the website level, where you can set specific permissions. Only letters and numbers are allowed in the username – as opposed to the classic single installation, where there can be a dot, for example. The latter is not allowed in this case, the names are common for the whole multisite, which is probably the reason.

Multisite database tables

A set of tables is created for each website on the network. Each set is prefixed with the site number (this number appears, for example, in the path to images). The core tables are: comments, commentmeta, links, options, posts, postmeta, terms, term_relationships, term_taxonomy.

Then there are tables of plugins for the website. This is the configuration of each website on the network. Plugins working across the network have tables only in the main set, i.e. without the numeric prefix.

The overall multisite settings are stored in the following tables (dataset without numeric prefix):

• wp_blogs – addresses of individual websites in the network
• wp_site – address of the multisite control site, i.e. network administration
• wp_sitemeta – multisite settings, i.e. how the whole network should be set up
• wp_users – users for the whole network of sites

Depending on the configuration of the URL, the primary website can also be a content website. If the multisite is on yoursite.com and the websites in the network are on subdomains, then the configuration and content of the website on yoursite.com is in tables like wp_options, wp_posts. But if the control website is also the first website in the network (=has the same url), then [probably] the content in tables wp_2_posts etc. takes precedence.

Multimassacre

It’s actually not that complicated, there’s just a lot of information around. The first three multisites are challenging because the configuration is never the same, sometimes the hosting doesn’t cooperate (tech or people), sometimes it gets stuck, sometimes you forget to set something up. But it’s not rocket science 🙂.