Managing Access to Plugins (So Clients Don’t Break Their Site!)
When building WordPress sites for clients we often rely on plugins to provide the core functionality of our product.
The trouble is, if a client inadvertently deactivates a plugin, it could break the site, or at the very least severely impair its functionality.
In this article I’ll share some tips and tricks you can use to make sure clients don’t disable their own websites by mistake.
While our goal should always be to achieve an air-tight seal, communication should always be on the forefront of our efforts. Developers tend to blame clients for everything – sometimes rightly so, and sometimes not so much.
One of the most essential tools in our toolkit is documentation. If a plugin shouldn’t be disabled then write this down somewhere and share it with the client. Group this together with other tips, tricks and how-tos and boom, you have helpful documentation your client will no doubt appreciate.
You should also make an effort to communicate in person or on Skype. If there is an element in your project, which could potentially break everything, perhaps it is a good idea to let the client know and stress just how important it is not to disable plugin X.
At this stage, the client should be aware of any issues with a specific plugin. However, things may be forgotten over time, the client may employ other people or maybe just mis-click. That’s where access restriction comes in.
The easiest way to do this is to simply prevent the link to remove a plugin from appearing. This is a fairly simple matter, we can use the
plugin_action_links hook, iterating through each of our plugins, and disabling the link for particular ones.
If you’ve been reading up on safety you may ask: Is this safe? What if the user knows the link and visits it in lieu of clicking on the link?
This is not really our concern here. The fact that we’re disabling the links doesn’t mean WordPress’ permissions system is compromised. Only admins can disable plugins.
If your client – as an admin – logs in and intentionally disables the plugin by visiting the specific link he/she probably knows what he/she is doing.
There is a small downside to this method. The actions are disabled for all admins, even for us. If this is an issue for you, you can create a custom role which is “above” the administrator.
Creating an Admin Overlord
There is such a thing as a Superadmin, but this is an actual role used in a Multisite installation so it’s best to avoid any conflicts. What we’ll do is create a role named Overlord who will be able to do anything that admins can and then some. Here’s how:
There really is no need to create our custom role every time the page loads so I’ve added it to an activation hook. This only runs when the theme is activated. If your theme is already activated just run the code within the hook once by temporarily adding it to the init hook.
We create a role named “Overlord” and copy all the capabilities admins have. A new capability named “can_overlord” is added, which we can check against when needed.
We can now modify our previous code by adding the capability check. This will disable the action links for everyone but overlords. Don’t forget to make yourself a Superadmin to see the links!
I like to build in a final safeguard – a check for required plugins. This is beneficial because it lets clients know what is going on if the plugin is disabled and it also informs you of what it is the site relies on (don’t forget that you may come back months/years later).
I like to use The TGM plugin activation class for this because it allows me to provide required and suggested plugins and configure the messages users receive. I’ve written about TGM Plugin Activation before, take a look there for more information. Here’s a nice example, which I’ll explain below:
You need to include the class itself and then configure it. This is a matter of telling it which plugins you require and customizing the message strings.
Plugins can be specified right from the repository, from an external source or can be self-contained within your theme, take a look at the documentation for examples.
By customizing the strings you can provide friendly messages to clients which tell them what is going on, who they can contact and – more importantly – how they can resolve the issue themselves.
By default, the class lets users know exactly which plugins have been deactivated. I opted to go for a more direct approach with this string:
Some plugins have been deactivated which are needed for your website to function. Please re-activate or install the required plugins using the link below. If you are unable to do so please contact [email protected] as soon as possible.
I am strongly against doing this, but disabling the whole plugins section is also an option.
Similarly to our link disabling efforts, users could still access the page directly, even if the user interface is removed.
Feel free to wrap this in a check for the ‘can_overlord’ capability to make sure the menu is visible to Overlords.
As an additional safeguard you could also remove the ability to edit themes and plugins. This is something I am a fan of because this is also good security practice. You’ll need to add the following to the wo-config.php file.
Removing the ability to muck up your site by removing plugins – but retaining updating abilities – is not only possible, but downright easy.
This removes unnecessary communication and ambiguity from your client work and can provide your client with easy DIY options – a better experience all round.
Have you had any disastrous situations where clients have added or removed plugins, or updated settings? Let us know in the comments below.