Were you just locked out of your WordPress blog’s administration area? When you try to access the admin area, do you see the error message, “You do not have sufficient permissions to access this page”? Did you just recently run a prefix changer to tighten the security of your blog?

If the answer to all of these questions is “yes”, then this may be the solution that you are looking for. We have seen this error message for a few different issues, such as with an old, outdated plugin that is no longer compatible with a new version of WordPress, but for that problem the message only displays when you try to access the plugin’s setup page. The issue that we are describing locks a blog owner out of the entire admin area. The only thing that displays on the screen is the error message.

We have seen this twice after we hardened a blog against attacks by changing the table prefix using the prefix changer built into WP Security Scan. After digging into this issue, we discovered that the root of the problem is due to an apparent bug that does not change all of the database table name references in the wp_usermeta table. While all of the table names do get changed, one or more of the references to the new table names is skipped.

If you run into this problem, use the phpMyAdmin utility or whichever database management utility your hosting company provides in your site’s control panel to access the wp_user_meta table.

1. Open the WordPress database.

2. Make a backup of the database, just in case something gets screwed up. An easy way to create a quick emergency backup within phpMyAdmin is to select a database, click on the Operations tab and use the “Copy database to” utility to make a copy of your database under a different database name. Make sure that “Structure and data”, “CREATE DATABASE before copying” and “Add AUTO_INCREMENT value” are all selected. Enter a name for the copy of the database. If you do run into a problem, you can simply change the database name in wp-config.php to switch to the copy of the database. Another good idea when working with a small table is to print out a screen shot that shows all of the values and data as they existed before you make any changes.

3. Select the user_meta table. Because you just changed the table prefixes, the “wp_” prefix on the user_meta table name will reflect the new prefix. Just look for a table that uses the new prefix along with “usermeta”.

4. Use the browse tab and scan through the meta_key column and look for any references to the old table names. I usually find the following six, but there could be more or less, depending upon which version of WordPress you are using and how your have your admin users configured. There are not very many rows in this table, so it is easy to scan. If you have more than one user account set up, your will find that some of these columns are duplicated for each user.

wp_autosave_draft_ids
wp_capabiliates
wp_metaboxorder_post
wp_user_level
wp_usersettings
wp_usersettingstime

For the WordPress blog that we were working with in the example show above, two users (see user_id column) were configured. The critical data field that was causing the error for us and preventing us from logging in was wp_capabilites, which sets the user level for each admin user. We changed both instances of wp_capabilites in the meta_key column to wp_qs1_capabilities and we could then log in once again.

As shown above, the wp_usersettings and wp_usersettingstime values had also not been changed by the WP Security Scan prefix changer. However, after simply changing wp_capabilites, we logged in and found that WordPress had automatically created new rows for these values using the new prefix. It looks like other values that could be important include wp_user_level and wp_autosave_draft_ids. If you are still experiencing unusual behavior with the admin section after changing the wp_capabilites value, it is possible that the other two values also need to be changed to reflect the new prefix.

It may not be necessary to change every instance of the old table prefix in the meta_key column because it appears that WordPress will create some of these as needed. If you do change other meta key values, just be careful that you are not duplicating a row that already exists. The important part is that only one of each meta key value should exist for each user (user_id). You will find that some users have meta_key references assigned that do not exist for other users. That should be okay because some of these reference keys are created only as they are needed.

If you have an existing blog and you are hardening it and you wish to avoid this WordPress error, you might want to try the WP Prefix Table Changer found on the BlogSecurity.net site. It is a plugin that allows you to change the table prefix much in the same fashion as the WP Security Scan tool, but we have not experienced any problems using that plugin.