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!

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!