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.

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.

#plesk news and announcements #wordpress