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

[zanuda]

Did your customers install WordPress via WP Toolkit "Install" button or via APS packages (domain- Applications)?

 

[Robin Scott]

I'll have the old install docs somewhere... I wrote them. This is a 1 client server, but with a heap of installs. Its a corporate client.

 

[Aleksey Filatev]

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!

WordPress Toolkit unable to retrieve administorator password from existing instance, because only hash of this password stored in WordPress instance database. But WordPress Toolkit is able to set new administrator password. In this case toolkit will remember entered password and after that automatic dashboard login feature will work properly. Could you please check errors in a browser console while trying to set new adminisotrator password? And also could you please check errors in the Plesk debug log (/var/log/plesk/panel.log) while trying? It looks like a bug but we need to investigate is this a frontent or backend issue.

Also would be very useful if you can screencastify your browser windows while trying to change WordPress Administrative password via WordPress Toolkit.

 

[Robin Scott]

Its working to install new WordPress sites. The issue is with pre-existing WP sites (not all of them - strangely there are 2x which were there already which work - both have the wp_ database prefix (not saying that's the cause, just something they have in common!))...

The other server I tested is in the same environment and took practically the same updates and worked.

 

[Robin Scott]

I'll get some screencasts - can I email you these? They will almost certainly reveal private information...

 

[Robin Scott]

`
ERR [1] '/usr/local/psa/admin/bin/filemng' 'alexbar' 'exec' '/mnt/storage/www/[SITENAME].co.uk' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/wp' '--path=/mnt/storage/www/[SITENAME].co.uk/httpdocs' 'admin-username' 'change' '[USERNAME]' '--username=' failed with code 134.
`

I have replaced sitename and username, but these are both correct. Looks like wp cli is not working there, this error 134 is I think related to trusting the certificate authority.

In this case, these are secured by Let's Encrypt using the Plesk extension. Actually I can see another error in the Plesk log which relates to this.

 

[Robin Scott]

In fact, it looks like this WP CLI command is malformed - its trying to change the admin username, but not supplying a new one?

 

[Robin Scott]

Hey I found the issue here...

Site which doesn't work:



Site which does work



Changing this setting to on, allows password to be reset.

Note this was "like this before" and "worked before" so maybe will help in future if someone else runs into this issue. It was a bit of a weird one to chase back - once I found those Plesk log files for this (thanks @Aleksey Filatev - I'm not a big Plesk admin!), it became way clearer what (wasn't) working here... didn't realise it was basically firing wp cli from WPT... I did that my side a bit, checked hosting settings and found this one!

I can set this across all sites and resolve. Phew.

 

[Robin Scott]

hmm no - it doesn't resolve it for all of them, just the one site I was looking at...

 

[Robin Scott]

So WP CLI, this works to change admin password in one of these failed sites - couldn't the "change password" code WPT uses do it this way?

plesk ext wp-toolkit --wp-cli -instance-id 199 -- user update [USERNAME] --user_pass="[PASSWORD]"

The code which is attempted by the WPT is failing, as above. Still happening. It was a false positive that SSI allowed this to work - it was a staging copy which "just works". I still don't know exactly why, though the error coming from the failing sites suggests a "certificate trust" issue.

 

[Robin Scott]

In fact, why is the CLI code Plesk calls attempting to change the admin username - that's not what's being attempted here?!

 

[Robin Scott]

Hi,

This issue is still persisting despite the new version being installed.

 

[Robin Scott]

`[2018-09-03 17:03:19.923] ERR [1] '/usr/local/psa/admin/bin/filemng' 'SITENAME' ' exec' '/mnt/storage/www/SITEDOMAIN.co.uk' '/usr/local/psa/admin/plib/modules/wp -toolkit/vendor/wp-cli/wp-cli/bin/wp' '--path=/mnt/storage/www/SITEDOMAIN.co.uk /httpdocs' 'admin-username' 'change' 'CORRECTUSERNAME' '--username=' failed with co de 134.

stdout:


stderr:
Need to specify new administrator username and password.
{"err_code":20102,"err_message":"Need to specify new administrator username and password."}
`

Note this is not passing - apparently - the new username (potentially also the password is missing). I am able to change passwords using WP CLI on this system.

 

[Robin Scott]

Note '--username=' should be '--username=CORRECTUSERNAME' also we should have --user_pass=SOMEPASSWORD in there too?! Perhaps not in this log, but we should be using the change password, not the change username direction. We're not attempting to change the username here. I think its related to the update to allow changing the username - because this did work before then.