WP Toolkit - General Discussion

[custer]

Hi everyone,

The purpose of this thread is to announce WordPress Toolkit releases and to discuss them.


We have released a new version of WordPress Toolkit -- v2.1.1. It features in-built maintenance mode management, ability to protect website access with a password, new installation flow for easier and more visible installation from Websites & Domains screen, and other improvements + fixes. The full release notes:

• Users can now protect their WordPress websites with a password. Anyone browsing a password-protected website receives the “401 Unauthorized” response unless they provide the correct login and password.
• Users can now manually put their WordPress websites into maintenance mode. Users are also able to edit the placeholder page that is displayed to those visiting a WordPress website under maintenance.
• The “WordPress register” event can now be used with Plesk event handlers. The event triggers every time a WordPress website is registered in the WordPress Toolkit after performed scan for WordPress installations or after installation via the Application catalog.
• The WordPress installation procedure was simplified and streamlined.
• The procedure for the installation of WordPress plugins and themes on newly created WordPress websites was simplified and streamlined.
• Under certain circumstances, the administrator’s webmail address was displayed incorrectly in WordPress Toolkit. (EXTWPTOOLK-490)
• Importing a WordPress website resulted in an error if no hosting was configured for the parent domain. (EXTWPTOOLK-558)
• In case of available major updates, administrators of WordPress websites with minor automatic updates enabled received daily notifications about installed updates even though these updates were not actually installed. Meanwhile, notifications about available updates were not delivered. (EXTWPTOOLK-561)
• Cloning WordPress websites failed to preserve the source website’s automatic update settings. (EXTWPTOOLK-600)
• If the subscription was configured to use PHP 5.3 or earlier, WordPress Toolkit ( WPTK ) erroneously detected subscription’s WordPress instances as broken. (EXTWPTOOLK-632)

 

[BELLUM Labs.]

In Plesk 12.5 WordPress Toolkit is automatically updated?
I'm not able to give a global reseller access to WP Toolkit: is there a URL that allows to the reseller to manage ALL his WP installations?
Many thanks

 

[custer]

WordPress Toolkit is an extension starting with Plesk Onyx and it's updated automatically. Plesk 12.x installations do not receive any WordPress Toolkit updates except critical security fixes. You have to upgrade to Plesk Onyx if you want to give a reseller the ability to access WP Toolkit and manage all his WP instances from a single place.

 

[Mark Bailey]

Hi all, this is my first post as we're moving over to Plesk from cPanel! We're a WordPress-specific host, so the Toolkit is especially great. A couple of suggestions based on our testing:

#1: The Toolkit only appears to install a vanilla installation of WP. However, various hosts sometimes need to install their own customized WordPress install, for example with preinstalled themes, plugins and settings. We like to preinstall Jetpack and a caching plugin, preconfigured with the right settings for our servers, and already activated. It would be great if we had the ability to install our own custom version of WP.

In lieu of that, it looks like Plesk Event Handlers might be able to do some of that, but I can't find any reference that shows me enough about the syntax. Would anyone be kind enough to share any examples on operations that would move a plugin into place (either from the repository or our own) and activate it if possible?

#2: It's really cool that users can install and otherwise manage plugins and themes right from Plesk. However, one missing function is the ability to upload. Many people use premium plugins and themes, so it would be great if those could be installed this way too.

Keep up the great work!

Mark

 

[DerDanilo]

Currently we experience the issue (since some weeks) that the WP Toolkit Auto-Update function for all website switches itself to "off" every day.
Maybe this is related to the fact that it does it's maintanance and then changes this setting back, though I've tested to run the cron jobs related to WP-toolkit and and it seems that this is not the issue.

If this does not stay with auto-update it pretty useless, please fix this asap. For now the WP-Toolkit seems still more beta then stable. It still has a lot unresolved smaller issues.

Thanks!

 

[custer]

Hi Danilo,

First off, thank you for your feedback!

Currently we experience the issue (since some weeks) that the WP Toolkit Auto-Update function for all website switches itself to "off" every day.
Maybe this is related to the fact that it does it's maintanance and then changes this setting back, though I've tested to run the cron jobs related to WP-toolkit and and it seems that this is not the issue.

If this does not stay with auto-update it pretty useless, please fix this asap.

I'm not 100% sure what you mean, so let me clarify how automatic updates work in WPT first. When an instance is added to WPT, we set its WP_AUTO_UPDATE_CORE constant in wp-config.php to false and update the instance using WPT and wp-cli. In other words, the state of this constant is not indicative of the actual status of automatic updates for this instance.

Additionally, if you change this constant manually in wp-config.php from false to minor or true, and you had automatic updates set to off in the WPT itself, we will detect this and change the WPT automatic update settings accordingly.

If, however, you or your customers do not modify this constant in the wp-config.php file and your automatic update settings are being reset, please let us know so that we could look into this issue.

For now the WP-Toolkit seems still more beta then stable. It still has a lot unresolved smaller issues

I'm sorry to hear that your experience with WordPress Toolkit isn't perfect, Danilo. We're constantly working on improving it, and we would really appreciate if you could tell us more about these smaller issues -- even though they're smaller, they still count. If you don't want to type everything down, we can set up a call, if that works for you.

Thanks!

 

[custer]

Hi Mark,

Hi all, this is my first post as we're moving over to Plesk from cPanel! We're a WordPress-specific host, so the Toolkit is especially great. A couple of suggestions based on our testing:

I'm happy to hear that the Toolkit is helpful for you, guys!

#1: The Toolkit only appears to install a vanilla installation of WP. However, various hosts sometimes need to install their own customized WordPress install, for example with preinstalled themes, plugins and settings. We like to preinstall Jetpack and a caching plugin, preconfigured with the right settings for our servers, and already activated. It would be great if we had the ability to install our own custom version of WP.

This is a feature that quite a lot of people have being asking us about, and we have it on our roadmap. There is no specific ETA yet, but it should definitely be available later this year. We're also planning a tight integration with Jetpack, since we're partnering with Automattic.

In lieu of that, it looks like Plesk Event Handlers might be able to do some of that, but I can't find any reference that shows me enough about the syntax. Would anyone be kind enough to share any examples on operations that would move a plugin into place (either from the repository or our own) and activate it if possible?

FYI, you can use wp-cli to activate your plugins automatically. I'd suggest to start with this: wp-toolkit: WordPress Toolkit, then move on to wp-cli documentation.

#2: It's really cool that users can install and otherwise manage plugins and themes right from Plesk. However, one missing function is the ability to upload. Many people use premium plugins and themes, so it would be great if those could be installed this way too.

This is also something that we want to implement in the near future -- stay tuned for the WPT updates! We are releasing them on a monthly basis, so you'll get new features each month.

Keep up the great work!

Mark

Thank you Mark, and don't hesitate to contact us if you've got questions or feedback!

 

[DerDanilo]

I'm not 100% sure what you mean, so let me clarify how automatic updates work in WPT first. When an instance is added to WPT, we set its WP_AUTO_UPDATE_CORE constant in wp-config.php to false and update the instance using WPT and wp-cli. In other words, the state of this constant is not indicative of the actual status of automatic updates for this instance.

Additionally, if you change this constant manually in wp-config.php from false to minor or true, and you had automatic updates set to off in the WPT itself, we will detect this and change the WPT automatic update settings accordingly.

If, however, you or your customers do not modify this constant in the wp-config.php file and your automatic update settings are being reset, please let us know so that we could look into this issue.

Thanks for your reply. You understood the problem more or less correctly. I tried all scenarios that I could think of to reproduce the problem. I will keep trying. The info you provided might help. It's just weird that this setting is disabled on all pages at once.

 

[custer]

Danilo,

We can take a careful look at your server, if you'd like, and figure out what's wrong. PM me for details.

 

[custer]

Hi everyone,

We've released a small update for WordPress Toolkit that fixes a bug reported to us by @Danilo Schwabe and @Koen Verbruggen (thanks again, guys!). This is the changelog for WPT 2.1.2:

[-] Repeatedly scanning a subscription for WordPress instances resulted in autoupdate turned off for all found instances. (EXTWPTOOLK-652)

 

[Mark Bailey]

Hi @custer,

Thank you so much for the detailed response! Please forgive my delayed reply.

Cool, it looks like wp-cli will allow us to do what we want. But I still can't figure out how to properly create Event Handlers with the correct wp-cli syntax to perform the needed tasks after WordPress is installed. The few things I'm not sure about:

• Is there any prefix or anything else needed before the wp-cli command, or do I just use the command?
• How is the site ID variable inserted (e.g., "Tell wp-cli to install Jetpack on the newly-created WordPress site.")? I understand the variables for site ID and other things, but I'm not sure whether they can just be inserted into wp-cli commands or of there is other syntax required.

So I'm wondering if anyone would be willing to show me a couple of Event Handler examples for any of these functions? (If I see the proper syntax for one, I should be able to create the rest.)

• Install a certain theme in the newly-created WordPress site.
• Install a certain plugin (not activated) in the newly-created WordPress site.
• Install and activate a certain plugin in the newly-created WP site (if that can be a single/combined operation).

Any help will be greatly appreciated! We are looking forward to working with Plesk (the software and the people)!

Thanks and best regards,

Mark

 

[UFHH01]

Hi Mark Bailey,

here are some information links, which might help you to work with the Plesk Event Handler and WP-CLI:

=> wp-toolkit: WordPress Toolkit
=> WordPress Toolkit in Plesk

=> event_handler: Event Handlers
=> Event Parameters Passed by Event Handlers
​

Is there any prefix or anything else needed before the wp-cli command, or do I just use the command?

Documented commands are for example:

plesk ext wp-toolkit --wp-cli -instance-id 4 -- plugin install bbpress --activate

( Pls. have a look at the documentation links above )


If you desire more help when using the Plesk Event Handler and WP-CLI - commands, or if you desire help for troubleshooting, pls. consider to open a new thread.

 

[Mark Bailey]

Hi @UFHH01,

Thanks for the info. To clarify, I have already reviewed the documentation and am becoming familiar with the components in general, but the issue is combining them (e.g., making a wp-cli command perform an action on completion of the "WordPress Installed" event...for example, install and activate bbpress on the newly created site).

So, as I understand it, the example you provided would not accomplish what I need to do. It would install and activate bbpress on WordPress instance 4. But the problem is that we want to automate plugin installation on a newly-created WP installation. So, instead of a specific ID, the Event Handler would need a variable identifying the target as the new install. I also understand variables passed, but I don't understand how to merge the 2...add a variable like that to a wp-cli command.

So I just wanted to clarify, I'm not just asking for documentation that's already there, it's more about making the documented things work together. There aren't many example Event Handlers in the documentation, so I just don't know the syntax to do what we want.

I'll keep experimenting and open a new thread if necessary.

 

[custer]

Hi everyone,

We've released a new version of WordPress Toolkit - v2.2. Here's the changelog:

• [+] The basic features of WordPress Toolkit are now available for free in Plesk Web Admin edition.
• [ * ] Improved handling and reporting of WordPress upgrade errors.
• [ * ] The built-in help for command-line utility has been improved and updated.
• [-] The dialog for removing a broken instance had no text. (EXTWPTOOLK-671)
• [-] After detaching an instance, WordPress Toolkit did not properly set the instance's autoupdate settings. (EXTWPTOOLK-653)
• [-] Spaces were missing in the text on the cloning page for some languages. (EXTWPTOOLK-660)
• [-] When user performed a custom WordPress installation and specified 'admin' as a WordPress administrator username, this username was replaced on the Securing Instance step of the installation. Now the 'admin' username is not replaced if explicitly specified, and the instance is marked as insecure instead. (EXTWPTOOLK-507)
• [-] During the upgrade, the default WordPress maintenance page was used instead of the maintenance page configured in WordPress Toolkit. (EXTWPTOOLK-644)
• [-] Manually removing a database without using Plesk could result in inability to install or clone WordPress instances. (EXTWPTOOLK-471)
• [-] WordPress Toolkit could not work with an instance that had any code requiring 'wp-settings.php' in 'wp-config.php'. Now WordPress Toolkit ignores such code when working with the instance and provides improved error reporting for 'wp-config.php' issues. (EXTWPTOOLK-638)
• [-] If a theme or a plugin failed to update, no error message was shown. Now WordPress Toolkit shows a comprehensive error message in such case. (EXTWPTOOLK-489)
• [-] Some plugins dependent on other plugins (such as WooCommerce Germanized plugin) could not be activated via the WordPress Toolkit. (EXTWPTOOLK-621)
• [-] Repeating previously failed clone procedure for a WordPress instance failed again if the database user was linked to another database. (EXTWPTOOLK-658)
• [-] Removing the database of a cloned website resulted in inability to clone it again to the same domain and with the same database name. (EXTWPTOOLK-669)
• [-] If user was cloning a subdomain-based WordPress multisite when no valid domains were available, WordPress Toolkit displayed an ugly-looking error without even opening the Clone screen. To avoid hurting the aesthetic sensibilities of users, the error is now displayed properly on the Clone screen and is looking quite fabulous. (EXTWPTOOLK-639)
• [-] If cloning of a WordPress installation was blocked by database import or export errors, the WordPress Toolkit reported that the installation was not configured, but did not explain the actual problem. Now it correctly detects and reports the problem that caused the error. (EXTWPTOOLK-636)
• [-] Themes with descriptions containing non-ASCII characters were breaking the functioning of theme search in WordPress Toolkit. (EXTWPTOOLK-579)
• [-] When synchronizing data between two WordPress instances, the maintenance mode page displayed on the target instance tried to use the resources located on the source instance. (EXTWPTOOLK-631)
• [-] Trying to enable maintenance mode on a WordPress instance of version earlier than 4.3 resulted in an error. (EXTWPTOOLK-686)

 

[custer]

We've released a quick WPT update yesterday, here's the changelog:

• [-] Some parts of the security check screen didn’t show proper text in the Special Edition of the WordPress Toolkit if non-English locale was used. (EXTWPTOOLK-699)
• [-] The buttons on the maintenance mode setup screen had no labels and performed no actions if non-English locale was used. (EXTWPTOOLK-700)

 

[pocokarisma]

I'm not 100% sure what you mean, so let me clarify how automatic updates work in WPT first. When an instance is added to WPT, we set its WP_AUTO_UPDATE_CORE constant in wp-config.php to false and update the instance using WPT and wp-cli. In other words, the state of this constant is not indicative of the actual status of automatic updates for this instance.

Additionally, if you change this constant manually in wp-config.php from false to minor or true, and you had automatic updates set to off in the WPT itself, we will detect this and change the WPT automatic update settings accordingly.

Hi @custer,

Regarding the last paragraph I am quoting. In all my instances I must set the WP_AUTO_UPDATE_CORE constant in wp-config.php to true, because I use the plugin "Easy Updates Manager" to manage all the updates, this plugin looks for the WP_AUTO_UPDATE_CORE constant and if it is set to false it does not attempt to update WordPress. The point is that despite the fact I set the Automatic updates to ON for both Major and Minor in WPT, once the instance is "refreshed" (when I click the button refresh in WPT and in other circumstances) WP_AUTO_UPDATE_CORE goes back to false. How can I prevent this from happening?

Thanks!

 

[custer]

Hi @pocokarisma,

The behavior you describe is the way WordPress Toolkit works -- it disables the constant and uses wp-cli for updating WP itself, so any plugins depending on the constant might not work properly. You can always detach the instance from WPT, but you will lose all WPT benefits this way.

Do I understand you correctly that you're using the plugin you've mentioned because you want to automatically update your plugins and themes?

 

[custer]

Hi everyone,

We've released a new version of WordPress Toolkit, v2.3. The main feature introduced by this release is the ability to create a restore point before performing an update or a data sync. If something goes wrong, you can roll back to the previous instance state. We've also added one more security checker and a variety of bugfixes. Full changelog below:

• A restoration point can now be created for a WordPress instance before running operations that have a risk of damaging the instance, such as upgrading it or syncing data. After such operation, the instance can be rolled back to the restoration point.
• A new security check ‘Disable pingbacks’ was added. It prevents attackers from exploiting the WordPress Pingback API to send spam and launch DDoS attacks.
• A link to the list of WordPress instances was added to the left navigation pane in Power User view and Customer panel.
• A confirmation dialog is now shown before updating multiple WordPress instances.
• A confirmation dialog is now shown before installing a WordPress instance to a database which is already used by another instance.
• A confirmation dialog is now shown if WordPress installation can overwrite certain files, created by some other CMS.
• Now the WordPress Toolkit does not allow synchronizing databases between WordPress instances that share a single database.
• The message about synchronizing an instance with an older WordPress version to an instance with a newer version was corrected. (EXTWPTOOLK-736)
• The string placeholder was used instead of the domain name on the clone page when German language was used in the user interface. (EXTWPTOOLK-771)
• WordPress Toolkit could not work with instances where the is_admin function was used in wp-config.php. (EXTWPTOOLK-722)
• Changing the Plesk encryption key after a failed attempt to clone a WordPress instance could result in all further attempts failing. (EXTWPTOOLK-657)
• When cloning a WordPress instance, an error on the database migration step, could result in file transfer step marked as failed. (EXTWPTOOLK-701)
• When cloning an instance, the WordPress Toolkit searched for possible locations of wp-config.php in a wrong order, which could result in a failure to clone the instance. (EXTWPTOOLK-704)
• A customer having no access to the WordPress toolkit could indeed have an ‘Install Wordpress’ button, which actually did not perform any action. (EXTWPTOOLK-721)
• The “Administrator’s username” security check was displayed in a wrong section of the Secure WordPress dialog. (EXTWPTOOLK-695)

Windows

• Cloning or synchronizing WordPress instances could fail due to unquoted escape sequences in file paths. (EXTWPTOOLK-749)

Looking forward to your feedback!

 

[pocokarisma]

Do I understand you correctly that you're using the plugin you've mentioned because you want to automatically update your plugins and themes?

Yes you do. I know WPT can do plugin, theme and core updates but the aforementioned plugin offers me more features and granularity, some of them vital to me. Also I use another plugin to perform remote automatic backups (UpdraftPlus Backup/Restore) that, apart from the scheduled backups, it does a complete backup every time the other plugin (Easy Updates Manager) updates anything. I use WPT mostly because of its cloning capabilities.

@custer is there any way I could prevent WPT from setting the WP_AUTO_UPDATE_CORE constant?

Thanks!

 

[ArtemF]

Hi,

I'm currently testing Plesk Onyx with Cloudlinux 7.4 and have an issue with wordpress toolkit(2.3.0-551).
When trying to install wordpress i get following errors:

• PHP Fatal error: Uncaught Error: Call to undefined function json_encode() in /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/mustache/mustache/src/Mustache/Engine.php:637
• Stack trace:
• #0 /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/mustache/mustache/src/Mustache/Engine.php(729): Mustache_Engine->getTemplateClassName('{{#is_subcomman...')
• #1 /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/mustache/mustache/src/Mustache/Engine.php(657): Mustache_Engine->loadSource('{{#is_subcomman...')
• #2 /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/mustache/mustache/src/Mustache/Engine.php(236): Mustache_Engine->loadTemplate('{{#is_subcomman...')
• #3 /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/utils.php(459): Mustache_Engine->render('{{#is_subcomman...', Array)
• #4 /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CompositeCommand.php(297): WP_CLI\Utils\mustache_render('/usr/local/psa/...', Array)
• #5 /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp in /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/mustache/mustache/src/Mustache/Engine.php on line 637

Tried it on PHP 5.6 and 7.1 both run as fastCGI with json module enabled(i checked phpinfo).