Plesk Updates Archives

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.

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:

If your PHP version has reached End of Life but still supported by WordPress Toolkit, you will be notified about this as well:

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:

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

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 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.

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!