Contents
Preface
WordPress supports multi-site functionality, but I have never felt that there is an urgent need for multi-site, and I don’t want to use the equipment that normally runs the site to experiment, so I have never tried it.
A few days ago, in order to write a solution for WordPress multi-site (see article:Home data center series uses cloudflare tunnel to realize automatic takeover of disaster recovery site when WordPress main site fails), and bought an Alibaba Cloud server for 99 yuan. Now that the plan is written and the cloud server is idle, I thought I might as well take this opportunity to familiarize myself with the WordPress multi-site function so that I can use it immediately when needed in the future.
However, after following various online tutorials for a long time, I found that for a site that has been running for a long time, directly enabling the multi-site function has too many inconveniences:
1. Sub-directory deployment cannot be used
For sites that have been running for more than a month, the sub-directory deployment method is no longer an option (although I don’t use it), but I believe this is a convenient deployment method for many friends.
2. The subdomain model will have some inexplicable problems
After enabling the subdomain-based multisite mode, set up the WordPress site according to the previous domain name access method (see article:A simple tutorial on how to set up WordPress to support multiple domain name access), different inexplicable problems would occur. Finally, the problem was solved by modifying the site url and home in the wp_options table of the wordpress database. However, it didn’t feel right after it was accessible. Sometimes the page could not be opened in the console and needed to be refreshed. In short, it was not very pleasant.
Ultimately, the decision was made to redeploy the site to a new multisite WordPress site and then restore other settings. This article assumes that the content of my domain "blog.tangwudi.com" was migrated to a new multisite WordPress site "test.tangwudi.com".
Redeploy WordPress
I won’t go into details here, you can refer to previous articles:Docker series uses Docker to set up a blog slave site based on WordPress and implement regular backup of master-slave site configuration.
Enable multisite
Edit the wp-config.php file and find the following description:
/* That's all, stop editing! Happy publishing. */
Then add the code above this line and save:
define( 'WP_ALLOW_MULTISITE', true );
As shown below:
Then enter the dashboard, and under the Tools menu there is an option to configure the network:
If the following warning appears, it is because the wildcard domain name resolution of *.test.tangwudi.com is not configured to point to the site. Don't worry about it. You only need to configure the subdomain correctly afterwards:
Configure the site network correctly according to the prompts in the red box below:
After saving, log in again and you will see a new "My Sites" option. The "Manage Network" option is the key to adding new sites.
I will not go into details about how to add a new site or how to add an administrator for a site. There are many tutorials online and it is not difficult. This is not the focus of this article.
Migrate old site data to the new site
In fact, many tutorials on how to start WordPress multi-site on the Internet end at the previous section. If it is a brand new site, this is normal. However, if we want to start multi-site on an old site that has been running for a long time and has a lot of content, we need to migrate the data. Of course, this migration is also divided into WordPress program data and content in the database.
Migrate old site wordpress program data
Prerequisite knowledge: The WordPress program has three directories: "wp-admin", "wp-incloudes", and "wp-content".
“The "wp-admin" directory contains administrative files that control the WordPress dashboard; "wp-incloudes" contains files that store and manage the appearance of the WordPress dashboard; and "wp-content" contains folders containing all themes, plugins, upgrades, and uploads used by the website.
To minimize disruption to the new site's configuration files, I directly copied the three directories from the old site: "wp-admin", "wp-content", and "wp-incloudes" to the new site. However, accessing the site resulted in the following error:
Theoretically, the best approach at this point would be to find which configuration file specifies the "twentytwentyfour" theme and then change it to point to the existing theme. However, after a quick look, I couldn't find it. Too lazy to bother with that, I simply renamed the existing theme, specifically the folder "twentytwentytwo" (highlighted in red in the image below), to "twentytwentyfour".
Then you can access:
use
https://test.tangwudi.com/wp-admin/my-sites.phpVisit and you can see that all the plugins are here:
The theme has also come over, but the agron theme used by the old site is not the default theme and is not enabled:
Change the argon theme to enable it for all sites:
Note 1: After enabling multisite, usehttps://test.tangwudi.com/wp-adminThis only accesses the dashboard of the main site "test.tangwudi.com" (the other sub-sites are similar). To globally control plugins, themes, articles, and other content across all sites, you need to access...https://test.tangwudi.com/wp-admin/my-sites.php:
Note 2: After much troubleshooting, I finally discovered that the "plugins" directory under the "wp-content" directory is the original installation directory for the plugins. It's best to clear it out, because some plugins don't support multiple sites (or only the paid version supports multiple sites). Copying them directly will cause a lot of problems. It's better to reinstall them on the new site according to the actual situation. This problem wasted at least a day of my time.
Migrate old site articles and other data to the main site of the new site
Originally, I thought it was very simple: either directly import the wordpress database of the old site to the new site, or use the WPvivid backup plug-in to directly restore the database content, but I found that it didn't work. After directly importing the sql file exported from the old site, the site might not be opened. . , I think it's because the database formats of single site and multi-site are different, and the WPvivid backup plug-in simply said that the free version does not support multi-site and needs to be upgraded to pro. So I adopted a more primitive method: export all data on the old site as an xml file, and then import it on the main site of the new site:
The default maximum upload file limit for WordPress deployed by Docker is 1 MB. If the XML file exported from the old site does not exceed 1 MB, you can import it directly. However, mine is 2.7 MB, which is much larger than 1 MB, so I need to modify the php.ini in the WordPress container.
Because I'm used to using Vim, I needed to install it using apt. However, the default WordPress container doesn't have a "/etc/apt/sources.list" file, so I couldn't use apt. Therefore, I used the following command to generate sources.list:
cat < /etc/apt/sources.list deb http://deb.debian.org/debian/ bookworm main contrib non-free-firmware deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free-firmware deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free-firmware deb http://deb.debian.org/debian- security/ bookworm-security main contrib non-free-firmware EOF
Then you can run the following command to install vim:
apt update apt install vim
Finally, edit php.ini using the following command:
cp /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini vim /usr/local/etc/php/php.ini
Generally, you only need to modify the following two parameters:
upload_max_filesize = 20M # Modify according to your actual needs post_max_size = 30M # Modify according to your actual needs, generally this value should be larger than the above upload_max_filesize
Import the XML file exported from the old site into the main site:
Then start the argon theme in the appearance:
Finally visit the main site, now the basic framework is ready:
All that’s left is to reinstall the plug-ins and see which plug-ins support multi-site mode. If they don’t, you need to find alternatives. You also need to set up the plug-ins. If you really want to do it, it will take some time, so I won’t go into details here.
Summarize
Actually, after going through all this trouble, I found that the multi-site mode is indeed not as convenient as the single-site mode in terms of operation and maintenance. Migrating from a single site to the multi-site mode is still quite troublesome. If one of the sites in the multi-site mode is much more important than the other sites, I think it is better not to use the multi-site mode. Otherwise, if one of the unimportant sites is attacked and has problems, the important sites will also be affected.
In addition, I think that if you want to use the multi-site mode, it is best to plan it from the beginning and start setting up from a brand new site. First, the sub-directory mode is still very practical and there is no need to bother with sub-domain names. If you deploy a cluster of sites and have a detailed plan, the sub-directory mode will be very suitable; second, after running for a month, you can only set up the sub-domain mode. If it has been running for so long, it is estimated that the plug-ins have been configured and run-in. If you use the multi-site mode based on sub-domain names, it will be very troublesome to use the plug-ins, which feels a bit like getting half the result with twice the effort.
Using a subdomain is ideal, ideally using a second-level domain as the main domain, such as "tangwudi.com" in my case. This makes adding other sites later easier, as the DNS resolution will be simpler. Following my article's example of "test.tangwudi.com", adding a subdomain would result in "site1.test.tangwudi.com", which looks messy. This can be solved using CNAME records, such as "abc.tangwudi.com cname site1.test.tangwudi.com". Accessing this will still work, just make sure to configure the reverse proxy's host settings correctly.
To sum up, the default single-site mode and multi-site mode each have their own advantages. It is best to make a good plan when building a website and choose the one that suits you best. Once the site is running, it is best not to bother with it anymore.