Monthly Archives: July 2020

WordPress Multisite Error

A very open headline for what was a confusing WordPress Multisite Error. A more accurate headline after the event might be WordPress Multisite migration to a new server or domain url.

Scenario: An older wordpress site was migrated to a new server with PHP7.3 but was using PHP 5.6 on the old server and was not working on the new server. The problem was that the old server had been decommissioned.

At this point I was asked to review and fix if possible. I tried a number of processes just to see if an in-place fix was possible, including turning off the multi-site function for the site copy on the new server and processing wordpress updates, but turning the multisite back on failed to run the site.

So I created a ‘dev’ copy on a PHP5.6 enabled server, copied in the database, and the files, configured the options settings to change the live url to the dev url, and then stepped through the following:

First issue was that the url of https://dev.insertdomainnamehere.com/ would process but come up with a result of ‘server not found’ with the url modified to show as https://http//dev.insertdomainnamehere.com// which looked weird, was obviously broken, but why was it happening?

It seemed like a mod_rewrite issue, which pointed at the .htaccess setup so I reviewed that. Reference https://wordpress.org/support/article/multisite-network-administration/#htaccess-and-mod-rewrite
and compared all the lines, and the (potential) version matching issues, and I used the settings for 3.5+ which seems to still hold true for WordPress 5+. Nothing seemed wrong here.

Next I checked in the wp-config.php file and confirmed the database settings and then the various WordPress multisite parameters and in particular the define(‘DOMAIN_CURRENT_SITE’, ‘ https://dev.insertdomainnamehere.com/’) which I had modified from the live site url. I found that if I modified this setting then the broken url changed to correspond to this domain setting.

Why the weird url? Because this parameter should not include the protocol or the trailing slash. The correct format of this parameter would be:

define( 'CURRENT_DOMAIN_SITE', "dev.insertdomainnamehere.com"); 

So I turned off multisite setting with define(‘MULTISITE’, false) in the wp-config.php file and found that the access to the site was working, albeit without the Network option or subsites available. This just confirmed that the database connection was working and that the site configuration was ok, at least in part.

Checking the content of the database I noted that the subsites had table prefixes of wp_2_ and wp_3_ consistent with a multisite database, except there was no wp_1_ which made me wonder if the primary site was not configured correctly (strange as it had been working previously).

But that is correct. From one of the pages I reviewed ” It’s not supposed to make wp_1_* tables anymore. That was only done in WPMU and as of WordPress 3.0, you start with wp_* and all subsequent sites get numbers. ” So the wp_2 and wp_3 are correct.

Reviewing some more WordPress commentary searching for wp_1 gave up this reference at Stackoverflow on a WordPress database issue and while the problem was not the same, one of the replies slapped me as I had missed one of the multisite settings (or lack of it) in the wp-config.php.

define( 'WP_ALLOW_MULTISITE', true ); 

This is not the same as

define('MULTISITE', true);

and the wp-config.php file was missing the WP_ALLOW_MULTISITE parameter. (Why and for how long?) In any it was now added.

Not so much second, but just somewhere in the mix, I found that with some setting combinations, I would get a “Error establishing database connection” as a WordPress formatted error page. Which made me think that the database connection was wrong, but as mentioned above, swapping to multisite = false worked ok, so not database as such.

Next reference was found while I looked at Stackoverflow results again with https://stackoverflow.com/questions/19724781/wordpress-multisite-error-establishing-a-database-connection-in-localhost in which another comment not directly relevant to the issue was about checking the wp_blogs table.

Noting that I had modified all the wp_options tables to use the ‘dev’ site url, I checked the wp_blogs table only to find that these were (naturally) still pointing to the live site url’s. A quick modification to each of the primary and two subsite urls and the site was running smoothly.

In summary, for multi-site to work, we must have:

  • wp-config.php with both WP_ALLOW_MULTISITE and MULTISITE parameters defined as True.
  • update the wp_options tables AND the wp_blogs table to reference the new site url.
  • update or at least check in the wp_site_meta table for the ‘network admin’ access
  • correct format of the parameter for CURRENT_DOMAIN_SITE

Now, I should be able to get on with security patching and reinstatement as a live site.