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!
with
30 Comments
Hi Guys, keep up the good work – this is something WordPress definitely needed. One suggestion would be to add support for fail2ban WordPress plugin as now that plesk ships with fail2ban why not secure WordPress with it as well? Currently we offer support but we need to nag customers to install and enable the plugin, if it where shipped and enabled by default that would be great.
Also on your script which obfuscates the version info displayed in templates, you append the code to the end of functions.php, but if the is a close tag your line ends up after that so the net result is the like of code appears in top left of the live website. Just need to add your code before the close tag at end of file if one exists.
I’ve created a Fail2Ban Jail and Filter to catch failed WP logins — and so far it works well. This means there’s no need for users to install a plugin, just add the Jail in Plesk and you’re good to go. Let me know if you would like me to post details.
Hi Gavin,
This sounds like a good idea, thanks for sharing! We are strongly considering implementing this in the next version of Plesk. Can you provide details of your particular arrangement?
Here’s a gist of my wp-login Fail2Ban Jail and Filter:
https://gist.github.com/gbot/3e10ef0655d191436907
I should note that this method could be a bit CPU intensive, as Fail2Ban is monitoring a lot of log files. A less intensive method is described at the following link, but requires modifying the active theme’s functions.php file (or installing a plugin) to write to the error log on WP login failures.
http://blog.somsip.com/2012/02/using-fail2ban-to-protect-wordpress/
Hope that helps.
This definitely helps — thank you very much, Gavin!
Hi Chris,
Thanks for reporting the bug — we’re investigating it at the moment.
We’ve thought about adding the ability to install a number of preselected plugins. The problem is that every WordPress hoster has different plugins in mind when it comes to actually selecting them, so we’ve decided to postpone this functionality for a time being.
However, as Gavin has helpfully mentioned in the comments, creating a Fail2Ban Jail and Filter to catch failed WP login attempts seems to be a great alternative that we consider implementing in the future releases.
Hi,
Is it possible for Plesk admins to access the plesk-wp-cli directly to run commands via the shell and / or shell scripts?
I’ve had a look in /usr/share/plesk-wp-cli/ but I can’t figure out what we should execute to run wp-cli.
WP-CLI docs state: php wp-cli.phar –info, but this doesn’t work with plesk-wp-cli.
Is this possible?
The Plesk WP Toolkit is awesome – thanks!
Hi Gavin,
We do not support accessing wp-cli shipped with Plesk directly, since it might break functioning of WordPress Toolkit. However, we do have CLI tools for managing WordPress instances:
http://download1.parallels.com/Plesk/PP12/12.0/Doc/en-US/online/plesk-unix-cli/73581.htm
We also have the means of managing WP instances via API:
http://download1.parallels.com/Plesk/PP12/12.0/Doc/en-US/online/plesk-api-rpc/73591.htm
If this doesn’t help, tell me what is the scenario you’re trying to perform, and I’ll see how we can help you out. Thanks for your feedback!
Thanks for the explanation.
I’ve looked at wp-instance, but it’s quite limited in what it provides, compared to full wp-cli.
My immediate task is that I need to add some custom code (define(‘WP_POST_REVISIONS’,0 )) to all WP site’s wp-config.php. wp-cli supports this via ‘core config’ (http://wp-cli.org/commands/core/config/).
I could do this without wp-cli by just searching through /var/www/vhosts/… for wp-config.php files and injecting the code, but using wp-cli seems like a “safer” way to do it. It would need to work for all WP installs; those installed via APS and manual installs.
So, I’m looking to write a bash script to:
1. get all WP installs (wp-instance –get-list)
2. somehow parse this list and get all WP install dirs (no idea how to do this yet)
3. loop through and run ‘wp core config –extra-php …’ to insert the PHP into wp-config.php
I can think of all sorts of other useful things I’d like to do with WP-CLI, such as installing some mu-plugins on all installations. I need to figure out how to parse the list of WP installs, and then loop through, installing plugins.
Thanks for your consideration of these matters.
Well, that explains a lot. If you really need to access all wp-cli functions and you don’t want to install it by yourself on all servers, you can call this utility (it’s our patched version of wp-cli):
usr/share/plesk-wp-cli/bin/wp
Please note that you’re using it at your own risk, as we have no idea what problems this could create.
One more thing: we’re thinking about exposing all wp-cli functionality (for example, in our wp-instance utility), so there’s a chance that you won’t have to take risks accessing wp-cli directly. Thanks for sharing your case with us, Gavin — please let us know if there are other WordPress-related improvements you can think of.
Hi,
I often use WP sitenetwork feature, it needs some additional lines in wp-config.php file. It looks like it’s not supported by your toolkit, ie. after a site migration (using migration tool) the wp-config lines are removed. It also happened with last update.
Additional to that to use several domain names and SSL certificates for several sites in the site-network we need to setup new subscription and customize vhost.conf to overwrite DocumentRoot and SuexecUserGroup to the main subrscription (also the wp install).
Is there a chance that WP site network and domain mapping will be supported in the future ?
Hi Sylvio,
Thanks for reporting this bug about WP multi-site installations being broken after upgrade/migration. We have identified and fixed the bug in one of our WordPress APS package updates. The fix required extensive rewriting of our upgrade scripts, that’s why it took so long. Let me know if you are still experiencing the issue.
Thank you for sharing the information about domain mapping issues as well, Sylvio. We’re looking into that, as this issue might be quite complex to fix. If you have more details on this (how you expect Plesk to behave in this case, what would be your best user experience, etc), I would appreciate if you could share them.
It would be *really* useful if
plesk bin wp_instance –get-list
could return the full local path to each WP installation, currently it only lists the ID, URL and OWNER.
+1
I assume you want to see the full local path pwd-style (for example, /var/www/vhosts/mymegablogdomain.com/httpdocs/wordpress_instance)? I’ve filed your request in our internal system. Its tracking number, for your reference, is PPP-13906.
Thanks for the suggestion, we’ve missed this one initially. Let me know if you have other feedback or suggestions on WP Toolkit, we really appreciate your input, Gavin!
Hi,
It looks like we can use the wp_instance utility and XML API to install WordPress plugins that are available on WordPress repository, hence the need for plugin-id, but how we can use them to install commercial WordPress plugins that aren’t available on the repository?
I cannot fine something like this: ./wp_instance –install-plugin mycms
If my assumption is correct and we cannot use the WP toolkit cli or API to install commercial WP plugins, is there any other tool shipped with Plesk that would allow us to do so?
For some reason the blog automatically ripped off some input..
“I cannot fine something like this: ./wp_instance –install-plugin mycms plugin-zip-file-location”
Hi Hossam,
This functionality isn’t available in our wp_instance utility, since it’s not available in WP Toolkit UI itself. It is, however, available in wp-cli itself. You can try accessing this wp-cli function by calling the following utility (it’s our patched version of wp-cli):
usr/share/plesk-wp-cli/bin/wp
Please note that you’re using it at your own risk, as we have no idea what problems this could create.
The command you need is wp plugin install (see http://wp-cli.org/commands/plugin/install/ for more info).
We would like to use the toolkit to
1) create users (a specific user for each hosting account that has wordpress)
2) change some roles
It would be great if the toolkit could be used to run wp-cli with the correct hosting account credentials.
@Hossam and @Andrey,
The current WordPress Toolkit (WPT) does not allow for uploading custom plugins and themes.
However, when uploading a custom plugin/theme via WordPress admin panel or FTP, one can make WPT aware of that custom plugin/theme by running:
./wp_instance –clear-cache
Afterwards, the custom plugin/theme will be visible in WPT, under Server Management, when clicking on the tab “Plugins” (custom plugins can be deactivated/activated normally) or the tab “Themes”.
Hope this small tip helps.
Kind regards….
How come i cant login in the blog site i created with 1 click installer in plesk application menu.
What actually happens when you click “Switch On Auto updates” for a WordPress installation? I would have expected to see a new link the the wp-config.php file like:
define( ‘WP_AUTO_UPDATE_CORE’, true );
or
the line: define( ‘AUTOMATIC_UPDATER_DISABLED’, true ); to be removed or the constant set to “false”
but I my wp-config.php file does not seem to change when I turn on auto updates.
What tells WordPress or the server to update?
If something is set in WP Cron are the WP_AUTO_UPDATE_CORE & AUTOMATIC_UPDATER_DISABLED ignored?
Thanks for the info.
hi! i have one domain name and hosting. i logged in plesk (web host edition).
I follow the instruction to install wordpress but my site is down 🙁 ..
I don’t understand what i have wrong.. I haven’t used this platform again and I’m confused …
Please some advice!!! Thank you!!
Plesk Onyx
Version 17.0.17 Update #12
CentOS 6.8 (Final)
WordPress 4.71
Multisite:
Plesk WordPress manager shows all WordPress plugins as inactive, but they are of course active and working.
Is this a known issue?
Hello there.
Is it possible to change the default installation behaviour of WordPress and add some options before the installation Process, e.g., a predefined theme, plugin or post?
Thank you and Best Regards
Fernando
Hello Team,
Can you add one click performance options like HTTP/2, Varnish, Nginx Reverse proxy and Memcached so that wordpress site loading speed will be best.
Hello Shrikant,
we’re already analyzing possible implementations of Varnish or Memcached. Additionally, I will release some articles about how to integrate these server-side caching mechanisms easily in Plesk Onyx soon.
Hi all,
I noticed that under /.wp-cli/cache/ there are a lot of zip files with older versions of WP and plugins and they keep on growing. They also get into the backups by default.
Can one safely get rid of them? how to avoid them piling up?
Franco
Hi there,
I was wondering if there is a way to initiate cloning of a website via WP-ClI?
We want to setup a base WP website/theme and then be able to trigger a clone and give it a subdomain name from within WP admin.
Is this possible in any way?
Thanks
G
You can use the WordPress Toolkit CLI for cloning websites. The command is
plesk ext wp-toolkit --clone.