When web hosting web hosting australia 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 original site by mistake.
Communication
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.
Access Restriction
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.
|
1 2 3 4 5 6 website hosting 7 8 |
|
view raw
restrict.php
hosted with ❤ by GitHub
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:
|
1 2 3 4 5 6 7 |
|
view raw
role.php
hosted with ❤ by GitHub
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!
|
1 2 3 4 5 6 7 8 |
|
view raw
restrict-role.php
hosted with ❤ by GitHub
Additional Safeguards
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
|
view raw
tgm.php
hosted with ❤ by GitHub
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 developer@yourwebsite.com as soon as possible.
Disabling Everything
Similarly to our link disabling efforts, users could still access the page directly, even if the user interface is removed.
|
1 2 3 4 |
|
view raw
disable-menu.php
hosted with ❤ by GitHub
Feel free to wrap this in a check for the ‘can_overlord’ capability to make sure the menu is visible to Overlords.
As website hosting 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.
|
1 |
|
view raw
wp-config.php
hosted with ❤ by GitHub
Conclusion
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.