WordPress is the most popular CMS in the world today, powering more than 74 million websites in the world and 47% of all websites using a CMS. It’s giving birth to dozens of millions of new posts and comments each month, and that’s just the tip of the iceberg. WordPress also dominates application installations in Plesk – in fact, it comprises almost two thirds of all known applications installed on Plesk servers. After looking at all these numbers, it should not be a surprise for any person involved in hosting industry that we have decided to address the growing market of WordPress users by adding a tool that helps them manage and secure their blogs. Enter WP Toolkit, available in Plesk 12:
In this article I will explain the ways WP Toolkit helps WordPress hosters and users, address some misconceptions, answer several frequently asked questions, and share some spoilers about what’s to come in the next versions of WP Toolkit.
WP Toolkit – Mass management
The first aspect where Toolkit helps a lot is mass management of WordPress installations. The worst kept secret of WordPress administration is that performing operations like installing, updating, activating, deactivating or removing your plugins on a number of WordPress instances is pretty much exhausting. Sure, WordPress UI allows its administrator to manage almost anything – but only for this particular WordPress instance. As an admin who manages multiple WordPress blogs, I don’t really like to jump between menu items on each WordPress installation every time I need to, say, update Akismet to the latest version. The idea that one can simply click “Update” once and relax with a cup of tea while Plesk does all the work could definitely cheer many WordPress admins up.
WP Toolkit makes this one-click mass management idea a reality. Since Plesk works with multiple domains and, subsequently, WordPress installations, we theoretically have all the tools to elegantly address the lack of built-in mass management in WordPress (I’m not counting multi-site installations, as they are a special case not applicable for most users). In particular, the Toolkit handles mass management of such aspects as security, updates, plugins and themes, as most other things are specific to a particular WordPress blog and cannot be managed en masse. These four aspects, however, can be addressed quite handily, so if you need to perform certain action (or even multiple actions) on a number of plugins, themes or WordPress installations, the Toolkit offers you the functionality to do it without logging it to a single WordPress blog – and without even knowing the access credentials. So, the question is, how exactly we do it?
To avoid reinventing the wheel, we decided to use a small but powerful utility called wp-cli, which allows managing WordPress installations through command line. We’ve patched the utility to better suit our needs and, since it’s available only for Linux platforms natively, we’ve ported it for Windows to make our Plesk for Windows users happy as well. Unfortunately, usage of this utility means we can only support WordPress versions 3.4 or higher – but let’s be frank, for the sake of security alone nobody should be using software that outdated. Once user initiates an action in Plesk UI, the utility is launched with necessary parameters, performing whatever operations user wants.
As a sidenote, using command line for mass management is not the most efficient way – something that’s generated a couple of funny incidents early in the development (“You are downloading the same plugin ten times when installing it on ten WordPress instances? Duuudeee…”). That’s why we’re looking forward to WordPress 4.1, which promises to include JSON REST API plugin in WordPress core. This will allow us to make WP Toolkit much more efficient and faster for those who will use WordPress 4.1 and higher (as a bonus, there’ll be more incentive to upgrade).
WP Toolkit – Security
The second aspect where Toolkit really makes a difference is security. Plesk team takes security very, very seriously, so a lot of time spent on WP Toolkit was focused on making sure we can help WordPress hosters keep their servers secure. Many WordPress administrators new to the world of blogging don’t realize how important website security is, and make no attempts to secure their blogs. If their website is hacked, this can affect not only the admin of compromised WordPress installation, but also the company that’s hosting it – for example, by turning the hacked blog into a nest of outgoing spam and getting the whole server blacklisted.
The security aspect of the Toolkit is two-fold. First, we wanted to give WordPress admins an extremely easy and robust tool to quickly secure their blogs without spending a lot of time reading about a myriad of possible security measures and choosing between countless security plugins that conflict with each other. Second, we wanted to provide a certain degree of automation when it comes to ensuring WordPress security, since in order to manually use the tools we provide, people have to actually care about security.
To create a tool that allows users to secure their WordPress blog, we’ve studied many sources, ranging from WordPress Codex to obscure blog posts, and consulted with WordPress experts. This allowed us to define a number of universally applicable security improvements that can be enabled without causing bloggers too much inconvenience, wrap these improvements up in user-friendly form and put them straight in Plesk UI. I’m not going to explain here what exactly we do in each particular case, because this information is readily available in Plesk itself (hover your mouse over the question mark next to each improvement in Plesk) and in user documentation, however, some things are definitely worth mentioning.
Multiple improvements from the list are applied on the web server config level. In the wild these changes are typically done by modifying .htaccess file, which, if customized, takes preference over web server config. We’ve decided to leave .htaccess alone for multiple reasons (danger of overwriting customer data, difficult to roll back safely, .htaccess might not be available at all, etc), so users are free to play with it as they see fit. Note that WP Toolkit will not detect changes made in .htaccess file, so actual security status for these items might not be displayed correctly by security scan feature. This means that if a customer has access to .htaccess file, he or she can overwrite the security directives through this file and be happily hacked down the road.
It’s important to note that there are two security measures that can actually affect the functioning of a WordPress blog, in particular, its plugins, so we have put them in a separate group. These items forbid execution of PHP in wp-includes and wp-content folders, respectively. In many cases, plugins won’t be affected by these limitations, and if they do, I suggest reading up on them and thinking twice before installing them to avoid debacles like TimThumb vulnerability. Nevertheless, since the main requirement for our security improvements is to avoid affecting the user experience or data, these two security items are not applied by default – you have to enable them by yourself.
Speaking of defaults, this is how we’ve handled the second aspect of WordPress security – automation for those who do not know or care about security. Since all our security improvements, except the two mentioned above, are perfectly safe to perform during the installation of WordPress, we are applying them automatically whenever your users are installing APS version of WordPress through Plesk interface. This takes no more than 2 seconds per instance on average, but it gives you robust WordPress security out-of-the-box. Now you won’t have to worry about your clients compromising your server by being too lazy or clueless to secure their blogs.
Going deep
Now that we’ve discussed how WP Toolkit helps both hosters and WordPress administrators, it’s time to talk about some of its less obvious features and quirks.
Manual installation
We know some users and hosters do not use APS catalog (basically, the contents of Applications tab) for installing applications, opting to install WordPress through other means (for example, manually). We didn’t want to discriminate such installations, so we’ve decided to support them. To understand if there’s a manual WordPress installation, we browse files on a subscription, looking for location of wp-content and wp-includes folders. We are also looking for for wp-config.php file to get DB credentials and table prefix. These basic steps make adding manually installed WordPress blog to the Toolkit and managing it a piece of cake – unless you broke it beforehand, of course. If WP instance is corrupted (missing files and folders, incorrect or missing database credentials or table prefix), it will not be added to the list of WP Instances. If your installation of WordPress is fine, the Toolkit offers virtually the same features for managing it as for APS installations.
Upgrade order
Some experienced WordPress administrators have expressed their worry about the order in which things are upgraded by WP Toolkit. The problem with upgrading WordPress is that if you upgrade the core first and go for plugins next, it might break your website. Updated plugins work with both old and new WordPress versions, while outdated plugins might not know how to work with a new WordPress version. To the people who were wondering about how the Toolkit does it: don’t worry, if you click “Update All”, we update plugins first, then themes, then WordPress core itself. This ensures that plugins will not break during the upgrade of WordPress core, as they should be already compatible with the version of WordPress that’s being installed.
Plugins and Themes
Another things that confuses people is the scope of Plugins and Themes tabs. When you do something with a plugin on Plugins tab, which WordPress installations does it affect? Well, installing, activating and removing plugins (and themes) from Plugins (and Themes) tab will affect all possible WordPress installations. So if you install a plugin from Plugins tab, it’s installed on all WordPress blogs that are shown on the WordPress Installations tab (except the ones that already have this plugin – another funny incident we’ve addressed early in development). Our internal usability testing told us that this logic is difficult to understand if you’re not a telepath, so we’re planning to fix this in the next version of Plesk – stay tuned and watch out for preview builds.
One question I’ve also heard from people was “how do you ensure that all these plugins and themes are up to date, since there are so many of them?” Actually, it’s real simple: when you want to install or upgrade a plugin or theme through WP Toolkit, we’re showing you the list of items fetched directly from wordpress.org. Basically, what you see is as up-to-date as wordpress.org allows it to be, we’re not hosting mirrors of the whole plugin and theme repository (and thank goodness, as there are almost 30,000 WordPress plugins available, and a new one is added nearly every hour). This means that you and your users have 24/7 access to the latest WordPress plugins and themes from the biggest repository on the web, and you’ll be getting update notifications within 24 hours of their availability.
Update notifications
Speaking of notifications, there were multiple complaints from hosters about getting WordPress update notifications all the time. This is not actually a Toolkit issue by itself – since WordPress is an app, you are getting notifications about it if you chose to receive app update notifications (well, not exactly “chose” as they are enabled by default, but I digress). Anyway, if you’re annoyed by this, simply go to Tools & Settings > Notifications and clear whatever checkboxes next to “APS application updates” are causing you grief:
Future of WP Toolkit
Obviously, we’re working on improving WPTK as we’re getting overwhelmingly positive reaction from people around the world. In particular, we’re looking into the following:
- Fixing usability issues
- Adding the ability to track the actions performed by users through WP Toolkit
- Improving performance of WordPress blogs
- Performing automatic snapshot of WordPress installations before upgrading them in case something goes wrong
- …and many other features and improvements.
If you have feedback on WP Toolkit or ideas on how to improve it, making it more useful to you and your clients, let us know in comments.
Special thanks to Jay Versluis from WPHosting and Eric Amundson from IvyCat Web Services for helping us shape WP Toolkit the way it is – thank you, guys!