WordPress Toolkit v5.4 has been in development for over two months, during which the team has produced four minor product updates. Now, it’s time to present the second major release of WordPress Toolkit in 2021 to the public. Read on to find out more.
WordPress Toolkit Action Log
A lot of things can go wrong with your WordPress installation for a variety of reasons. Having a detailed log of events that happened to your site could be very helpful if things ever go south.
WordPress Toolkit now saves a log of essential actions it performs on all managed websites to address this need. Logs are written in plain text for each individual WordPress installation. They have a particular naming pattern that uses internal site UID and are stored in a separate folder:
$HOME/logs/wpt_action_logs/action_log_#SITE_UUID#.log (where $HOME is the home directory of your domain).
For example, in Plesk, you can find the log here:
/var/www/vhosts/mywebsite.net/logs/wpt_action_logs/action_log__4d4a10e8-84b2-423e-8539-b43c97b692ae.log
On cPanel, the same log would be stored here:
/home/admin/logs/wpt_action_logs/action_log__4d4a10e8-84b2-423e-8539-b43c97b692ae.log
Log files are accessible via File Manager of your control panel or via ‘Logs‘ link on the site card that opens the corresponding log file in the Log Browser (on Plesk) or File Manager (on cPanel). For convenience, the ‘Logs‘ link is also available as an icon in the site title, so you can quickly open the log for any site in a collapsed site list:
Note that Log Browser in Plesk cannot properly parse the WordPress Toolkit log right now. We will rectify it in the next WordPress Toolkit release.
Not all events are logged at the moment, just the most important ones, but we will expand the list in the next WordPress Toolkit release to ensure that everything WordPress Toolkit does could be found in the log files. We will also introduce the interface for viewing correctly parsed logs in the same Toolkit release. We hope that this feature will help site admins troubleshoot their sites and reduce the number of support tickets we (and our partners) receive.
New wp-cron Management Workflow
The ability to turn off default wp-cron behavior was introduced one year ago in WordPress Toolkit v4.7. Since then, we’ve collected a lot of feedback on this feature, and it was time to put this feedback into action.
First, the option was renamed to ‘Take over wp-cron.php‘. This was done to avoid the classic “enable to disable” confusion, where you are prompted to enable something that says “disable,” and you’re like “ehhh??”
Second, you now can explicitly choose if a replacement cronjob should be created or not via the ‘Create a replacement task when a takeover is initiated‘ switch:
If you toggle this switch after ‘Take over wp-cron.php‘ is already enabled, it will create or remove the replacement cronjob correspondingly. If the switch is toggled before the takeover is initiated, then the replacement cronjob will be (or won’t be) created when the user enables the takeover.
Speaking of replacement cronjobs, they are now way less strict when it comes to user modifications like task execution frequency. Basically, you can modify every aspect of the cronjob without being afraid that WordPress Toolkit will overwrite the changes. If WordPress Toolkit cannot find its own cronjob, it will not try to recreate the cronjob, concluding that it was knowingly modified or removed by the user. If the user has butchered or removed the replacement cronjob by mistake, it can be recreated by switching off and on the corresponding ‘Create a replacement task…‘ switch.
SSL/TLS Support Status
WordPress Toolkit has been showing the SSL/TLS status on the site card for quite some time, but this status was not particularly helpful, as it merely showed which protocol was used in the WordPress site URL. We’ve redesigned this behavior to be more beneficial to site administrators. Now, the site card features the actual status of what’s going on with SSL/TLS certificates on your site. In particular, WordPress Toolkit now detects and helps address the following situations:
- If SSL/TLS support is turned off on your hosting
- If there’s no SSL/TLS certificate installed for the domain name used by your WordPress site
- If SSL/TLS certificate you’re using is self-signed
- If SSL/TLS certificate you’re using is expired
- If SSL/TLS certificate you’re using was not issued for the domain name used by your WordPress site
- If permanent SEO-safe 301 redirect from HTTP to HTTPS is turned off on your hosting
- If SSL It! extension is not installed in Plesk
- If SSL/TLS feature is turned off for your account in cPanel
- If there’s a protocol mismatch (HTTP to HTTPS redirect is enabled, but WordPress still uses HTTP)
Example of situation #5 from the list above:
… and, obviously, we’ll also let you know if everything’s OK with your site in terms of SSL/TLS, displaying your certificate name:
If you don’t have a certificate, the Toolkit will gently nudge you towards issuing a Let’s Encrypt cert or buying a cert.
New Cloning Backend
When it comes to cloning, many WordPress-related tools and services claim that they clone WordPress sites. However, the question today isn’t “which tool can do it,” the question is “which tool does it best” – after all, both BMW Isetta and BMW i8 are German cars that can drive on your average road, but there’s a world of difference between them in terms of performance. Our cloning mechanism has been quite complicated (to put it mildly) since its inception. This complexity made things difficult to maintain and improve, so we decided to update it. Specifically, our goals were:
- Easier maintainability (a single backend for all supported platforms instead of multiple different algorithms)
- Better security
- Improved performance
- Enhanced reliability
It took us quite some time, but we got it done, and WordPress Toolkit now boasts a new backend that meets all our expectations. We have even managed to test it in battle conditions: a cPanel customer was experiencing weird slowdowns during cloning, so we’ve decided to replace the cloning backend on the affected server to see what happens. The experiment was a resounding success, speeding up the procedure dramatically. Even so, such change could be quite risky when applied on all WordPress Toolkit servers at once, so we’re planning to introduce it gradually – more about that in the next paragraph.
Other Improvements & Bugfixes
WordPress Toolkit v5.4 includes a lot of other minor improvements and multiple bugfixes. Some of the highlights include:
- AlmaLinux support on both cPanel and Plesk
- Integration with WHM / cPanel was redesigned and simplified for improved reliability
- WordPress Toolkit now ships with its own version of UI library on Plesk to make sure that all the latest changes and bugfixes are available to our users as fast as possible
- Progress display in windows was standardized and unified for better user experience
- Various warnings and notifications related to problematic PHP versions were improved and made more consistent
- Minimal WordPress version that can be installed via WordPress Toolkit was increased to WordPress v4.9 (the last major release without Gutenberg for those who refuse to use it)
Finally, the output of ‘–info‘ CLI command now includes the WordPress installation state:
More Updates on cPanel
E-mail notifications on cPanel
E-mail notifications about updates and quarantined sites are now finally available on cPanel. There’s no UI for managing them now, so they are disabled by default to avoid making users unhappy. To enable the notifications, server administrators need to put the corresponding option in their config.ini file and set its value to true:
‘cpanelAdminSuspiciousInstanceNotificationEnabled‘ – sends a notification about new suspicious instances to server administrator.
‘cpanelResellerSuspiciousInstanceNotificationEnabled‘ – sends a notification about new suspicious instances to each reseller.
‘cpanelClientSuspiciousInstanceNotificationEnabled‘ – sends a notification about new suspicious instances to each client.
‘cpanelAdminAutoUpdatesNotificationEnabled‘ – sends a digest of newly available and installed updates (WordPress core, plugins, themes) to the server administrator.
‘cpanelResellerAutoUpdatesNotificationEnabled‘ – sends a digest of new available and installed updates (WordPress core, plugins, themes) to each reseller.
‘cpanelClientAutoUpdatesNotificationEnabled‘ – sends a digest of new available and installed updates (WordPress core, plugins, themes) to each client.
We’re planning to introduce the UI for managing these notifications in the next major WordPress Toolkit release, at which point we’ll enable all these notifications by default. Until that, hosters and server administrators will have to rely on config file modification to receive helpful information from WordPress Toolkit in their mailboxes.
Leika for cPanel
For those who don’t know yet, we have a service called Leika for rolling out gradual changes and conducting various experiments. This service offers tremendous help controlling the spread of potentially dangerous changes and experimenting with ideas that could positively affect user experience.
Until now, Leika only worked for Plesk, But not anymore as we’ve just made it available for WordPress Toolkit on cPanel too. The cloning backend change described earlier is one of many WordPress Toolkit features to undergo gradual rollout for the whole audience – and it’s the first one (but not the last one) on cPanel.
Future Plans
Many of the plans for the next release were already mentioned above:
- Add UI for action logs
- Add the rest of the actions to logs
- Add UI for e-mail notifications on WHM/cPanel
In addition to these things, we are looking into improving how we handle popular caching plugins during cloning. There’s more exciting stuff coming in v5.5, but I’ll have to keep that under wraps for now – after all, we should always keep some pleasant surprises in store for you 😉
With that said, see you soon, and thank you for your time!
