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!

The Plesk WordPress Toolkit 5.3 is Now Available

WordPress Toolkit update 5.3 blog Plesk Header

The first WordPress Toolkit release of 2021 is now publicly available — please welcome WordPress 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 WordPress 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 WordPress 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 WordPress Toolkit.

WordPress Toolkit 5.3 Plesk

Identifying Outdated and Unsupported Sites

 
Updating wp-cli resulted in certain unfortunate consequences: WordPress 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, WordPress Toolkit can now identify websites using unsupported version of PHP and display corresponding information in the interface:
WordPress Toolkit Plesk v5.3
 
If your PHP version has reached End of Life but still supported by WordPress Toolkit, you will be notified about this as well:
 
WordPress Toolkit v5.3 Plesk blog

 

Since we’ve started to better differentiate between various site states, WordPress Toolkit now also properly notifies users if their WordPress version is way too old:
 
WordPress Toolkit v5.3 Plesk

 

We’ve also added an extra notification about outdated WordPress core, since some people have complained that existing notifications are not visible enough:
 
Plesk WordPress Toolkit 5.3

 

To avoid scaring users, WordPress 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 WordPress 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.
 
WordPress Toolkit now supports this change, so when you install WordPress 5.6 or newer via WordPress 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 WordPress Toolkit manages WordPress core autoupdate settings. Previously WordPress 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 WordPress 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 WordPress 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 WordPress Toolkit v5.3: the constant is no longer added automatically when WordPress Toolkit checks for availability of updates. It can only be added if customer explicitly saves or changes autoupdate settings.

Cloning with defined DEFINER

 
WordPress 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

 
WordPress Toolkit on cPanel has two Deluxe upsell links: one in WHM, one in cPanel. Hosters can configure these links in Manage2 or modify WordPress 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 WordPress Toolkit. We’ve also updated the default WordPress 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 WordPress 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 a number of 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 WordPress 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!

The Plesk WordPress Toolkit 5.2 is Now Available

The Plesk WordPress Toolkit 5.2 is now publicly available! This release focuses on catching up on popular customer requests and fixing various nagging issues. The 5.2 update has something for everyone, so let’s take a look at what’s new!

Sets for Resellers

Allowing resellers to have their own sets is the most popular feature request in the WordPress Toolkit section of Plesk Uservoice. It’s requested not only by legit resellers but also by those who are using reseller accounts as limited Plesk server administrator accounts. Anyway, this feature is finally here:

Here’s what you need to know about this feature:

  • Resellers get the same default sets as server administrators.
  • Resellers can only access and manage their own sets.
  • Customers of resellers can see the sets of their resellers when installing WordPress. They do not see server administrator sets.
  • The global option “Allow customers to use sets when they install WordPress” will also affect reseller sets. If this option is switched off, resellers’ customers won’t see any sets when installing WordPress.
  • Reseller service plans actually include additional services with automatic installation of WordPress (alone or with any of the reseller sets).

Theme Activation in Sets

Another thing that’s been requested a lot recently is the ability to choose which theme should be activated in a set when this set is installed on a WordPress site. This feature allows hosters and web studios to provide more turnkey added value in their WordPress service offerings. So we made it happen.

As a reminder, you can install sets in one of the following ways:

  1. Provision a subscription-based on a service plan with a specific Additional Service that installs WordPress with a particular set.
  2. Install a set together with WordPress when you install a new WordPress site.
  3. Install a set on an already existing WordPress site via Sets tab functionality.

All these ways are available both via GUI and CLI. Your selection of a particular theme that should be activated in a set will be applied regardless of which way the set is installed.

Important notes:

  • This is not the final UI we’re aiming at. We’re planning to redesign the whole Sets tab next year to make it more convenient and user-friendly, and this feature will be a part of the redesign.
  • This ability is also available as a new operation of the –sets CLI command. Usage example: plesk ext wp-toolkit –sets -operation activate-theme -set-id ID -theme-id THEME_ID
  • By the way, plugins in a set can also be configured to be activated or deactivated upon the installation of the set. Since plugins are activated by default, the activation feature is more of a deactivation feature, so it’s not as important (most people would like their plugins to be active right away). Anyway, it was easy to do, so we threw it in as a bonus.
  • Activating and deactivating plugins in a set via CLI is also supported.

Pending Smart Update Notification

Looking at Smart Updates, cPanel team has noticed that there’s no way for users to learn that Smart Updates wasn’t applied automatically due to some issues and that they needed user attention. This happens because WordPress Toolkit is not yet integrated with email notifications in cPanel (something we’re planning to remedy soon). 

It also became clear that the problem is bigger than this. Users who’ve launched Smart Updates but closed the Update window without making a decision could also forget that they needed to either apply the update or reject it. To fix this problem, we have added a visual marker notifying about a pending Smart Update on a site card:

This notification will be displayed whenever there’s a finished Smart Update test run that needs to be reviewed and either applied or rejected by the user. To open the Smart Updates window, users will be asked to click on the Check Updates button.

WordPress Toolkit Deluxe Dashboard… Lite

After the introduction of the second licensing type in WordPress Toolkit for cPanel, we realized that there’s no quick and convenient way for the server admin to check who exactly has access to the paid WordPress Deluxe features. Depending on how the hoster’s packages and feature lists are organized in WHM, this task can range from trivial to quite challenging. 

To make things a bit easier, we’ve added a very basic screen that lists all accounts on a server with access to WordPress Toolkit Deluxe. It can be accessed via a link on the Settings screen:

Lo and behold, this might be the simplest WordPress Toolkit screen in the product history:

Depending on user feedback, we might improve this list, including stuff like redirects to cPanel of a particular user account, and so on. For now, it does what it intends to, and we hope it will prove useful.

Underscore in Slugs

WordPress Toolkit had a long-lasting issue with plugins and themes that use underscore symbol in their slugs (technical names / IDs). Specifically, it was not possible to upload, install, or update any plugin or theme with such a symbol in its slug through WordPress Toolkit. 

For a time, this was not deemed to be a real issue since WordPress directory maintainers do not usually assign slugs with an underscore to submitted plugins and themes, so this symbol is not typically used in such context. 

However, over the years we have discovered that there are several popular plugins that feature underscore in their slugs (js_composer is the biggest culprit). The time has finally come, and we have updated a number of internal WordPress Toolkit routines to properly work with plugins and themes that have slugs with underscore symbol.

Site List Expanding Changes

In WordPress Toolkit 5.0 we have introduced a new list-based interface for sites, which brought not only new features but also new issues with it. 

One particular issue happened when users installed a new site. The interface for managing this site was often collapsed by default even if it was the only site in the list. We’ve investigated the behavior of our new list UI and introduced a number of changes in WordPress Toolkit 5.2. Now, the following logic is used:

  • After a site is installed, it is expanded by default, regardless of how many sites are in the site list.
  • After a clone is created, it is expanded by default, regardless of how many sites are in the site list.
  • If a user only has one site, it should always be expanded by default.

This is just the beginning, though. We continue to look into improving the collapse/expand behavior further in our next releases. In particular, we’d like to remember the user’s choice (which site was expanded, and which was collapsed) and improve the performance of the site list when it has a lot of sites. Both items might seem obvious but are far from trivial in terms of implementation. Therefore they will take some time to address.

CentOS 8 & CloudLinux 8 support

WordPress Toolkit v5.2 supports CentOS 8 and CloudLinux 8 on both Plesk and cPanel. Note that the CloudLinux team has not officially announced CloudLinux 8 support for Plesk and cPanel, but WordPress Toolkit works fine on it, as far as we can tell.

Web Server Rules Description

WordPress Toolkit adds specific rules to web server config files when it applies certain security measures. If you look at these rules, it’s not apparent who added them and why. To make things more transparent for admins, we have added short descriptions for each rule right in the webserver config files (except for IIS, where it’s not so easy). 

It’s a small change, but we’d like to think it can help users better understand the value brought by WordPress Toolkit and help debug things if something goes wrong.

Research, Improvements, and Bugfixes

During this release, the team did a lot of research on topics we’d like to address in the future. Here are some of the things we’ve investigated:

  • How to properly clone and copy the content of a specific WordPress site if another WordPress is located inside the first site’s subdirectory.
  • How to properly clone and copy the Elementor plugin.
  • What are the most frequent and important issues with cloning functionality?
  • Why Smart Updates sometimes provide false negatives on websites with a large number of posts.
  • How we can ship a specific version of the UI library in WordPress Toolkit for Plesk.
  • How broken WordPress Toolkit will be after we perform a very belated and very major wp-cli update.
  • What issues related to PHP module requirements might turn up if WordPress Toolkit is using ea-php or alt-php when installed in cPanel working on CloudLinux 6 & 7.
  • How to improve site list performance and WordPress Toolkit performance in general on cPanel.

Some of these research tasks resulted in an immediate item resolved in the 5.2 release. Such was the case for cPanel performance research. The team has significantly improved the performance right away in v5.2 and identified several good improvement opportunities for the upcoming WordPress Toolkit 5.3 release. 

Future Plans

Our next major release will be out in January 2021. As mentioned above, we’ll continue our efforts to fix and improve existing functionality. WordPress Toolkit 5.3 will have an increased focus on improving our cloning feature, updating wp-cli utility to the latest version, and improving site list performance on both cPanel and Plesk. 

We’re still looking into what else we fit into the next release, so expect some surprises later down the road. Thanks for reading and see you next year!

The Plesk WordPress Toolkit 5.0 Version Release

I’m glad to announce that WordPress Toolkit v5.0 is now available! This seminal release introduces major changes in the product, fully justifying the major version increase. Let’s learn what makes this release truly special.

Goodbye Onyx, Hello Obsidian

WordPress Toolkit 5.0 leaves Plesk Onyx behind, requiring Plesk Obsidian to work. This change was necessary because it was getting increasingly difficult to develop new things while having to drag along a bunch of legacy code required for WordPress Toolkit to work in Onyx 17.8. Full transition to Obsidian should allow us to avoid using many old crutches, making changes faster and with fewer bugs. It will also open a lot more UI/UX possibilities, allowing our design team to properly express their ideas.

Users on Plesk Onyx 17.8 will stay on WordPress Toolkit 4.x, receiving only critical security updates (if/when necessary). Updating to WordPress Toolkit 5.0 will require updating your Plesk installation to Plesk Obsidian. We’re also going to prepare a separate WordPress Toolkit 4.10.x release. That’s to show a special notification to users about updating to Obsidian if they want to get new stuff. Learn more about Plesk Onyx End of Life and its support policy update here.

New Website Management UI

The biggest in-product change in WordPress Toolkit 5.0 is the new UI for managing WordPress installations. It’s said that a picture is worth a thousand words.

We wanted to avoid dramatic revolutions and evolve the UI naturally. Making it more convenient and usable without requiring users to re-learn it. To achieve this, we’ve taken our true and tried website card interface and replanted it on a different set of UI elements that are also used by Dynamic List in Plesk.

Our next step was moving the update functionality to the very front. Since keeping your site up-to-date is one of the most important things the site admin is expected to do on a regular basis:

Other tools were also reshuffled a bit and placed in the expected and convenient locations. We wanted to make sure users won’t be confused and lost trying to find what they need. In the end, we’ve got ourselves a new modern-looking yet familiar interface with improved focus on important things – performance and better responsiveness.

This might not seem like a huge change, but it’s a very important one for us. Our old UI was already quite good (so no need for a drastic redesign). But it used outdated technology that was, let’s say, on life support. It was time to move the UI to a different foundation, creating a new UI platform with a huge potential for improvements and integrations.

We’ve already toyed a bit with some interesting ideas that would fit nicely in the new interface. I’m going to show you a super-secret sneak peek into some of these ideas made possible by our new UI platform:

We’d love to explore these ideas (and many others) in the future, but this is a tale for another time (and another bunch of challenges we’ll have to solve eventually).

WordPress Toolkit Lite Update

The “Lite” version of WordPress Toolkit 5.0 (also called WordPress Toolkit SE on our website) was previously limited to owners of Plesk Web Admin edition and similar low-end Plesk editions. However, the “free” part of the WordPress Toolkit required a thorough review and redesign to make it acceptable for a larger audience.

After conducting the review, we’ve come to the conclusion that the changes were required on two fronts:

  • Redesign the UI and UX of the whole process
  • Change the contents of the Lite (free) feature list

Let’s start with the UI/UX redesign. The old “Lite” interface had a lot of visual glitches, bugs, and overall inconsistencies accumulated over the years. Case in point:

Our design team came up with a new unified approach that was positively received by pretty much everyone who saw it. Powered by the new UI library, this redesign significantly improves the WordPress Toolkit Lite experience, making it consistent, unobtrusive, and pleasant to look at. I’ll let the screenshots tell the story:

The same screen, but with Lite upsell elements highlighted:

Inside a paid feature screen:

As for the contents of the WordPress Toolkit “Lite”, we’ve come up with the following rules of thumb that should be logical, reasonable, and easy to understand for both hosters and end-users:

  • Single-site operations available in the control panel or in WordPress itself should be free. Such features are either a mandatory baseline thing expected to “just be there”, or simply a nice bonus. They won’t push people to purchase paid WordPress Toolkit, but if they’re behind the paywall, it will annoy users (“I can do it in WordPress admin for free, why are you selling it?”).
  • Mass operations should require a paid version of WordPress Toolkit. They are a matter of convenience not available in WordPress itself, and they are required for any large-scale business. This makes them high value for agencies and hosters.
  • High-value operations like cloning or Smart Updates should also require a paid version of WordPress Toolkit. These features are critical for (semi-)professional level work and they are hard to carry out otherwise.

With this logic in hand, we’ve revised the list of “free” and “paid” features in WordPress Toolkit, coming to the following results.

Free and Paid Features

Features are available for free in WordPress Toolkit Lite:

  • Management of Search Engine Indexing
  • Debugging management
  • Password Protection
  • Update settings for individual sites
  • Upload of plugins & themes on the plugins & themes management screen of a particular site

Feature only available in the full (paid) version of WordPress Toolkit:

  • Mass update operations, including modification of update settings for multiple sites at once

We hope these changes will provide a better experience for all users, and we’re looking forward to introducing more features on both sides of the fence in the future.

WordPress Toolkit for cPanel and Future Plans

The team has been working on the cPanel release for more than a year, starting last September. I’m happy to say that the wait is over – WordPress Toolkit is finally available on cPanel! So, let’s go over the key points of this release.

WordPress Toolkit for cPanel is basically the same product, functionality-wise, just on cPanel. There are some minor discrepancies, but most of them will be either addressed in the next WordPress Toolkit releases or will have to wait until corresponding features are fully available in cPanel.

Unlike Plesk, WordPress Toolkit for cPanel is licensed on a per-account basis. Our first release is limited to a hand-picked selection of VIP partners, who will have exclusive access to WordPress Toolkit.

What’s Next?

Speaking about the future, our next release will be a shorter one to coincide with the cPanel v92 launch. We’ll focus on supporting the alternative licensing model for the public WordPress Toolkit 4 cPanel launch, introducing CloudLinux support on cPanel, and adding things like localization support (again, on cPanel). WordPress Toolkit 5.1 will also include customer features and bug fixes for existing Plesk customers, so don’t worry about the Plesk side of things, we’ve got that covered as well.

…So, once again, I want to thank the whole WordPress Toolkit development team for their fantastic work. And also thank you for your attention. If you have anything you’d like to share with us, let us know in the comment section below. See you next time!

 

All You Need to Know About the Plesk WordPress Toolkit 4.10 Release

We’re happy to announce the release of The Plesk WordPress Toolkit 4.10, the last major release of the WordPress Toolkit 4.x line. Don’t worry, we’re not abandoning the project. This is simply our way of saying that the next big WordPress Toolkit version is going to start with number 5 – hooray!

Discover the Plesk WordPress Toolkit

WordPress Toolkit 4.10 is also the last major WordPress Toolkit release that supports Plesk Onyx 17.8. Although we’ll continue to release security updates for Plesk Onyx customers until its End of Life. However, if you want to keep getting major new features and improvements, it’s time to update your Plesk. WordPress Toolkit 5.0 will only be available for Plesk Obsidian.

With that said, let’s see what’s new in the Plesk WordPress Toolkit 4.10.

Site Backup

Users have been asking us for a long time to introduce a simple tool for quickly backing up a single WordPress site. Plesk has a great Backup Manager tool that works wonders in the majority of cases, but it might be overkill sometimes. 

Specifically, the issue some customers have with Backup Manager is that it backs up the whole subscription with all its sites and data instead of a single site. This can be particularly annoying if you have several sites on a subscription – for example, one staging site and one production site. 

Backing up such a subscription requires much more time and disk space than needed if you want to back up just your production site, for example.

WordPress Toolkit 4.10 introduces a tool for backing up and restoring individual WordPress sites to address this issue. 

This link has been previously directing users to Plesk Backup Manager for the corresponding subscription. Now it opens a new window for backing up a particular site:

Backing up a site is as simple as clicking Back Up, no configuration or setup is required. A separate directory in the user’s webspace stores all site backups. When you use Plesk Backup Manager to perform a scheduled backup or to back up your stuff to cloud storage, these site backups made by WordPress Toolkit will be usually included.

In addition to backing up your site, you can download backup files to safely store them elsewhere or upload them on a different server. Restoring a backup could actually be quite destructive for a website since its data will be rewritten. So a corresponding warning is shown. Hesitant users are given the option to back up their site before doing a restoration, as a helpful suggestion.

Backup is a very complex and involved topic. So we had to make some compromises to efficiently use our resources. Clicking download icons will take you to File Manager, while in the future it’ll start the download process immediately. We’ll also relax some restrictions on supported backup file names and metadata to make sure that a wider range of WordPress backups is supported for restoration purposes. And the restoration process itself is more user friendly.

Right now, the feature is focused on backing up and restoring data in the context of an existing website hosted in the same place. Working with WordPress Toolkit-made backup files uploaded to a different server is a difficult process now. And we’re looking into improving that in the nearby future.

There aren’t immediate plans to introduce features like cloud backup or scheduled backup – users can employ Plesk Backup Manager for that. The goal of this feature is a quick and effective creation of WordPress site backups for further processing outside of WordPress Toolkit. And this is the direction we’ll be focusing our improvements on in the next releases.

cPanel Support

Our efforts to make WordPress Toolkit work on cPanel are coming to a happy end soon, as the project is going through its final lap already. We still need to fix some issues and add a couple of things, but we’ve already hosted several demos for large hosters, getting very positive feedback.

The product will first launch with the novel pay-as-you-go licensing – available exclusively to a number of hand-picked partners. After a short period of time, it’ll become available to the general public, with a more traditional licensing scheme based on license tiers. Stay tuned for a special announcement to learn more about this landmark event.

Bug Fixes and Multisite Support

Our colleagues in cPanel helped us uncover a couple of potential security issues, which we have promptly addressed. We have also fixed several annoying customer bugs. As far as research goes, we needed to figure out the existing limitations of multisite support in the WordPress Toolkit, so we could improve it in the future releases. Extensive research into multisite support was conducted, and a lot of new information was unearthed. 

Now, we have a clear understanding of what we should fix to make WordPress Toolkit work better with multisites.

Future Plans – What’s Next?

The team is already working hard on WordPress Toolkit 5.0, which will also be the first public WordPress Toolkit release for cPanel. This version increase also warrants changes in WordPress Toolkit UI to make sure it focuses on important things and stays responsive, flexible, and useful. 

After the release of WordPress Toolkit for cPanel the team will have more free hands to work on feature requests and various improvements. So we expect a lot of interesting things to be released until the end of the year. Keep your feedback coming, and we’ll keep the releases going! 🙂

Once again, many thanks to the whole WordPress Toolkit team for their hard work. And thank you for your attention. If you have a question related to the Plesk WordPress Toolkit, please let us know in the comment section below. Until next time!

The Plesk WordPress Toolkit 4.9 Release – What’s New?

We’re happy to announce that the Plesk WordPress Toolkit 4.9.0 release is now available for the general public. As most of you probably know, this year we’ve been pretty busy working on WordPress Toolkit for cPanel. And even though 4.9 is not a huge update in terms of customer features, it certainly brings some long-awaited surprises in store. So, let’s deep dive into details to see what’s new.

Find out more about the Plesk WordPress Toolkit

Limit the Number of WordPress Installations in Service Plans

Hosters could always limit the access to WordPress Toolkit or some of its functionality through Plesk Service Plans. However, it wasn’t possible to set a limit on how many WordPress sites any given user could manage via WordPress Toolkit. This made things unnecessarily harder for some people. Because many Managed WordPress hosters do have these site limits as a part of their business. We’ve decided to address this glaring omission in WordPress Toolkit 4.9 and added this limit on the Resources tab of a Service Plan management screen:

Now, it’s possible to directly customize a particular subscription and change the limit. Service Plan add-ons also have this limit available. So, most kinds of possible upsell scenarios are covered.

The website limit will affect the ability to install WordPress sites via WordPress Toolkit. Add new sites using the Scan feature and create clones of existing sites. Note that so-called “technical” installations – e.g. clones made by Smart Updates don’t count towards the site’s limit, as they’re not visible to users in the interface.

By default, the limit is set to Unlimited. So nothing will change for users out of the box after the update to WordPress Toolkit 4.9. Some of you may ask what happens if the hoster defines a limit that’s lower than the number of sites the customer already has at the moment. In this case, the user won’t be able to add more sites. But existing sites won’t suddenly disappear from the interface. 

However, if the user removes or detaches a site, it won’t be possible to add another site back if the limit is reached. In other words, you can reduce the number of sites as you see fit. But you can’t increase it beyond the limit set for your subscription:

Configure Default Database Table Name Prefix

WordPress Toolkit generates a random prefix for database table names every time someone installs a new WordPress. This is to alleviate the impact of automated bot attacks looking for vulnerable WordPress databases using the default table prefix. For some users – especially WordPress developers, this behavior is quite annoying. So we added the ability to configure a specific default prefix for database table names whenever someone installs a WordPress on a server:

Here comes the tricky part. Generating a random prefix for database table names is a security measure in WordPress Toolkit. That it’s applied automatically during the installation of WordPress. If you set the default prefix back to ‘wp_‘, WordPress Toolkit will respect your choice and will not change this prefix. But it will set the site security status to ‘Danger‘ to tell you that this isn’t secure. This shouldn’t be an insurmountable challenge, like any other predefined prefix (be it ‘wp‘ or ‘wp___‘, or whatever else that is not ‘wp_‘) won’t trigger the security warnings.

If users want to return to the old behavior with a randomized prefix, all they need to do is to leave this field empty. This small QoL (Quality of Life) improvement should provide a number of users with more control over their WordPress Toolkit experience.

Working on WordPress Toolkit for cPanel

We’ve been doing a lot of work on the WordPress Toolkit for cPanel front during the development of WordPress Toolkit 4.9. For instance, we’ve added the capability to update the product in cPanel. And we started to really dig into the security and performance aspects. Addressing a lot of issues that both WordPress Toolkit and cPanel teams found. 

Features like Sets and Reseller support were also added in the scope of the current release. We’re actively working on licensing and test infrastructure at the moment. And while there’s still quite a lot of stuff left to do, we can already foresee a finishing date. Our WordPress Toolkit for cPanel will be good enough to be ready for a demo very soon. And we’re already seeing a lot of interest from various partners – woohoo!

Testing Amazon AWS Infrastructure and Other Stuff

There’s another hidden but very important activity going on behind the scenes for quite some time. And that’s the initiative of moving our regression testing to Amazon AWS infrastructure for extra speed, flexibility, and on-demand availability. This should allow us to test WordPress Toolkit on cPanel as often and as thoroughly as WordPress Toolkit on Plesk. 

Using AWS for testing should also allow us to run a suite of tests per each developer commit in the future. Bringing us closer to our goal of “green master” initiative – or in other words, having a product that could be released in a production-ready state at any given time.

Speaking of improving the product, some of the security and performance improvements done in the scope of WordPress Toolkit for cPanel should also affect WordPress Toolkit for Plesk in a positive way. WordPress Toolkit 4.9 includes a number of important customer bugfixes as well.

Future Plans

Our next major release will be Plesk WordPress Toolkit 4.10, tentatively scheduled to be launched by the end of summer 2020. This upcoming release coincides with the peak of the vacation season. So we won’t have the manpower to push any groundbreaking changes – they’re reserved for the next upcoming releases. 

However, you can rest assured that WordPress Toolkit 4.10 will include some in-demand customer features, bug fixes, and other interesting stuff on top of changes required for cPanel support. We’re also planning to release a small WordPress Toolkit 4.9.1 update very soon with a couple of new CLI utilities as a part of the CLI completeness initiative. The future of the product looks very busy, so stay tuned for updates – and especially, stay healthy! 

…So that’s all for the Plesk WordPress Toolkit 4.9 release. Remember that our teams are always on the lookout for new features to implement or bugs to crash. And here’s where your feedback is essential. You can share your suggestions or ideas for new functionalities to one of our channels – Uservoice, Plesk Community Discussion Forum, and Plesk Online Community

Or while you’re here, you can also leave your feedback in the comments below – our teams have eyes everywhere! Once again, thank you for reading. And cheers from the whole WordPress Toolkit team!

Next Level Ops Podcast: Solving the Most Common WordPress Problems with Lucas Radke

Hello Pleskians! This week we’re back with the eighth episode of the Official Plesk Podcast: Next Level Ops. In this installment, Superhost Joe and Product Wizard Lucas Radke talk about common WordPress problems and what hosting providers and users can do about them.

In This Episode: Noisy Neighbors, Fixing WordPress Problems, and What Hosting Providers Can Do

What are the most common WordPress problems for hosting providers? In what domains do common WordPress problems fall for most users? How much does WordPress itself mitigate these problems and what can hosting providers and users do? In this episode, Joe and Lucas discuss the three main areas under which WordPress problems usually fall — performance, updates, and security. You can have noisy neighbors when an environment is shared by too many users, impacting your website’s performance. 

Frequent updates are also often a pain point as non-updated plugins and themes can lead to security issues. Hosting providers should ideally provide solutions for this, otherwise it can lead to backdoors that compromise websites. For instance, tools such as Smart Updates for Plesk WordPress Toolkit analyzes WordPress updates and identifies and performs changes without breaking the production site. It also notifies users of any potentially critical updates. 

It’s essential for users to be proactive about potential issues from their side, especially non-savvy tech users. What can users do to ensure that they are taking the right precautions? The first thing is to make sure that they use a trusted web hoster who provides them with a secure hosting environment. Recently, WordPress has also had an increasing emphasis on security and recommends some basic security protections. For example, to make sure that access is limited, keeping backups, regular updates, and installing plugins and themes from trusted sources. For WordPress, security is about risk reduction.

“The great and terrible thing about WordPress is the amount of freedom you have. The freedom to set up whatever website you want considerably cheaply. But also the freedom to cause problems for either yourself, your client or your hosting provider,” says Joe, “Because if you’re on a shared host and your website is compromised, then it’s possible that other websites are compromised as well.”

Key Takeaways

  • What are some of the actions hosting providers can take to fix common WordPress issues? Hosting providers are responsible for how well the site performs. Users may expect high performance without paying the price for it. Many users install plugins to help with the performance or security of their website. The hosting provider has to make sure that plugins are updated and to make sure that there are no open doors for hackers. It’s also essential that hosting providers have a properly trained support team, specialized in solving WordPress issues.
  • What can users do to minimize some frequent WordPress problems? Being proactive is very important for users. Along with being informed about what’s happening in the community from a security perspective. Which plugins are having potential issues? What are some of the security issues coming up in the WordPress community? Trying to get the information that helps users reduce security risks should be a priority, especially for non-tech savvy users.
  • To what extent does WordPress mitigate these problems? WordPress has had a recently increased security focus. It’s forcing stronger passwords; it’s verifying email addresses; it has a site Health Checker and Troubleshooter performing checks on users’ WordPress installations; and other criteria for running WordPress sites securely.
  • Which plugins can mitigate some of the issues? iThemes Security is a useful plugin. Smart Updates for Plesk’s WordPress Toolkit has some cool features. WordPress Toolkit checks for updates for plugins, themes, and core. It can automatically perform updates if you choose to do so. Smart Updates makes sure that the proper changes are identified and implemented without breaking the live site.

…Alright Pleskians, it’s time to hit the play button if you want to hear the rest. If you’re interested in hearing more about WordPress hosting, check out this Next Level Ops episode. We’ll be back soon with the next installment.

The Official Plesk Podcast: Next Level Ops Featuring

Joe Casabona

Joe is a college-accredited course developer. He is the founder of Creator Courses.

Lucas Radke

Lucas is a Product Manager at Plesk.

Did you know we’re also on Spotify and Apple Podcasts? In fact, you can find us pretty much anywhere you get your daily dose of podcasts. As always, remember to update your daily podcast playlist with Next Level Ops.  And stay on the lookout for our next episode!

Discovering the Plesk WordPress Toolkit: Behind the Scenes

It goes without saying that WordPress is the most popular CMS in the world today. In fact, 37,8% of all websites use WordPress as a CMS. And considering that in 2020 there are over 1.7 billion active websites globally, almost 40% is quite an impressive figure (right?) That said, it’s no wonder why WordPress also dominates application installations in Plesk, such as our beloved WordPress Toolkit.

Additionally, this month we’re celebrating Plesk WordPress Toolkit has reached more than 1,600,000 WordPress websites throughout all Plesk versions and platforms. And we’re proud to say that for us, this milestone is huge. But, of course, this doesn’t end here. We’re looking forward to increasing this number and continuing its development by addressing our users’ needs. So, if these numbers have stumped you, read the rest of the article for more interesting facts.

Biggest WordPress Toolkit Feature Releases in 2020

Plesk WordPress Toolkit is one of our most treasured products. It might be because its all-in-one solution handles all WordPress installations from one single dashboard. And because it simplifies your daily workload and makes your life as a WordPress user much easier. While making sure your site is updated and protected against cyber threats. We understand – we love it too!

Whereas other abnormalities are still striking in 2020, our super team behind the WordPress Toolkit strives to deliver an enhanced product on every release. Let’s remember the major updates since the beginning of this year:

Developing WordPress Toolkit for cPanel

Whilst 2019 releases were mainly focused on radical improvements to our premium Smart Updates, 2020 has been the year for developing WordPress Toolkit for cPanel. In fact, we had a very good start with this ambitious project. And by the 4.8 release, we had made WordPress Toolkit on cPanel almost feature complete. Nonetheless, we still need to be patient before WordPress Toolkit for cPanel is available for the public. But we can assure you that the finish line is closer every day.

CLI for Smart Updates

After adding CLI for existing features such as cloning and data copy early this year – find out more here, the time for Smart Updates arrived. In WordPress Toolkit 4.8 we added the first part of Smart Updates CLI, allowing hosters to enable and disable Smart Updates on a site.

Website URL Update

One of the frequent cases our partners encounter is the migration of websites to their servers by customers. WordPress stores the website URL in its database – and sometimes, in the configuration file. Therefore, such migrations require some manual tinkering to make the website work as usual. To help users, we added the ability to perform this action with a couple of clicks straight from the WordPress Toolkit user interface. This feature is called “Update Site URL.”

Disable wp-cron.php Execution

To facilitate the ability to disable wp-cron.php, we added a one-click switch on each website’s card. Turning the switch on will automatically create a scheduled task that runs wp-cron.php every 30 minutes. And it will also disable the default wp-cron execution by adding a specific line to wp-config.php file. Pretty useful indeed.

Default WordPress Installation Language

Finally, in 2020 we also delivered this quite handy functionality. 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.

Did You Know? – The Team Behind It All

All these great achievements wouldn’t have been possible without our technical team. And to recognize their hard work and commitment throughout these years, we want to dedicate some time to them. So, let us introduce you to Andrey Kugaevsky, Product Manager at Plesk – aka the WordPress Paladin. Even though we’re sure you’ve probably heard Andrey before in one of our official Next Level Ops Podcast or read one of his articles in our blog.

Andrey and his team sweat their work out to make WordPress Toolkit the star of the show. With that in mind, we’re inviting you to meet the team behind our beloved product. Let’s hit the play button:

Your Feedback is Also Essential

And of course, our technical team wouldn’t be able to achieve such great achievements if it wasn’t because of our users’ contributions. There are different ways you can use your voice and help Andrey and his team to make the WordPress Toolkit even better. Our Program Managers are in permanent contact with support teams for gathering information before choosing a new product feature for implementation. And for some top features, they test hypotheses on-site or create surveys and send them to customers for review.

If you have feedback on WordPress Toolkit or ideas on how to improve it, making it more useful to you and your clients, you can check out this article to find out more about how to contribute.

Get Started with Our Current Offers

Now that you know a little bit more about what’s going on behind closed doors, you may want to give Plesk WordPress Toolkit a try. Currently, we’re offering 6 months free for WordPress Toolkit on a yearly subscription, including remote management for agencies. Additional details about these offers can be found here.

Or if you’re already familiar with our product and your curiosity got you this far, why don’t you tell us your experience with Plesk? You can let us know in the comments below. We’re all ears!

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!