The first WP Toolkit release of 2021 is now publicly available — please welcome WP Toolkit v5.3 This release is focused on fixing issues reported by customers, improving performance, and making sure we can properly handle working with both outdated PHP versions and the latest PHP 8.Â
Read on to learn what’s new:
Â
Updated wp-cli & PHP 8 Support
Â
PHP 8 was released two months ago, and already many of you trying to use it for hosting WordPress sites. So, to support this release, we needed to explore the outdated wp-cli component used for managing many aspects of WordPress sites.Â
In v5.3 of the WP Toolkit, the team has updated  from the previously used (and quite outdated) version 1.4.0 to the latest available version 2.4.1, which finally allows WP Toolkit to manage sites working on PHP 8. Note that PHP 8 support in this  version is still kind of experimental (or “beta”, if you wish), so customers are advised to be more vigilant than usual when using PHP 8. As soon as  team announces full and proper PHP 8 support, we’ll immediately work on including the corresponding  update in WP Toolkit.
Identifying Outdated and Unsupported Sites
Â
Updating wp-cli resulted in certain unfortunate consequences: WP Toolkit now cannot manage sites working on PHP 5.2 (End of Life on 6 Jan 2011, 10 years ago) and PHP 5.3 (End of Life on 14 Aug 2014, 6 and a half years ago). To accommodate for this change, WP Toolkit can now identify websites using unsupported version of PHP and display corresponding information in the interface:
Â
If your PHP version has reached End of Life but still supported by WP Toolkit, you will be notified about this as well:
Â
Â
Since we’ve started to better differentiate between various site states, WP Toolkit now also properly notifies users if their WordPress version is way too old:
Â
Â
We’ve also added an extra notification about outdated WordPress core, since some people have complained that existing notifications are not visible enough:
Â
Â
To avoid scaring users, WP Toolkit now tries its best to create screenshots even for sites with unsupported PHP or WordPress versions. We hope that seeing a site screenshot will help customers understand that the site itself is working fine, but WP Toolkit cannot manage it because it’s so ancient that it should be surveyed by a team of archeologists first.
Â
New Autoupdate Defaults in WordPress 5.6
WordPress 5.6 has introduced new default settings for WordPress core autoupdates. New WordPress installations are now configured to automatically install both minor and major updates by default. Existing WordPress installations updated to v5.6 will keep their previous autoupdate settings.
Â
WP Toolkit now supports this change, so when you install WordPress 5.6 or newer via WP Toolkit, the autoupdate settings will be automatically set to “Both major and minor updates“, as opposed to “Only minor updates” option, which was the default before v5.6.
Â
Â
Due to the new defaults mentioned above, we have also changed the way WP Toolkit manages WordPress core autoupdate settings. Previously WP Toolkit was using the WP_AUTO_UPDATE_CORE constant in wp-config.php file to help WordPress understand how it should behave. With changes brought in WordPress 5.6, we have decided to avoid using this constant and use the get_site_option( ‘auto_update_core_major’ ) parameter stored in the WordPress database instead. This parameter is utilized by WordPress itself when site admin switches between “major & minor” and “minor only” autoupdates in WordPress admin area. Using this parameter makes WordPress site management via WP Toolkit more natural, transparent, and non-obtrusive for advanced site admins.
Â
Existing WordPress installations updated to v5.6 will keep the WP_AUTO_UPDATE_CORE constant in wp-config.php file until autoupdate settings are changed by the site admin. Note that WP Toolkit will still have to use the WP_AUTO_UPDATE_CORE constant if site admin decides to completely disable all autoupdates.
Â
An additional fix related to WP_AUTO_UPDATE_CORE constant was also included in WP Toolkit v5.3: the constant is no longer added automatically when WP Toolkit checks for availability of updates. It can only be added if customer explicitly saves or changes autoupdate settings.
Cloning with defined DEFINER
Â
WP Toolkit creates a database dump when it clones a site. In certain cases, this dump includes a defined DEFINER clause, which leads to failure of the cloning procedure. You can now rest easy that this problem is finally fixed.
Â
Since every site is different, this may not be convenient for you. Therefore, it is possible to turn off the application of this fix by adding the following option to the config file:
Â
fixDatabaseDumpDefiner = false
Â
Upsell Links Configuration in cPanel
Â
WP Toolkit on cPanel has two Deluxe upsell links: one in WHM, one in cPanel. Hosters can configure these links in Manage2 or modify WP Toolkit config file on the server. To make things easier, we have added the ability to customize these links on the global “Settings” screen in WP Toolkit. We’ve also updated the default WP Toolkit upsell link to make sure it is pointing to a proper destination.
Â
Â
For reference, here’s the priority of link customizations: links in UI overrule the links in config file, which overrule links provided by Manage2, which in turn take precedence over the default links shipped with WP Toolkit.
Research, Improvements, Bugfixes
Based on the research performed in December, we have increased the site list loading speed on Plesk. We have also tested the performance of Smart Updates and regular updates to better understand where and how we can improve our product.Â
Â
As for bugs, the v5.3 release includes several customer-requested bugfixes, particularly those that address cloning-related issues.
Â
What’s Next?Â
We’re also working on a number of exciting new features to continue improving the WP Toolkit, based on your feedback and usage. Have you got the latest version yet? What has been your experience with the Toolkit? Let us know in the comments or via your partner account manager!
with
2 Comments
Hello,
Has there been an update to the documentation for Smart Update to include your own sitemap?
Hi Joel! Smart Updates is already using sitemap for checking the site. WordPress Toolkit will look for the following files in the order of priority (highest to lowest):
* Custom ‘smart-update-sitemap.xml’ sitemap file in the site directory
* Standard ‘sitemap.xml’ sitemap in the site directory
* Fallback sitemap created by wp-cli in the site directory
Important: sitemap specified in ‘robots.txt’ and sitemap located in the root of the domain are ignored if the site is installed in a subdirectory.
You can change the number of pages analyzed by Smart Updates via ‘smartUpdateCrawlerPagesLimit’ setting in the config file. The default value is 30.
We hope this helps 🙂 Thank you!