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.1 Release – Backup Limits, Localization Support, and More

We’re proud to announce that the Plesk WordPress Toolkit v5.1 is now publicly available. So, let’s see what this release brings to the masses.

Discover the WordPress Toolkit 5.1

Backup Limits

Backup functionality was introduced back in WordPress Toolkit v4.10. And we have already received quite a lot of feedback about it. The most popular request was about limiting the number of available backups to prevent end-users from subtly eating up all their storage space. We’ve added the limit to Plesk Service Plans under the Resources tab:

The limit is enforced on a per-site basis for the whole subscription. So, each site on a subscription gets to create the allowed number of backups. If you set the limit to 0, the backup feature becomes unavailable to end-users. Which is handy for those admins who want to fully restrict access to the new backup feature.

cPanel changes

A month ago we released WordPress Toolkit for cPanel. And we’re striking the iron whilst it’s hot. That means we’re implementing a lot of changes specific to cPanel. Let’s quickly go through them:

Database User Management

The Database User Management feature was already available in Plesk before. Unfortunately, though, it didn’t fit into the WordPress Toolkit 5.0 schedule. Since we want WordPress Toolkit to be as identical as possible on both Plesk and cPanel, we’ve added this ability in WordPress Toolkit 5.1:

New Security Measure

The “Block directory browsing” security measure was missing in the initial release of WordPress Toolkit 4 for cPanel. This was due to certain technical issues we didn’t have the time to properly resolve back then. Now, we’ve fixed everything that needed fixing. So we’re introducing this security measure on cPanel:

Localization Support

WordPress Toolkit v5.1 now supports multiple different languages on cPanel. Whenever you change your language in WHM or cPanel, WordPress Toolkit will also switch to this language. This change affects both WHM (with server-wide locale setting) and cPanel (with user-specific language setting).

Changelog

WordPress Toolkit changelog isn’t the easiest thing to find, especially for cPanel customers. To remedy this, we’ve added the ability to view product changelog from the global WordPress Toolkit settings:

WordPress Toolkit has a single unified changelog for both Plesk and cPanel, since it’s the same product, just on different platforms. Filtering out information about the platform you need isn’t particularly easy. We’re looking into improving the changelog UI and UX in the future.

Improvements, Bugfixes, and Future Plans

Speaking of changelog, it clearly shows that WordPress Toolkit 5.1 includes more bugfixes than usual. But don’t worry – This is not caused by the sloppiness of the WordPress Toolkit dev team. We’re simply putting more focus on the stability and robustness of the product, which means fixing more bugs 🙂 

Besides improving site list performance on cPanel, we’re also planning to implement several internal enhancements. That hopefully will make WordPress Toolkit more stable and robust, leading to fewer bugs down the road. We’re also going to address a couple of other hot topics. Like adding sets for resellers by the end of 2020 – but we’ll get back to you with it when it’s fully developed. 

One of the upcoming WordPress Toolkit releases will focus heavily on addressing issues related to cloning, which should also improve Smart Updates’ performance.

…As you see, we have a lot of things in store for the future. So stay tuned for the upcoming WordPress Toolkit releases. And drop us a line in the comment section if you’d like to share your experience with us. Thank you for your attention and see you next time!

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!

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!

Deep Dive Into WordPress Toolkit 4.7 Release

WordPress Tookit 4.7 is the third major WordPress Toolkit update in 2020. It’s also the first update developed and released by a team working completely remotely due to the current lock down. We’re happy to announce that we were still able to deliver as planned. Read on to learn what was added in this release.

What’s WordPress Toolkit?

Update of Paid Plugins & Themes

Most WordPress agencies and web developers are using paid plugins and themes in their projects. Same goes for WordPress admins who’re at least semi-serious about their site. The main problem with such plugins and themes was that they’re not hosted on wordpress.org. Thus, WordPress Toolkit couldn’t detect their updates and install them. This deficiency led to a miserable user experience where you could update a bunch of plugins and themes via WordPress Toolkit. But for the rest, you had to go through WordPress itself. The Smart Updates feature also couldn’t update such plugins and themes, hence limiting its usefulness.

I’m not exaggerating when I say that this was the main known showstopper on the critical user path in WordPress Toolkit. This is why I’m very happy to announce that we have removed this showstopper in WordPress Toolkit 4.7. If you can see and install the plugin or theme update in WordPress itself, you can do the same in WordPress Toolkit now. Let’s take a closer look.

Here’s how these updates are displayed in WordPress itself:

WordPress Toolkit displays these updates in the same way it displays updates for plugins and themes from wordpress.org:

We can update everything that can be updated in WordPress itself in a way familiar to WordPress Toolkit users:

After the update is performed, you can see the version change confirming the update success, same as with free plugins and themes from wordpress.org:

 Just to be sure, let’s check what WordPress itself says about the update:

Alles gut! Smart Updates will also be able to handle these updates in the same way they handle updates of regular plugins and themes. Same goes for automatic updates, if they’re enabled for a particular site.

There’s one important caveat that needs to be mentioned, though. Certain paid plugins and themes require a license to be updated automatically:

Right now WordPress Toolkit will try to update such plugins and themes anyway. And everything will look as if the update was successful. But when you check for updates again, you’ll see that nothing was actually updated. We’re planning to handle this in one of the next WordPress Toolkit releases. It’s not that big of a deal, given that WordPress itself won’t be able to update such plugins and themes. But it’s still something we’d like to iron out in the future.

We hope that the ability to update paid plugins and themes via WordPress Toolkit will make life easier for many WordPress pros. 

Ability to Disable wp-cron.php Execution

WordPress has its own scheduled task responsible for handling time-based jobs like checking updates, publishing scheduled posts, and so on. This script (wp-cron.php) is run every time a page on a WordPress site is accessed. Such behavior might be fine for websites with low traffic, but when your site gets more popular, the strain caused by running this task too often can lead to reduced server performance. That’s why many WP pros recommend to “disable wp-cron” — a short way of saying “turn off the default way of executing wp-cron.php and instead run an external scheduled task on a specific predefined schedule”.

To facilitate this operation, we have 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. It will also disable the default wp-cron execution by adding a specific line to wp-config.php file. 

If a user has the permission to manage scheduled tasks, a ‘Setup’ link will appear in the interface:

Clicking the link takes you to editing the parameters of the external scheduled task in the native control panel interface. If you want to run the task on a different schedule, you can modify it on this screen, using familiar Plesk controls:

The task created by WordPress Toolkit is a standard scheduled task that can be accessed on the Scheduled Tasks screen in Plesk at any time:

This is done to ensure operational transparency and the ability to easily manage the parameters of the scheduled task. To ensure the robustness of this system, WordPress Toolkit is regularly checking whether the scheduled task still exists. If a user accidentally deletes this task, WordPress Toolkit will recreate it very soon. 

Disabling wp-cron is a well-known trick in the WordPress community, so some users might’ve manually done that already. If this is the case, the WordPress Toolkit will detect the changes in the wp-config.php file, and the state of the corresponding switch will be adjusted automatically. However, we can’t reliably tell which scheduled task was manually created by users to handle the launching of wp-cron.php, so users might have two scheduled tasks running. The solution is simple: you can either leave both tasks running (shouldn’t be a big deal in terms of performance). Or you can remove your own old task and modify the task created by WordPress Toolkit to make it work the way you want it to work.

Server administrators also have the ability to enable this option by default on all new WordPress installations. This is done by selecting the corresponding checkbox in the global WordPress Toolkit settings:

Toggling the feature off on a site will update the site’s wp-config.php file and remove the corresponding scheduled task, so if something starts working incorrectly, the changes are fully reversible. 

UX Improvements 

WordPress Toolkit 4.7 includes two more changes requested by users. Both are UX improvements that should make working with WordPress Toolkit more comfortable for all users.

Remember the site labels introduced in WordPress Toolkit 4.5? Now you can filter all your sites on the ‘Installations’ tab by these labels, making it easier to work with a large number of sites:

If you’re looking at your Updates screen and wondering what exactly is included in a particular plugin or theme update, you can now click on the ‘Changelog’ link to open the corresponding page:

Bugfixes & Other Improvements

We have synchronized the timeouts between WordPress Toolkit and our screenshot service to make sure less screenshots end up in limbo because of miscommunication between the two systems. We have also fixed several customer bugs, including a serious bug that prevented updates of remote WordPress sites connected via our plugin. Our next release will include more fixes of customer-reported bugs from our backlog, with some internal improvements to boot. 

WordPress Toolkit for cPanel and Future Plans

Behind the scenes we are continuing to develop WordPress Toolkit for cPanel. So far, the team has finalized the development of cloning functionality, added the ability to remove WordPress websites, and introduced the Smart Updates feature. 

On the cPanel integration front we’re going to add the Data Copy feature, introduce additional security measures, start working on the product licensing, and work on a number of internal improvements. When it comes to new customer features, we already have a shortlist of candidates to choose from. And they all look very promising. We can’t wait to unveil new stuff for our customers.

Thank you for reading all the way to this point. We hope that your WordPress Toolkit experience will continue to improve. And we’re already hard at work to make it happen. Until next time!

WordPress Toolkit 4.6 is Now Available

WordPress Toolkit 4.6 is Now Available - Plesk

We’ve just released the WordPress Toolkit 4.6 update – the second update in 2020. Read on to learn about the new things we introduced. Including Website URL updates, Cloning and Data Copy CLI, and other improvements. Plus, a heads up on further plans regarding WordPress Toolkit and cPanel.

Discover WP Toolkit

Website URL Update

One of the frequent cases our partners encounter is the migration of websites to their server 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’ve added the ability to perform this action with a couple of clicks straight from WPT UI.

This feature is called ‘Update Site URL‘ and it’s available in the ‘hamburger’ menu on a WordPress site card:

wordpress-toolkit-4.6-update-website-url - Plesk

When the WordPress admin clicks the link, WordPress Toolkit checks the actual site URL. Basically, what you’re seeing in the site card header. And then compares it to what WordPress thinks is the site URL. If these two URLs match, all you can do is close the window and live happily ever after.

wordpress-toolkit-4.6-update-site-url-2

If the URLs don’t match, WordPress Toolkit offers you a one-click update site URL in WordPress. Synchronizing it with the actual URL where the site is currently hosted (according to the control panel.)

wptk-4.6-update-site-url-3

The process is quite quick: we’re looking for the “wrong” URL in WordPress database and wp-config.php file, replacing it with the “right” URL:

wptk-4.6-wordpress-website-url-4

However, there are certain edge case limitations to this feature. For example, it’s not available for multisite installations (yet). So, we’ll take a look at our customer feedback before deciding our next steps. Meanwhile, this feature should be a time-saver for hosters and agencies who deal with migrated websites on a regular basis. It should also help non-professional users who’re scared of running wp-cli or modifying their site’s database directly.

Cloning CLI

We’re officially introducing CLI for cloning procedures in WordPress Toolkit 4.6. This feature provides access to a full range of cloning options via the command line interface. Here’s the brief usage info:

plesk ext wp-toolkit --clone

   -source-instance-id INSTANCE_ID

   (-target-domain-name DOMAIN_NAME | -target-domain-id DOMAIN_ID)

   [-target-path PATH]

   [-target-db-name DB_NAME]

   [-target-db-server-id DB_SERVER_ID]

   [-target-db-user-login DB_USER_LOGIN]

   [-force-overwrite yes|no]

   [-format raw|json]

   [-show-progress yes|no]

You may notice there are no commands for creating a new subdomain during cloning – something that’s actually available in the UI. We’re talking about CLI, which is used for integration and automation. So, there are assumptions that server administrators will use panel CLI/API to create subdomains before running the cloning CLI.

Data Copy CLI

WordPress Toolkit 4.6 also introduces the CLI for data copy feature. Thus, allowing server administrators to perform everything they need via the command line interface. Here’s some brief usage info below:

plesk ext wp-toolkit --copy-data

   -source-instance-id SOURCE_INSTANCE_ID

   -target-instance-id TARGET_INSTANCE_ID

   [-data-to-copy all|files|db]

   [-files-replace-modified yes|no]

   [-files-remove-missing yes|no]

   [-db-tables-copy-mode default|all|new|selected]

   [-db-tables COMMA_SEPARATED_LIST_OF_TABLE_NAMES]

   [-exclude-db-tables COMMA_SEPARATED_LIST_OF_TABLE_NAMES]

   [-create-restore-point yes|no]

   [-show-progress yes|no]

WordPress Toolkit 4.6 Bugfixes and Improvements

We’ve revised our bug backlog to make sure we’re addressing multiple customer issues in this release. To improve our team efficiency, we have started to use Amazon AWS to run some of our tests. We’ll continue investing in improving our development and testing process. All to make sure we can deliver more things with higher quality in time.

WordPress Toolkit for cPanel and Future Plans

We’ve made a lot of progress on the cPanel front with regards to WordPress Toolkit 4.6. Particularly the development of WordPress installation function and providing full CLI support. We also addressed a lot of fundamental UI integration questions, and even cooked up a prototype of the cloning functionality. We have already switched to the “make it work everywhere” paradigm when developing new features. So, our new ‘Update Site URL’ feature is also available in the current cPanel build.

wordpress-toolkit-4.6-in-cpanel

In light of our next release, we’re planning to continue working on the cPanel integration. This includes: finalizing cloning, introducing Smart Updates, and starting to catch up on the additional security measures. Our next release, WordPress Toolkit 4.7, will also include fixes of customer-reported bugs and some long-awaited user features and improvements.

Thanks again to the whole WordPress Toolkit team for their hard work, and thank you for your attention. Until next time!