You’ve restored your WordPress to the same or to another site, and now you notice that you can not log in to the newly restored site any longer.
A WP STAGING | PRO bug could cause login issues 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 | PRO, but it required the creation of a new backup.
If you have already restored your website with this older backup, you can fix the login issue by doing a few modifications with a database 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 by wpnew_
during the backup restore process, but this failed due to the mentioned bug.
So to fix it, simply 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 the reason 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, too.
That’s it. You are done and can log in to your restored website now.