Plesk WordPress Toolkit 5.4 Release: Action Log, wp-cron Management Workflow, SSL Support, and More

WordPress Toolkit 5.4 Release - Plesk

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:

WordPress Toolkit 5.4 Release - WordPress Toolkit Action Log - Plesk

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.

WordPress Toolkit 5.4 Release - WordPress Toolkit Action Log 2 - Plesk

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:

WordPress Toolkit 5.4 Release - - New wp-cron Management Workflow - Plesk

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:

  1. If SSL/TLS support is turned off on your hosting
  2. If there’s no SSL/TLS certificate installed for the domain name used by your WordPress site
  3. If SSL/TLS certificate you’re using is self-signed
  4. If SSL/TLS certificate you’re using is expired
  5. If SSL/TLS certificate you’re using was not issued for the domain name used by your WordPress site
  6. If permanent SEO-safe 301 redirect from HTTP to HTTPS is turned off on your hosting
  7. If SSL It! extension is not installed in Plesk
  8. If SSL/TLS feature is turned off for your account in cPanel
  9. 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:

WordPress Toolkit 5.4 Release - SSL/TLS Support Status - Plesk

… and, obviously, we’ll also let you know if everything’s OK with your site in terms of SSL/TLS, displaying your certificate name:

WordPress Toolkit 5.4 Release - SSL/TLS Support Status 2 - Plesk

If you don’t have a certificate, the Toolkit will gently nudge you towards issuing a Let’s Encrypt cert or buying a cert.

WordPress Toolkit 5.4 Release - SSL/TLS Support Status 3 - Plesk

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:

  1. Easier maintainability (a single backend for all supported platforms instead of multiple different algorithms)
  2. Better security
  3. Improved performance
  4. 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:

WordPress Toolkit 5.4 Release - Improvements & Bugfixes - Plesk

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!

Announcing Plesk WordPress Toolkit 4.8 Release

Plesk WordPress Toolkit 4.8 is the fourth major WordPress Toolkit update in 2020. In this release, we focused on several customer-requested features. Including Smart Updates CLI, new notifications for outdated plugins, choosing the default WordPress installation language, and more. Read on to learn what’s new in this release.

Find out more about Plesk WordPress Toolkit

Choosing the Default WordPress Installation Language

When users install WordPress via WordPress Toolkit, there’s some magic happening behind the scenes. In particular, we are selecting default WordPress language based on the language of the user who is getting this WordPress installation. So, for example, if my Plesk is switched to Italian when I install WordPress, it will offer Italian as the default WordPress language. If the server admin is using Plesk in English and installs WordPress for a user whose Plesk is in German, the default WordPress language selected on the installation form will be German.

Apparently, either this logic doesn’t work all the time (although we weren’t able to conclusively confirm this). Or some people simply want to use a very specific language by default in all cases. The request from several customers was heard loud and clear. So we delivered this functionality in WordPress Toolkit 4.8. Now server administrators can open global WordPress Toolkit settings and choose a language that should be selected for all WordPress installations on the server by default. Users installing WordPress can choose a different language if they want, obviously.

Let’s take a closer look:

To return the old behavior which selected the language automatically, simply choose the “Same as user language” option (it’s right on top of the list of languages). Oh, and if you’re wondering what’s “Deutch (Österreich)” on the screenshot above, and why you can’t find this language in Plesk, here’s the answer: we’re taking the list of languages from WordPress itself. And it’s bigger than the list of languages supported by Plesk.

Adding CLI for Smart Updates

We’re slowly but surely adding CLI for existing features. And this time it’s Smart Updates feature that gets some love. WordPress Toolkit 4.8 adds the first part of Smart Updates CLI, allowing hosters to enable and disable Smart Updates on a particular site. The second part of Smart Updates CLI will come later. And it will include the ability to fetch Smart Update procedure status and confirm or reject the update.

Here’s the brief usage info for the current CLI command:

plesk ext wp-toolkit --smart-update

    -instance-id INSTANCE_ID|-main-domain-id DOMAIN_ID -path PATH

    [-format raw|json]

Arguments:

instance-id: WordPress installation ID

main-domain-id: Main domain ID

path: The relative path from the domain's document root directory. Example: /subdirectory

format: Outputs the data in a particular format. By default, all data is shown in the raw format. Supported formats: json, raw

Inability to Update Paid Plugins or Themes Notification

You probably remember that in WordPress Toolkit 4.7 we added support for updates of paid plugins and themes. Announcing this change, I’ve mentioned a disclaimer. It’s about WordPress Toolkit not letting users know about certain plugins & themes requiring a license for automatic updates. Starting with WordPress Toolking 4.8, users will be notified about this. That’s if WordPress Toolkit can’t update a plugin or theme and we suspect that it’s because its license is missing.

Unfortunately, there’s no way to notify users about this before the update. So we had to settle for the post-factum message.

Our Research

We’re always researching various things when working on a release. But these activities are never mentioned outside the team for some reason. And I figured it’s time to have a quick glimpse into our investigations. 

Here are some of the more interesting things we looked into:

  • Which issues prevent us from properly supporting CloudLinux on both Plesk and cPanel (spoiler: mostly panel-related things).
  • What is the performance impact of running Smart Updates on dozens of sites simultaneously (spoiler: could be worse).
  • Whether WordPress Toolkit is compatible with the so-called “Must-Use” plugins (spoiler: not really).

We’ll continue our research efforts in WordPress Toolkit 4.9. And I will continue keeping you in the loop.

What’s On the Future

We fixed several customer-reported bugs in WordPress Toolkit 4.8. And we improved product reliability in several places. Our bug-fixing activities will continue in WordPress Toolkit 4.9, alongside with internal improvements. 

During the 4.8 release, we also made WordPress Toolkit on cPanel almost feature-complete. Adding the Data Copy feature, enabling the rest of the security checkers, and so on. We still have quite a lot of things to do before WordPress Toolkit for cPanel is available for the general public. But the finish line is getting closer every day. Besides cPanel stuff, bugfixes, and improvements, WordPress Toolkit 4.9 will also include a couple of customer features. We’re looking at candidates right now. And I think our Uservoice voters should be quite happy with our choices. 

Thank you for reading up to here. And thanks to the whole team for their hard work. Meanwhile, we’ll continue to improve our beloved WordPress Toolkit. See you next time!