Converting a WordPress site from multi-site to single site is unfortunately not as simple as it should be. Kailey Lampert has helpfully created a tool called “Blog Extractor” which is a WP CLI package which does the basic work of extracting most of the required files and database tables required. On the GitHub repo for the Blog Extractor, it says “This has had limited testing so far and there may be bugs”; we haven’t experienced bugs, but there are definitely features which are missing. Since it is a WP CLI tool, it needs to be run on the command line and you need to have WP CLI pre-configured. The Blog Extractor is a very helpful way to get a large chunk of the process completed, but you will likely need to do some extra work on top. Installation instructions for the Blog Extractor are available on the Blog Extractor GitHub repo.
The table prefix on sites extracted from the Blog Extractor include the original table prefix used in the multi-site network. If you prefer not to have that prefix, you can manually change the table names via a database management tool (make sure to change the table named set in the wp-config.php file of the site).
The Blog Extractor does not migrate network activated plugins over. You can find which plugins are network activated on the original multisite network by running the command wp plugin list --active-network. Copy/paste that list of plugins over to your new single site install and activate each of them.
The blog extractor tool does attempt to migrate WordPress users over, but it only copies those who are current registered as being users on the site. If a user was removed form that site, but they are still the author of a post, then the author listed for that post will be wrong. To avoid this problem, you can copy over the entire wp_users table over to the new single site install. Note that the prefix on the database table may be different and you may need to relabel it to match the prefix of your new single site install. This will ensure that all users from the multisite install are available to your single site install. You could alternatively just migrate over the missing authors, but this will usually be more work than just moving the whole users table. Since they’re not registered on the single site, they will be listed as having no role; this is okay, because you only need WordPress to be able to access their data.
The previous steps will often automatically give you a site which is fully functional, but other times you may need to do more custom manual tasks specific to an individual site. An important thing to look for in the file system of the newly separated site, is for the function switch_to_blog(). This function is used for switching between sites on the multisite network, and if implemented on a single site will not be able to function and can cause catastrophic problems with the sites functionality. It’s not possible for us to provide exact information on how to strip the site of these function calls without breaking anything, as each site is unique and the code implementing that function can be in any format and can be used for implementing an infinite number of different features in various different ways. You will need to look for where it used and adjust the code base with your own judgement. More information about this function can be found on the switch_to_blog() function reference on WordPress.org.
Another feature which is often added to sites which can cause headaches on removal, are hard coded URLs or site IDs within the code. Hard coded identifiers like this can cause strange changes in functionality on converting from multi-site to single site. As with the switch_to_blog() function, you will need to manually hunt through the code for these and remove/modify as appropriate. There is no way to automate this task either unfortunately.
in Jerusalem, Israel