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:
- Provision a subscription-based on a service plan with a specific Additional Service that installs WordPress with a particular set.
- Install a set together with WordPress when you install a new WordPress site.
- 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.
- 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.
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!
Oh no, sorry about that!
Let us know how we can do better below
Tell us how we can improve this post?