Did you restore a WP STAGING WordPress backup on another website and notice that you can no longer log in to the newly restored site?
If you can not log in to a staging site, read this article
This login issue could happen with a very old version of WP STAGING and when the destination WordPress site had a different table prefix than the backup source site from which the backup was made.
This has been fixed in the latest WP STAGING version, but it required the creation of a new backup.
Suppose you have already restored your website with this older backup. You can fix the login issue by modifying the database with an administration tool like Adminer or PHPMyAdmin.
First, find out the table prefix of your production site.
Open WP STAGING > System Info
to find the table prefix in the list of variables:
Alternatively, you can find the table prefix in the wp-config.php. This is the configuration file in the root path of your WordPress installation.
For this example:
- Our source website has the prefix
wp_
- Our destination website has the prefix
wpnew_
.
Open PhpMyAdmin and access the database of your destination website where you have login issues.
Usually, all prefixes of wp_
in the WordPress core tables of a single or multisite should have been replaced wpnew_
during the backup restore process, but this failed due to the bug mentioned.
So to fix it, search for the term wp_
and replace it with the correct value wpnew_
.
The most important term you need to look for is wp_capabilities
in the table wpnew_usermeta:
This wrong value is why you can not log in to your website.
Click on Edit, and you will be able to change the value:
Rename it to wpnew_capabilities
.
If you are on a WordPress multisite, you must do this for all network subsites tables.
That’s it. You are done and can log in to your restored website now.