Hi James,
Thanks for the suggestion. Here’s the content:
The error was:
YOU DO NOT HAVE SUFFICIENT PERMISSIONS TO ACCESS THIS PAGE.
As we migrate, we usually take the old database and do a few search and replace operations:
1. check siteurl and replace the old url with the new one.
2. search for “home” and find out what the absolute path is for the server environment. Replace the old path with the new (e.g., “home/acctname/public_html/” gets changed to “home/acctname/www.yourdomain.com/” in the case of lunarpages to dreampress).
3. check wp-config in the old environment vs. new one for table prefix. In our case the old environment was “wp_” and the new environment’s table prefix was “wp_acctname_”. I did a search and replace and replaced ‘wp_ with ‘wp_acctname_
After importing the new database, the web site looked great from the front end, but as soon as we tried to log into WordPress we got that dreaded message.
After googling it, there were a bunch of suggestions we tried, such as:
1. check the user’s wp_capabilities and make sure they don’t have the wrong type of quotes
2. check the user’s wp_user_level
3. look for corrupt tables in the db
But none of those worked. In the end, it was an issue related to my step #3 that I didn’t do correctly. My new environment had that special table prefix, and I hadn’t done the search and replace properly.
We had a look around and found the issue, and it relates to the various places the table prefix shows up in the database.
THE DATABASE TABLE PREFIX IS NOT JUST USED IN THE DATABASE TABLE NAMES. IT’S ALSO USED IN DATA!
If that data isn’t also changed, a permission error happens because the returned values will be empty.
Specifically, these changes fixed the issue:
In the table: wp_acctname_options
there was an option named: wp_user_roles
that had to be renamed to use the prefix: wp_acctname_user_roles
And in table: wp_acctname_usermeta
there was a meta_key: wp_capabilities
that had to be renamed to use the prefix: wp_acctname_capabilities
And there were some other meta_key names in the user_meta table that started with wp_ and were expecting the same treatment, so I changed those as well. But these 2 were the critical ones preventing logins from happening.
After making those changes, the login worked again.
