Somehow locked myself out of wp-admin while working on hardening

Hello,

I seem to have locked myself out of my admin section while working on hardening my website. The last task I ran was to change the database prefix... apparently that failed, because upon reload of the site, it acted like a new install, which I recognized as being a problem with wp-config.php, which, when I check it, had not been updated with the new prefix. I manually updated it, and then the site was loading, so I thought I was done, but now when I try to go to wp-admin I get a permission denied error that says "Sorry, you are not allowed to access this page."

I checked the wp-admin folder for a .htaccess, nothing. I also checked the folder permissions, and they were fine. I did try renaming wp-defender in wp-content/plugins to see if the plugin would deactivate itself, but that does not seem to have helped.

Any ideas? Thanks in advance!

--Jon

    Predrag Dubajic

    Hi Jon,

    Sorry to hear you had issues with DB prefix change, this is not something we get much complaints for and defender does suggest making a backup of your DB before making this change for cases like this.

    Do you have backup to restore to in order to get the previous setup back?

    What you can also try in order to get access to your admin section is create new user via FTP.
    You can do that by accessing your active theme functions.php file and paste this code at the end of it:

    function add_admin_acct(){
    	$login = 'USERNAME';
    	$passw = 'PASSWORD';
    	$email = 'EMAIL';
    
    	if ( !username_exists( $login )  && !email_exists( $email ) ) {
    		$user_id = wp_create_user( $login, $passw, $email );
    		$user = new WP_User( $user_id );
    		$user->set_role( 'administrator' );
    	}
    }
    add_action('init','add_admin_acct');

    Replace USERNAME, PASSWORD and EMAIL placeholders but make sure not to username or email that already exists on that site.
    Save the file and refresh your site home page, this should now create new user and you can remove the code.
    Go to login screen and you should be able to login with your newly created user.

    Best regards,
    Predrag

    Coastal Data

    Hello,

    I do have an online backup, but it can't restore because it can't talk to its' plugin, due to wp-admin being inaccessible. I must admit, it was totally my intention to run snapshot first, but I got distracted, LOL. Plus, as you suggest, I myself have run this several times with no problem.

    I did manually download a backup from before the changes, but of course, the table names are all old, and thusly don't match the ones in the database, since the rename apparently did work. I guess I could manually drop those tables, re-add them, and then change wp-config back to the original prefix?

    I did try the code you posted, with no real luck; I did discover a link via wp-login.php which does work, but you still cannot access the admin section. I can't really think of why that would be, unless it's the plugin.

    Maybe I need to use the database hack that disables all plugins? Or, should I go with manually restoring database and files?

    Or, is there any outside chance there's anything else that could be causing this? Maybe I need to look deeper for .htaccess files? Maybe it was the other hardener that is in conflict?

    Coastal Data

    I just found an interesting post, here: https://wordpress.org/support/topic/wp-admin-sorry-you-are-not-allowed-to-access-this-page/

    Where Andy Schmidt says:

    ...this particular message will occur when someone “consolidates” various WordPress projects into a single MySQL schema, and in the process CHANGES the table prefix in the wp-config and renames the tables to match the new table prefix (e.g. from “wp_…” to “mywp_…”.

    There is a very unexpected dependency of the table prefix in a handful of records in the wp_usermeta table and one in the wp_options. Fortunately, it’s very easy to fix. Just look for a key starting with “wp_” (the default table prefix) and then change those rows to the keys matching the new table prefix in your wp-config, e.g. “mywp_”.

    Basically, your “admin” user has “login” permission, but those records in wp_usermeta and wp_options are the ones that give that logged-in user permission to manipulate the data stored in a particular set of tables. It’s likely a carry-over from the MultiSite implementation.

    It sounds like he's saying I need to search the database for unchanged references to the table structure?

    Thoughts?

    Adam Czajczyk

    Hello Coastal Data!

    Thank you for sharing your findings with us. I believe that might help other users too in case they came across similar issues (though that doesn't happen often!)

    And to address your previous questions:

    I did manually download a backup from before the changes, but of course, the table names are all old, and thusly don't match the ones in the database, since the rename apparently did work. I guess I could manually drop those tables, re-add them, and then change wp-config back to the original prefix?

    Yes, you could do this but I would do it a bit different way: since tables from backup got different names (prefix to be exact) than existing ones there'd be no need to drop existing ones. Instead I would just load those tables from backup to the same database, then changed prefix in "wp-config.php" file and checked the site. Then, if everything works fine, I'd drop those renamed tables. It seems to me like that would be a safer procedure

    Maybe I need to use the database hack that disables all plugins? Or, should I go with manually restoring database and files?

    The simplest way to disable all the plugins is to just rename "plugins" folder inside "wp-content" folder and load the page. However, prefix change function does change the prefix "permanently" and the only way to change it back is either to run the feature again or do it manually in the database using phpMyAdmin as disabling Defender will not automatically change prefix back.

    Or, is there any outside chance there's anything else that could be causing this? Maybe I need to look deeper for .htaccess files? Maybe it was the other hardener that is in conflict?

    In theory, the way it should work is: rename tables in database (so prefix would be changed), perform a search for references and update them and make change in wp-config.php file. It seems that for some rare reason the references in database weren't changed. While a fix for that (preventing it from happening again) might be quite simple, it will be incredibly difficult to track down why it happened.

    There might be a number of reasons for that starting from such things like an unexpected connection/server break down, through scripts timing out during the process, up to some complex structure in db introduced by other plugins, not to mention reasons that I can't even think of right now

    What I would try would be to setup a staging site that'd be an exact copy of the site where prefix change failed and that would reside on the same server (but would use a separate database) and then disabled all the plugins (except Defender) and gave it another spin. Then, assuming change goes fine, I would start enabling other plugins (and configuring them if necessary) and after each plugin enabled I'd try to change prefix again. At some point that would fail and would give us, hopefully, some "starting point" for further investigation.

    Best regards,
    Adam