Your needs come first so rest assured that we’re constantly evolving Plesk to bring you more value. Hence, the release of WP Toolkit 3.5, introducing an assortment of new security measures, a reimagined installation experience and more. Read on for a detailed overview of the updates you wanted, a WP Toolkit tour, plus WP Toolkit 3.6 spoilers.
Quick Tour of the updated WP Toolkit
Our pal Joe Casabona was one of the first to take the new WP Toolkit 3.5 for a spin. Here’s him demonstrating how easy it is to install and secure your WordPress, update multiple sites, clone and create a staging environment. All in just over 7 minutes!
New WP Toolkit Security Measures
First, you’ll likely see this notification pop up or find your previously secure instances suddenly marked as insecure. But don’t be alarmed – this just means you need to review and update the security status of your WordPress instances. Why? Because WP Toolkit 3.5 introduces 8 new security measures.
1. New Hotlink Protection
Preventing other websites from displaying, linking or embedding your images (hotlinking), as this quickly drains your bandwidth and can make your site unavailable.
2. Disable unused scripting languages
This security measure removes support for the scripting languages WordPress doesn’t use, like Python and Perl. Thus, blocking their related vulnerabilities. Available if you have the corresponding Hosting Settings management permission.
3. New Bot Protection
Blocks bots that overload your site with unwanted requests, causing resource overuse. Note that you may want to temporarily disable this if you also use a service that scans your site for vulnerabilities, since it may also use bots.
4. Disabled file editing in WP Dashboard
This measure prevents you from editing plugin and theme file sources directly in the WordPress interface. This is an extra protection layer for the WordPress instance in case an admin account is compromised so no malicious executable code gets into plugins or themes.
5. Block access to sensitive files
Now you can choose to block files like wp-config.bak and wp-config.php.swp, from public access as they contain sensitive information, like connection credentials. Thus, also preventing exposure of files with info used to determine your WordPress instance. Also included are files like logs, shell scripts and other executables that may exist on your WordPress instance and whose security can be compromised.
6. Block author scans / user ID phishing
These scans find registered usernames, especially WordPress admin, and brute-force attack your site’s login page. The above block prevents this, but note that depending on your site’s permalink configuration, you may also be preventing visitors from accessing pages that list all articles by a certain author.
7. Block access to .htaccess and .htpasswd
Attackers who gain access to .htaccess and .htpasswd files can exploit your site to a variety of breaches. These files aren’t usually accessible by default, but sometimes they might be. This is where this security measure steps in.
8. Disable PHP execution in cache directories
If a compromised PHP file ends up in one of the cache directories of your site, executing it can lead to compromising the whole site. So this measure disables execution of PHP files in cache directories to prevent such exploits. However, certain plugins and themes may ignore WordPress Security recommendations and store valid PHP executables in their cache anyway. So you can disable this security feature for them to work, or find a more secure alternative, as recommended.
You’re in Control of Security Updates
You should be able to supervise any website-affecting changes so WP Toolkit won’t automatically apply these new security measures on existing installations. So upon opening your list of WordPress instances after the WP Toolkit 3.5 update, you’ll see a one-time notification about this.
On that note, you’ll now see that two existing security measures are now less restrictive. First, the “Security of the wp-includes directory” checker now excludes the wp-tinymce.php file to avoid potential issues with Gutenberg and other editing plugins. Second, the “Security of the wp-content directory” measure now prevents the execution of PHP files only in the wp-content/uploads directory.
These checkers will be reapplied automatically for convenience and do not reduce WordPress security in any noticeable way.
New WP Toolkit 3.5 Installation Experience
WP Toolkit previously offered two installation options: Quick and Custom. Both had unfortunate shortcomings. ‘Quick’ didn’t ask you questions, but also didn’t give info on the parameters to use when installing WordPress. ‘Custom’ gave you control and displayed everything, but you had to fill out the form.
Now users can make an informed choice whether to confirm defaults and install WordPress quick, or take time to change the options they want. With the new, unified WordPress installation, you can still install WordPress in one click, but you’ll always know how it’s happening. Meanwhile, you can change all relevant installation parameters when necessary.
Bonus: You now have to enable automatic updates of plugins and themes within a more streamlined form, without Search Engine Visibility and Debug Mode.
The final change to the WordPress installation process is the ability to install on any domain from any accessible subscription. This is available anytime you click WordPress in the left navigation panel, even if you’re a reseller or server admin. One small step for WP Toolkit, one giant leap for adminkind.
WordPress Classic Plugin anyone?
If you’re not yet ready to use Gutenberg, you have a new ‘WordPress Classic’ plugin set. It also has a sibling ‘WordPress Classic with Jetpack’. However, note that we don’t plan to add immediate support for ClassicPress.
Updates to CLI
We updated the CLI command for the new WordPress installation. Specifically adding -auto-updates, -plugins-auto-updates, and -themes-auto-updates to the plesk ext wp-toolkit install command. And plesk ext wp-toolkit –clear-wpt-cache to clean WP Toolkit cache and handle issues with invalid cache data like corrupted WordPress distributive lists, or broken lists of languages and versions.
WP Toolkit 3.6 Spoilers
The Plesk team fixed a record 43 issues reported by customers and over 140 bugs reported overall. Moving forward, WP Toolkit 3.6 will lay foundations for the upcoming release of Remote Management for WP Toolkit. Plus, we’re continuing the switch to the new UI, this time redesigning the Clone and Sync procedures along with more relevant user-requested improvements. We’re also busy improving our internal process so we can deliver more high-quality stuff in less time, so stay tuned!
Thanks for the post. I don’t think I’m the only one who is a bit confused about the WP Toolkit clear cache commands. Could you explain exactly what these two commands do?
plesk ext wp-toolkit –clear-cache -instance-id 1
plesk ext wp-toolkit -clear-wpt-cache
The –clear-cache command clears the cached information about a specific WordPress instance (such as version, installed plugins, themes, etc.) from the WordPress Toolkit database and reads this information from the instance again.
The –clear-wpt-cache command clears the cache of the WordPress Toolkit itself, i.e. removes objects from /usr/local/psa/var/modules/wp-toolkit/cache/ directory, such as cache of plugins and themes from wordpress.org, list of available WordPress versions, etc.
Any updates as to ClassicPress support?
We do not have plans to include ClassicPress support at the moment, but we are monitoring the situation around ClassicPress to assess its popularity among our customers.
Thank you for the post, much needed measures here.
one thing that has me tearing my hair out is whitelisting websites for hotlinking. my use case is allowing paypal checkout pages to show the 150×50 img via url.
I assume google and other engines are allowed to search?
where is this done and how can we modify it?
many thanks again.