Today I learnt a new lesson – how to rename WordPress tables and lose ability to get into site admin area, and fix that back.
I tried to use WPScanner, to check performance and security. Security mainly. Here is how its dashboard looks like (just for reference):
This service is really good at providing a list of basic things to improve:
- monitor file changes in WordPress core,
- permissions,
- server response headers
- PHP version
- other security concerns.
Basically, nothing special, but it is a huge time saver to have everything in the same place with proper links to explanation articles or how-to’s, and results of your changes evaluation. Which is cool.
One of the issues was regarding WordPress tables prefix. This can be a problem only in 1 situation, when some plugin is not escaping data and passes variables (for example, a number) directly to the query’s WHERE clause. In this case hacker can do something like 1;SELECT * FROM wp_users;. And that can break the site and return all the data on a page (in some cases).
So I decided to change the prefix, just in case. I activated maintenance mode and renamed all the tables in DB to include not a default wp_ table prefix. After that I lost access to wp-admin area, with no thoughts how does this security improvement influenced the site.
It took me several minutes to understand, that I need to rename wp_capabilities option in former wp_options table as well to have for it a new prefix. But admin area was still unaccessible for me. Site itself worked ok.
And here I spent like half an hour, struggling to get the idea of the issue. As it turned out, I didn’t have permissions to build admin area menu, and thus WordPress just bailed me with such error:
Sorry, you are not allowed to access this page.
I checked all options, manually parsed usermeta – no success. After that a possible caching issue came to my mind. And that became a light bulb. Several hours earlier I have activated Redis cache on a server (with an accompanied WP plugin). And it seems wrong capabilities were cached – those, that were valid for all tables structure. So I had to run only 1 command: redis-cli flushall – and that fixed my problem.
So, in case you are doing some changes with DB and/or files – don’t forget to disable all kind of caches that you have. Just in case 🙂
Leave a Reply