New Releases Archives

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.

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

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!

New Releases Plesk Updates Plesk WordPress Toolkit smart updates WordPress WordPress Toolkit WordPress Toolkit for cPanel

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!