Guide for WordPress Multisite
Tags: wordpressdevelopment, php, development, cmsdevelopment
Published: 2023-01-10 11:08:59

---
title: Guide for WordPress Multisite
published: true
date: 2022-12-30 12:45:15 UTC
tags: wordpressdevelopment,php,development,cmsdevelopment
canonical_url: https://wplake.org/blog/wordpress-multisite/
---

Learn about WordPress Multisite Network, when you may need it and how to setup. We’ll review advantages and drawbacks, and also will share tips that will help to create, manage, or split your own multisite.

![cover](https://cdn-images-1.medium.com/max/1024/1*rjGdgJV8vSjpjpPAR9c-Sg.jpeg)

### About WordPress Multisite

You can be familiar with WordPress for many years, but may not know what is WordPress Multisite. That’s because most WordPress websites are a single installation. This feature is used pretty rarely, but it’s an essential feature of WordPress, and in some cases can be indispensable.

What is a WordPress Multisite Network? It’s a couple, or more, WordPress websites that use a single WordPress installation. It means they have a common file system and a common Database. Don’t worry if it sounds foggy, we’re going to review it in a simple example.

#### An example with flowers

Let’s say we have a website about flowers, and our domain is **flowers**. We review all kinds of flowers here, but there are very popular kinds, like **roses**. So we have a lot of requests about them and want to dedicate a separate website, which will cover only them. It may be either **roses.flowers** or **flowers/roses**.

A separate website means a lot of work, we’ve to create a new theme, and set up and configure all plugins. And what if we want to have a separate website for several kinds of flowers, not only roses? It means we’ll have many different WordPress websites, with separate dashboards.

Just imagine that you’ll need to login into all of them from time to time. Updating plugins on each of them will be a problem. But the real nightmare will be updating a theme, if you’ve made changes to one of the websites, you’ll need to repeat the update on each of them.

WordPress Multisite feature suggests a solution. A network of WordPress websites that use the same installation. In our case with flowers, we can have an unlimited number of subdomains (kinds of flowers) for our primary **flowers** website, and all of them will be available via one dashboard. They’ll use one installation, which means all of them will have an access to the primary plugins and your theme. You’ll update plugins or make changes to the theme only once, and all subdomains will display it immediately. It’s possible thanks to the common file system.

### Limitations of Multisite

We hope it’s clear to you now overall, what is WordPress Multisite. Let’s talk about limitations, to understand in which cases it won’t work.

The biggest limitation is the domain. WordPress Multisite feature can work only with subdomains or subfolders. It means we technically can’t join several different domains, like **flowers** and **clothes**. The feature allows joining only subdomains of one domain.

A subdomain is a secondary domain that is based on the primary. For example, in the case with **roses.flowers** the **flowers** is a primary domain, and a subdomain.

A subfolder looks like a plain permalink, but instead of a page contains a whole website. For example, in the case of **flowers/roses** , the **roses** will be not a page, but a website. It means that all pages of the roses website will have the such prefix. For example, **flowers/roses/history** and **flowers/roses/how-to-care**

WordPress Multisite allows joining the primary website and all subdomains into a single installation, single network. If you want to have different domains, unfortunately, you must use several single installations.

There are other differences between single and multisite installations, but they aren’t limit us. We’ll review them a bit later.

### Features of Multisite

![features](https://cdn-images-1.medium.com/max/1024/1*KKPKruJcTDyfBxGjFpoClg.jpeg)

Now let’s review the key principles of the Multisite.

#### a) Common file system

All websites in the Multisite Network use the same single folder. It means a common list of plugins and themes. Don’t worry, each website has its own active list, so you can activate some plugins or a theme only for one website of a Network.

Uploads of the primary website are still stored within the ordinary **/wp-content/uploads/** folder. Uploads for secondary websites (subdomains) are also stored within the **/wp-content/uploads/** folder, but within adding subfolders.

For example, a newly uploaded **tulip.png** to the primary website will be saved as **/wp-content/uploads/2022/12/tulip.png**. A newly uploaded **rose.png** to the secondary website will be added to a subfolder, like **/wp-content/uploads/sites/2/2022/12/rose.png**. Where **2** in this path means an ID of the secondary website. Each secondary website in the Network will have its own ID, but you shouldn’t take care of it.

#### b) Shared Database

All websites will use a single Database. But each website will have its own tables for content. Posts, PostMeta, Taxonomies, Options, all of it will be unique for every website. It means you can have different pages, categories, and settings for each website, just like in the case of independent websites.

An exception is the Users, they’ll be common for the whole network. It’s a good thing, otherwise, editors and users would have to sign up separately for each of them. But don’t worry, user roles are unique for every website, so you can easily manage access. For example, you can deny users from website A to use of their credentials to log in to website B. Of course, if it needs.

WordPress Multisite creates several extra tables, like **wp\_blogs** and **wp\_sites** , but you shouldn’t worry about them. Those tables are needed for WordPress to manage the Network.

#### c) Dashboards

There is one common dashboard for a whole Network, and separate for websites.

A new role appears, Super Admin. By default, this role will have that administrator, which has created the Network. This administrator will be able to access a Network dashboard, which is common for all the websites. In this dashboard, he will be able to install, update or remove plugins and themes.

Each website still will have a separate dashboard, where its content can be managed in the usual way. Only one new limitation appears here: administrators won’t be able to add, update or remove plugins anymore. Administrators now have only the right to activate or deactivate plugins and themes for the current website. The right to install, update and remove plugins and themes belongs completely to the Super Admin. These changes can be done only via the Network Dashboard. So, you can update your plugins for all the websites in one place. It’s beautiful.

#### d) robots.txt and .htaccess

It’s important to mention these files separately. **robots.txt** relates to SEO, and  **.htaccess** manages permalinks (navigation). These files are a part of the file system and will be common for all the websites in WordPress Network.

But there is a major change: WordPress won’t rewrite these files automatically anymore. Before it was so, and every time you visited the Settings — Permalinks page, WordPress rewrote that file automatically. With the Network, you’ll be able to change those files only manually. It’s not a problem, just keep in mind that if your theme has any code that modifies those files, for example, uses the **mod\_rewrite\_rules** hook, it won’t work anymore.

Also, some plugins rely on similar hooks, like cache plugins. But don’t worry, all big plugins support the Multisite mode and will show notices with a guide, in case they’ll need to modify  **.htaccess**

#### e) Cron tasks

Cron tasks will work in the usual way. In case you’ve made no changes and your website uses the built-in WordPress cron, then everything will be the same for you.

But, in case you’ve disabled the built-in WordPress cron, and used **crontab** (e.g. to guarantee calls with fixed intervals) then your current approach won’t work anymore. You’ll have several websites, and the previous line in **crontab** won’t cover all of them. To keep using **crontab** for cron, you must install **wp-cli** and use a special bash script. You can read more about the setup [here](https://servebolt.com/help/article/how-to-setup-server-side-cron-for-wordpress-multisite/). You can also use the bash snippet from that article, just don’t forget to change the relative path in the bash code to absolute.

### How to setup WordPress Multisite

Note: before setting up a WordPress Multisite, think twice to make sure it fits your requirements. It’s pretty easy to create a WordPress Multisite, but there is no simple way to split or unmerge the Multisite Network back to single installations. Create Multisite only when you’re sure that you won’t need to have them as separate installations.

There is a great official guide from WordPress, which you can find [here](https://wordpress.org/support/article/create-a-network/).

Overall, the process is pretty simple and consists of several steps.

> _Important: Don’t forget to make a backup before any changes._

**1. Define a special constant** (in the **wp-config.php** )

It’s necessary to unlock the Multisite feature.

```
define( 'WP_ALLOW_MULTISITE', true );
```

**2. Deactivate all your plugins**

It’s necessary to make sure you’ll have no conflicts during the setup.

**3. Visit the Tools — Network setup page**

Here you have to choose a Network type (subdomain or a subfolder) and you’ll receive pieces of code for your **wp-config.php** and  **.htaccess**  . You’ll need to follow the instructions and paste those pieces into the files.

**4. Final. Log in and activation of the plugins**

After the steps above, you’ll see a message that asks you to log in again. When you’ve logged in, you’ll see the common Network dashboard and links to the specific website dashboards. Now you can activate your plugins for specific websites.

Congrats! Now you have the Multisite installation!

### How to transfer WordPress Multisite

**To another hosting**

You may need to transfer your WordPress Multisite to another hosting. In this case, no extra actions are required. Everything will be the same as with a single installation. If you’re unfamiliar, you can read the [official article](https://wordpress.org/support/article/moving-wordpress/) from WordPress. You have to move your files, and your Database to the new hosting, and then update DNS records to point to a new hosting. That’s it.

**To another domain**

It’s pretty easy to move WordPress to another domain if we talk about a single installation. In the case of the Multisite Network, the task can’t be done using built-in tools, as the whole Network depends on a primary domain. But don’t worry, we can achieve it with manual updates in the Database. For example, via PhpMyAdmin.

You can copy your Live database, import it to a new place, and then perform the following:

1. Changes in the **wp\_site** table  
Replace the old domain with the new for values in the **domain**  column
2. Changes in the **wp\_sitemeta** table  
Replace the old domain with the new one for **meta\_value** in the rows where **meta\_key = ‘siteurl’**
3. Changes in the **wp\_blogs** table  
Replace the old domain with the new for values in the **domain**  column

After that, don’t forget to update the **DOMAIN\_CURRENT\_SITE** constant in the **wp-config.php** to the new domain.

Also, don’t forget to make ordinary changes that are necessary for a single installation. I mean changes in the **wp\_options** table for the rows where **option\_name = ‘siteurl’** or **option\_name = ‘home’**.

That’s it. Following the steps, we’ve moved a WordPress Multisite to another domain.

### How to split WordPress Multisite

By default, WordPress doesn’t provide an option to ‘unmerge’ WordPress Multisite Network. The task is pretty unusual, that’s why developers didn’t make a feature for it.

There are only a few reasons why you need to split WordPress Multisite into several single installations. One of them can be a case when the subsites have grown and now have nothing in common with the primary website. So there is no sense to keep them within a Multisite Network anymore.

Usually, in this case, it’s better to create a new installation for each of them, and then import content from the related subsite manually. And then just remove the related subsite in the Network.

As a plan B, you can try to split the Multisite with manual changes in the Database. But you need to have strong WordPress knowledge and skills to work with dumps. Here are the steps that you need to follow for each website:

1. Make a MySql dump   
With all tables related to one website, plus common tables: **wp\_users** and **wp\_usermeta**
2. Import the dump into a new Database  
Don’t forget to update a table prefix to the ordinary ( **wp\_** ), in case it was a subsite.
3. Log in, to make sure everything works  
If you had roles only on of the websites, you may need to recreate them again

You can easily recognize which tables belong to which website. As we’ve mentioned each website in the Network has an ID. This ID is added to all website tables. For example, the Posts table for the first subsite will have a **wp\_1\_posts** name, for the second will have a **wp\_2\_posts** name, and go on and go forth. Only the primary website tables will have no prefixes. So, the Posts table name will look like as usual, **wp\_posts**.

### Conclusions

We’ve reviewed all important topics related to the WordPress Multisite feature. We hope that now you understand how it works, and what the goal of the feature is.

Using a Multisite Network can solve a row of problems. In case Multisite fits your requirements, use this knowledge to easily create and manage your own WordPress Network.

Thank you for reading! Follow us to get notified about new articles.

_Originally published at_ [_https://wplake.org_](https://wplake.org/blog/wordpress-multisite/) _on December 30, 2022._