WP Toolkit - General Discussion

[Eleshar]

@Eleshar

FYI, if you have stumbled upon the mentioned issue on Windows Server with IIS and shared application pools, I think we have identified and fixed it. WPT 3.5.1 with the corresponding fix was published several hours ago. If you are using a different configuration, though, please let us know the details so we can continue our investigation.

PS. I know you've said that you've already given up on WordPress Toolkit, and it makes me feel real bad -- we want our product to help people, not harm their business. If you're willing to give the Toolkit a second chance, drop me a PM. Thank you!

Apologies for the delayed response. I should have clarified - only temporarily given up on WordPress Toolkit until some of the bugs can be ironed out.

The test was done on our development server: ‪Debian 9.6‬ running Plesk Onyx Version 17.9.8. It has ~200 WordPress installs on WordPress 4.9.8.

With regards to the completely wiped sites - 5 sites were affected. The database and all files in httpdocs were removed after detaching them in WordPress Toolklit. I believe these 5 sites were using a custom PHP handler.

Is there a debug log for WordPress Toolkit available that we can check?

I'll give the latest release a go tonight and let you know once it goes.

 

[trialotto]

@Eleshar,

Your feedback is valuable for both Plesk Team and all other forum members.

The suggested root cause of the problem, potentially being a custom PHP handler, is very unlikely to be the actual root cause of the problem.

Can you please inspect the 5 offending sites by

- checking that they are not MultiSites (read: MultiSites are the most unstable WordPress sites, not due to the fact that they are MultiSites, but often due to plugins used)
- checking which plugins were installed commonly in all of the 5 offending sites

and that would be a nice start to proceed with further analysis.

Thanks in advance!

Regards........

 

[Tomek]

I have mixed feelings about this update.

I see a lot of work and adding new features for which I am grateful and thank you for it.

But right now, when I click on the Wordpress tab in the Plesk panel, loading the page with the listed instances takes much more time (dozens of seconds). Also, the problem with the language that I reported earlier was not resolved.

 

[zanuda]

Apologies for the delayed response. I should have clarified - only temporarily given up on WordPress Toolkit until some of the bugs can be ironed out.

The test was done on our development server: ‪Debian 9.6‬ running Plesk Onyx Version 17.9.8. It has ~200 WordPress installs on WordPress 4.9.8.

With regards to the completely wiped sites - 5 sites were affected. The database and all files in httpdocs were removed after detaching them in WordPress Toolklit. I believe these 5 sites were using a custom PHP handler.

Is there a debug log for WordPress Toolkit available that we can check?

I'll give the latest release a go tonight and let you know once it goes.

Hello,
Have you used "Detach" operation for several WP instance at once or detached them one-by-one?
Had these instances used separate databases for each WP or it was one database for several instances?
Such behavior looks like a "Remove" operation, nor as a "Detach". Do you have a backup which you may restore and try to detach these instances once again and save an appropriate log files?
Could you please provide us more details regarding your custom php handler?

 

[zanuda]

I have mixed feelings about this update.

I see a lot of work and adding new features for which I am grateful and thank you for it.

But right now, when I click on the Wordpress tab in the Plesk panel, loading the page with the listed instances takes much more time (dozens of seconds). Also, the problem with the language that I reported earlier was not resolved.

How many WP instances do you have in WP Toolkit?
How long the listing operation lasts?
I'm going to check your report regarding language issues and see if we can increase it's priority

 

[zanuda]

Hello @zanuda

ok, I will contact the pleska support directly with detailed information.

I've found your report regarding incorrect language when WP is installed via service plan.
We've checked several scenarios and were not able to reproduce such an issue
Have you contacted Support with detailed information about your configuration?

 

[Sn M]

I'm happy to see that WP-Toolkit is getting lots of needed updates! Where was the WP-CLI file moved to in the last release? It seems to have moved places as we used to be able to run /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/wp without issue but now it returns a file not found error. We'd love to be able to use WP-CLI for managing plugin settings from the command line.

 

[IgorG]

I'm happy to see that WP-Toolkit is getting lots of needed updates! Where was the WP-CLI file moved to in the last release? It seems to have moved places as we used to be able to run /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/wp without issue but now it returns a file not found error. We'd love to be able to use WP-CLI for managing plugin settings from the command line.

You can use it as

# plesk ext wp-toolkit --wp-cli -instance-id [ID] [command] [options]

More details you can find here WordPress Toolkit in Plesk

 

[Sn M]

You can use it as

# plesk ext wp-toolkit --wp-cli -instance-id [ID] [command] [options]

More details you can find here WordPress Toolkit in Plesk

Thanks, however, LiteSpeed cache plugin WP-CLI options don't work with that command. Can you please tell us the new location of the file?

'lscache-admin' is not a registered wp command. See 'wp help' for available commands.

 

[Tomek]

I've found your report regarding incorrect language when WP is installed via service plan.
We've checked several scenarios and were not able to reproduce such an issue
Have you contacted Support with detailed information about your configuration?

Hi zanuda,

did you check the scenario that we talked about in a private forum conversation?

 

[MV-YN-NL]

The block author scan which was introduced in version 3.5.0 blocks (403) the Wordpress built-in export functionality. The scan blocks the string "author=" and when posts and/or pages (or everything) are exported this string is present in the url. You might want to consider excluding "wp-admin/export.php" (or wp-admin/ in general) from the block author scan.

I fixed it for now by disabling the scan.

 

[zanuda]

The block author scan which was introduced in version 3.5.0 blocks (403) the Wordpress built-in export functionality. The scan blocks the string "author=" and when posts and/or pages (or everything) are exported this string is present in the url. You might want to consider excluding "wp-admin/export.php" (or wp-admin/ in general) from the block author scan.

I fixed it for now by disabling the scan.

Thank you for this information.
I've just checked workflow as you reported and we confirm a bug. It will be fixed in one of the nearest releases.

UPDATE: issue number EXTWPTOOLK-2397

 

[custer]

Hi everyone,

We have released WPT 3.6, here's the changelog:

• [+] Cloning UI was redesigned for improved responsiveness and consistency.
• [+] The UI for copying data (a.k.a. syncing) between installations was redesigned, also for improved responsiveness and consistency. As a side-effect, the procedure formerly known as Sync was renamed to Copy Data, so users should not be confused about what exactly is going on.
• [+] Users can now clone WordPress sites to arbitrary subdirectories on target domains.
• Improved the reliability of screenshot generation for WordPress installations, Part II.
• WordPress Toolkit no longer leaves various useless entries in the logs.
• Improved the handling of broken plugins and themes, reducing the number of esoteric error and warning messages shown to users.
• Install button now has the focus by default on the WordPress installation form, so hitting Enter after opening the form should immediately launch the installation process.
• Improved the performance of WordPress installation list if it has a lot of WordPress installations.
• Improved WordPress installation list for viewing on mobile devices.
• [-] WordPress Toolkit database no longer becomes inconsistent when a subscription with two or more WordPress installations is removed. (EXTWPTOOLK-2250)
• [-] Smart Update on Windows servers now checks pages other than the main page. (EXTWPTOOLK-2189)
• [-] Resellers can finally access WordPress Toolkit via the corresponding link in the left navigation panel. (EXTWPTOOLK-1472)
• [-] Users who remove all WordPress installations on the last page in the list of installations are no longer forced to look with despair at the empty screen (unless it was the only page in the list, then yeah). (EXTWPTOOLK-1750)
• [-] Select All Updates checkbox on the Updates screen is no longer confused about what it should select after several updates were already applied. (EXTWPTOOLK-2175)
• [-] Toolbar buttons above the list of WordPress installations no longer lose their titles after users minimize then maximize the left navigation panel. (EXTWPTOOLK-1394)
• [-] Server Administrator can now manage the Disable unused scripting security measure for WordPress installations on locked subscriptions not synchronized with a Service Plan. (EXTWPTOOLK-2178)
• [-] Disable unused scripting languages security measure can now be properly applied to WordPress installations on subdomains and additional domains. (EXTWPTOOLK-2323)
• [-] The username and email for WordPress administrator are properly updated in realtime during the WordPress installation procedure if you are changing the destination domain and it has a different owner. (EXTWPTOOLK-2396)
• [-] WordPress Toolkit now properly shows the theme screenshot if it is in the .jpg format (theme screenshots are displayed if WordPress is installed on a domain that does not resolve yet). (EXTWPTOOLK-1907)
• [-] Hotlink Protection And Additional Nginx Directives: Hotlink Protection security measure no longer overrides the additional nginx directives on a domain. (EXTWPTOOLK-2305)
• [-] Hotlink Protection And Mixed Case Domains: Hotlink Protection security measure now properly works for domains with mixed case names. (EXTWPTOOLK-2337)
• [-] Hotlink Protection And Expire Headers: Hotlink Protection security measure no longer disables Expire headers. (EXTWPTOOLK-2321)
• [-] Update tasks should no longer disappear with cryptic Unable to find the task responsible for the currently running update process message. (EXTWPTOOLK-2231)
• [-] WordPress Toolkit now properly cleans up its database when a subdomain with WordPress installation is removed in Plesk. (EXTWPTOOLK-2454)
• [-] Block access to potentially sensitive files security measure no longer prevents File Sharing feature in Plesk from working. (EXTWPTOOLK-2279)
• [-] Dramatically reduced the number of false positives for Block access to potentially sensitive files security measure. (EXTWPTOOLK-2247)
• [-] Clone procedure now correctly detects and properly modifies certain encoded URLs in the WordPress database. (EXTWPTOOLK-1789)
• [-] Cloned WordPress installations should no longer share their cache with the source installation (we know sharing is caring, but not this time). (EXTWPTOOLK-1773)
• [-] If WordPress Toolkit cannot change the database prefix for all tables when applying the Database table prefix security measure, it will properly roll back the changes to prevent website from being broken. (EXTWPTOOLK-2347)
• [-] When WordPress is installed in a subdomain, WordPress Toolkit no longer offers to install it in a subdirectory by default if the main domain already has WordPress installed. (EXTWPTOOLK-2252)
• [-] WordPress can now be installed via CLI into a path containing multiple directories. (EXTWPTOOLK-2260)
• [-] The error message displayed when users try to install WordPress on a domain without an available database now looks nicer. (EXTWPTOOLK-2440)

 

[GGCoffee]

Just started using the updated WP Clone feature, amazing improvement. It's lightning quick on selecting the target domain, woohoo.

 

[Bitpalast]

@custer The issue reported in
WP Toolkit cloning fails, same symptoms as in EXTWPTOOLK-456 (formerly resolved 03/31/2017)
that cloning suddenly requires proc_close() and proc_open() again, is back in release 3.6.2-1609.
It formerly existed in EXTWPTOOLK-456 (resolved 3/31/2017), came back up in release 3.6.0-1601, was resolved in 3.6.0-1603 last Saturday/Sunday, now it is here again in 3.6.2-1609.

I will refresh the bug report again, but would really be happy if this could please be resolved quickly, because it affects all secure hosting accounts where the proc_open() and proc_close() functions are disabled.

 

[custer]

Hi Peter,

Thanks for letting us know -- we're looking into that. Will post an update as soon as we have more specifics.

 

[Bitpalast]

It seems that we have run into several issues with the latest toolkit update on a Plesk 17.5 installation.

a) On a Plesk 17.5 hosting licence we can no long activate/deactivate maintenance mode. The system asks to buy the extension (it is/was included with the licence; reloading the licence did not solve the issue):



Edit: However, when trying to toggle the setting, it can be toggled. So maybe only the display is wrong?

b) On the same system: When we newly install Wordpress, first the /usr/local/psa/var/modules/wp-toolkit directory had wrong permissions (0700) which resulted in an error "plesk filemng failed filemng error occurred during /bin/cp command". We have updated the permissions to 0755 which now allows new installations of Wordpress by the toolkit, but with two strange errors:

b1) in /var/log/plesk/panel.log:


b) on the screen the system switches to the domain list overview page and displays a "permission denied" during the first phase of the WP installation like



It looks as if the Wordpress instance is installed correctly though. File system repair did not yield anything wrong either. Neither did plesk repair db make any difference. Permissions of the sqlite file are set correctly (as on other systems), ownerships are the same, too. The instance can be cloned and removed without any issues, too. I'd like to know though, what the Permission denied error is and how this can be solved.

 

[custer]

I will refresh the bug report again, but would really be happy if this could please be resolved quickly, because it affects all secure hosting accounts where the proc_open() and proc_close() functions are disabled.

Update: I can confirm this is a bug, and we're planning to fix it ASAP in WP 3.6.3.

Regarding your other reports, @Peter Debik -- we'll check it all first thing tomorrow. Will keep you updated. Thanks!

 

[zanuda]

Hello Peter, have you contacted our support team with the permissions problem? I've just seen ticket with most likely the same problem as yours.
If yes, then your problem should be solved already
If not, please check the following:
1. Run
# plesk repair fs -n
to check if it reports any problems;

2. Check the "umask" permissions. It must be as the following:
[root@localhost controllers]# umask
0022
[root@localhost controllers]# umask -S
u=rwx,g=rx,o=rx
It should be updated running the following command:
# umask 022
* The following articles can be usefull to set the new umask value permanently.
How to permanently change umask value from 0002 to 0022?
How to change umask mode permanently?

3. Run the Plesk utility to fix file system issues:
# plesk repair fs
Plesk Repair Utility: File System

After that please check how WordPress Tollkit works and let us know the result.

 

[Bitpalast]

Not my ticket :-(

No issues with umask, everything fine.

Tried repair -fs before, but no issues but the one described in
plesk repair fs fails to check permissions on /var/lib/psa/dumps: ERR [util_exec] proc_close() failed with exit code [1]
But workaround is o.k. and only related to /dumps location.
There are warnings regarding user content directories and files, but they target file permissions inside user websites. Nothing that is related to Wordpress or higher level directories.

More likely a WP toolkit issue, because it never showed up before the update to 3.6.0-1601.