I have been doing some extensive work with client sites (and my own) that involve moving sites across the internet.

Now, moving a standard site consisting of simple files is relatively easy. Simply copying and pasting the directory (and then adjusting any DNS settings) is all that is required to get these up an running.

However, WordPress – despite residing on a server in it’s own directory – is not simply a collection of static sites. Instead, it is server-rendered, using a MySQL database and a large collection of PHP files and scripts. While it’s not terribly complex, having a database and large number of scripts do increase the complexity of moving things around.

The Setup and Issue

I was using the Delicious Brains plugin WP Migrate Pro to pull out a single site from a multisite installation and then load it up into Local. This went smoothly – the only issue was a need to deactivate some of the multisite plugins on the newly-separated site after importing it into Local.

A few days later, I had made updates on the live multisite, and so I wanted to pull those changes down to my local single site installation. This migration never completed successfully, and after the migrate quit with errors I received quite a few errors.

Errors found in error.log:

WordPress database error Table 'local.wp_2_wfconfig' doesn't exist for query SELECT name, val, autoload FROM wp_2_wfConfig WHERE name = 'allowLegacy2FA' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), include_once('/plugins/wordfence/wordfence.php'), require_once('/plugins/wordfence/lib/wordfenceClass.php'), wfCredentialsController::useLegacy2FA, wfCredentialsController::allowLegacy2FA, wfConfig::get

And

WordPress database error Table 'local.wp_2_wfconfig' doesn't exist for query SELECT name, val, autoload FROM wp_2_wfConfig WHERE name = 'debugOn' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), include_once('/plugins/wordfence/wordfence.php'), wordfence::install_actions, wordfence::runInstall, wordfence::status, wordfence::isDebugOn, wfConfig::get

Additionally, when I tried to browse to any page on the site, I got a full screen error which ended with this:

PHP Fatal error:  Uncaught Error: Call to a member function has_cap() on null in /Local-site-directory/app/public/wp-content/plugins/publishpress/modules/calendar/calendar.php:4210

(While in this case the error was attributed to the PublishPress plugin, I should note that there were a couple of different plugins named as the cause of the error.)

Upon disabling the offending plugin (or all plugins) I was able to login, but there was absolutely no admin capability – not even the ability to “Edit Profile”, which is available to users with minimal permissions (Subscriber-level access). The only option in the top-right drop down was to logout.

The Solution

First, if you get locked out of your Admin dashboard, my issue is probably not yours. There are many good resources for what to do in most other situations, but I think this one is a very thorough and well-written one (and the page isn’t full of ads). 

I tried all these options – I created a new user with admin access, I replaced my wp-login.php, wp-admin, and wp-includes files with fresh copies, I disabled all plugins, and still I had no admin access.

However, when creating the new user, I noticed that my database prefix had been modified on some usermeta entries. Instead of the prefix being wp_10_ (for example) it was wp_10_10_. 

I checked my wp_config file, and the correct prefix was indeed wp_10_. So, I removed the extra characters from the usermeta entries (the affected entries were, of course, the user_level and capabilities entries). 

Still nothing. Then, I remembered that the actual permissions for user_roles are defined in the wp_options table. Checking on that, I found that the user_roles entry in wp_options contained the same incorrect prefix that was found on the usermeta entries. I adjusted that back to its correct prefix (defined in wp_config), and access was restored!

I did then need to manually reactivate all my plugins, but both admin accounts appear to be functioning correctly.

Hopefully this helps out at least one other person – I haven’t seen many people talk about this issue specifically (either having it or fixing it), but it was a pain to track down, so I wanted to make sure that my solution was out there.