WordPress plugins are written by enthusiasts and professionals with vastly different skill levels, so it’s natural that plugin quality varies dramatically from plugin to plugin. This causes WordPress-oriented hosters to look for ways of restricting certain plugins, whether because they’re putting a larger-than-needed load on the server, interfere with other services, or simply aren’t secure enough. To help hosters with this, WordPress Toolkit introduces a server-wide plugin blocklist that does just that:
That’s not the end of this feature, though — we’re already working on adding email notifications about deactivated plugins, but they will arrive in future releases!
WordPress Core Checksum Verification
When malware infects WordPress sites, it can embed itself in .php files that make up WordPress core. Thankfully, these files aren’t supposed to be modified, so we can check if they were tampered with by comparing their md5 checksums with the reference checksums of original files provided by wordpress.org:
If WordPress Toolkit finds any signs of trouble, it will warn the site admin, saying that something’s not right. At this point site admin can one-click reinstall WordPress core files, replacing the modified files with the non-modified originals:
Both checksum verification and WordPress reinstallation are done without loading WordPress itself for security reasons. Reinstallation should not affect any site data, but users will be prompted to create a backup before proceeding if they want (just in case).
Important note: this feature cannot check index.php, wp-config.php, or other similar files that contain installation-specific data and don’t have a reference checksum. Checking these files will require a different feature, and that’s a tale for another time.
WordPress In Plesk Dynamic List
The new Dynamic List introduced in Plesk Obsidian lacks some shortcuts to key WordPress Toolkit functions. This problem is now in the past, since WordPress Toolkit v5.6 adds a ‘WordPress’ tab on Dynamic List site cards where WordPress is installed, featuring these shortcuts:
Changes Under The Hood
There are several cool features introduced in WordPress Toolkit v5.6 that require a special mention:
- It’s déjà vu time: wp-cli utility was updated again, this time to version 2.5. With this change, all WordPress Toolkit features, including cloning, should fully work on PHP 8 without any issues. Unfortunately, this update required us to drop support for websites working on PHP 5.4 and PHP 5.5. The websites themselves will continue to work, but WordPress Toolkit won’t be able to manage them. As a sidenote, error handling and reporting related to PHP 8 was also improved.
- After wp-cli was updated to the latest version in WordPress Toolkit v5.3, we’ve learned that several useful wp-cli commands were split into a separate bundle. Users have been asking us to include this bundle, because these commands are helpful, so wp-cli-bundle is now shipped together with wp-cli utility.
- You can now delete WordPress sites through CLI using the new —remove command. I’d like to remind everyone that with this great power comes great responsibility, so make sure you know what you’re doing — it no longer asks for your confirmation!
WordPress Toolkit v5.6 introduces a variety of smaller changes that should improve quality of life for every WordPress Toolkit user. Let’s quickly go over them:
- You can already filter out entries in WordPress Toolkit action log but finding the context (i.e. what happened before or after) can be a bit of a pain. To remedy this, we’ve added a special ‘Show in context’ icon to the right of each filtered entry. Clicking this icon resets the filter and shows you your entry in the context of the whole log:
- ‘Hotlink protection’ is a previously-added security measure that isn’t strictly a security measure. This might sound hilarious, but it caused a number of confusions (like product images not displayed in email notifications sent by WooCommerce plugin). The cause is simple: certain people tend to enable all security measures without realizing that some of these measures are only needed in specific cases, and some of these measures are actually tools, like our Hotlink example. To avoid these issues, we have moved this option from ‘Check security’ window to a separate switch:
- All e-mail notifications sent by WordPress Toolkit on Plesk now include server hostname in the message subject for easier identification. This information is part of the notification template, so server admins are free to modify or remove it.
- The Domain management link in Plesk has been renamed for clarity:
- Cloning (and, subsequently, Smart Updates) now properly supports most popular caching plugins. To be more specific, most caching plugins were already supported and worked just fine, but we’ve found a couple of plugins that misbehaved. Not only have we made these rogue plugins work correctly after cloning, but we’ve also made the cloning procedure more robust in general, so there might be some positive side effects.
- WordPress Toolkit now automatically assigns the corresponding database to a site after it’s installed or cloned on Plesk for a better user experience. This change also works with the restoration of backups containing WordPress sites in Plesk.
- The Update process that involves multiple items now works significantly faster due to skipping many unnecessary operations. On a related note, Smart Update procedure itself also works a bit faster in a number of cases.
- Speaking of Smart Updates, detailed information is now provided about which .htaccess customizations prevent WordPress Toolkit from creating a proper site clone.
This article already mentions some of our plans for the future, but it’s too early to reveal all our cards. Rest assured WordPress Toolkit v5.7 will include both improvements of existing features and new, exciting functionalities. Until then, thank you for your attention and see you next time!