WordPress Toolkit - Lost (and can't update) Admin Logins

[Robin Scott]

Hi All,

Have a Plesk server with a lot of WordPress instances in it using the WP Toolkit from Plesk for a long time.

Running latest version - 17.8.11 - and it looks as though this has "disconnected" admin users from the WordPress instances. Clients use these to login across a selection of sites.

It looks like this on all sites:



It should show "login" in this box.

When clicking "Setup" we can't update password, instead it shows:



I wonder if we need to update a Plesk table somewhere to connect these back together.

Note that adding a new WP instance does work as expected - its like there's a table which did not copy on latest panel update?

 

[Robin Scott]

Just opening this one up as this client has purchased Plesk through a reseller, and therfore, I think I will get more joy looking at recent changes to this Plesk extension. There are a couple which seem to be relevant relating to administrator name. This site was moved to mounted storage, which may easily have not updated when running the relevant Plesk script, so I wonder if this is the root cause here. Could use a pointer on where WP Toolkit stores the relevant information.

 

[Robin Scott]

So just digging about in the Plesk MySQL databases, I can see that the new sites I added to test features have gone into a DB prefixed "wp_" whereas the old ones (which work in every way except the admin login) are in a database prefixed "wordpress_". This seems relevant:

 

[Robin Scott]

The client in above setup added a new site which had db prefix wordpress_ and this suffered from the same issue. I had a good look in the config files to see if this is stored anywhere, and tbh I'm not sure where this would be set.

 

[Robin Scott]

So to clarify - sites which have a database prefix of `wp_` work to allow login and password reset from the WPT in Plesk. Sites which have db prefix of `wordpress_` do not. I strongly suspect changing the database prefix will have no impact here, but I wonder if this is related, insofar as there must be some file somewhere, in Plesk, which is failing to connect to the relevant database for *this one function* that being the administrator login.

 

[Robin Scott]

These sites worked before - they showed "login" for each install. Now that is missing, and it shows "setup" as below... but it worked before. So something changed. What changed? A Plesk update and a WPT update. Nothing else on this system has been altered in this timeframe.



Site which work don't look like that. They look like this:



Note the "Log in" option which is missing in example 1 (and 194 other sites which had this before a recent update).

 

[zanuda]

Thank you for such a detailed feedback. We need some time to deeply investigate this issue. I'll try to reproduce such situation and will come back to you for an additional details if needed.

 

[Robin Scott]

Thanks - there is a workaround in place here, but its clunky and involves users triggering password reset which result in a lot of security emails coming at me on a regular basis

 

[Robin Scott]

Thank you for such a detailed feedback. We need some time to deeply investigate this issue. I'll try to reproduce such situation and will come back to you for an additional details if needed.

I got another server in same setup which is due Plesk and WPT updates - it only has a few old WP installs on it (its a staging server) so am gonna see if I can replicate my side which update makes this happen.

 

[Robin Scott]

Works fine in this other server too. I wonder if it may be related to MySQL version, which I think was changed in the site where this is not working to be MySQL 5.7 per this some time ago: How to upgrade MySQL 5.5 to 5.6/5.7 or MariaDB 5.5 to 10.0/10.1/10.2 on Linux the setup is otherwise similar.

 

[Robin Scott]

MySQL version in the failing system is

5.7.23-1.el6

 

[zanuda]

This shouldn't matter because WordPress Toolkit uses it's own sqlite database to store data about installed WP instances.
Could you please check permissions for this database, it should be like the following:
# ls -la /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3
-rw------- 1 psaadm psaadm 200704 Aug 10 05:32 /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3

 

[Robin Scott]

Yep that's exactly what it looks like!

 

[Robin Scott]

I do feel it is related to the database prefix, which is changed. Sites which don't work are prefixed `wordpress_` sites which do work are prefixed `wp_` this got changed with the same update.

 

[Robin Scott]

If we had a mechanism to update the database prefix (actually the database name at all) here, then it would be possible to be more sure, as we could effectively flush it (same as for database user).

 

[Robin Scott]

When I say here, I mean here:



If the option existed in WPT to change the database name, this would allow this issue to be at least ruled out. I don't think I'd be able to easily update the information in that wp-toolkit.sqlite3 file myself, otherwise.

 

[Robin Scott]

I'm going to remove the WPT extension, make sure that config file is gone, then reinstall and scan. This should rule out a heap of things.

 

[zanuda]

In general, reinstallation of WP Toolkit should help you resolve this issue.
Had you tried to create test domain and install WordPress there? Does this WP instance have the same problem with password changing?

 

[Aleksey Filatev]

If the option existed in WPT to change the database name, this would allow this issue to be at least ruled out. I don't think I'd be able to easily update the information in that wp-toolkit.sqlite3 file myself, otherwise.

Database name here - is the name of the WordPress instance database, specified in wp-config.php. It can not be changed via WordPress Toolkit. But if you somehow change it manually, toolkit will know about it and display updated info.

 

[Robin Scott]

Installing a test domain - WPT works when I do it, but when the clients do it, they have anecdotally managed to install "not working" versions.

Removing and reinstalling WPT does not work - the login is still missing, and update password does not work after the scan. Its strange, because every other element works just fine - so there's no issue with any other element. I can't figure out what's different about these "old" installs!