Issues with using a CMS

If you have a website, the chances are it runs on a CMS (Content Management System).  There are hundreds of them out there, some you will have heard of; Wordpress is the obvious one.  Others include Drupal, Joomla, and Umbraco.  These are great for the most part, as they require very little in the way of development knowledge.  Want a feature or some particular functionality? Get a plugin for it.  Want a different theme? Get one and install it.  They make things really easy.

There is one issue with them, however.  Updates.

Keeping systems up-to-date is great.  I highly recommend it, and advocate it for the best possible security.  But when you have more than a small handful of plugins (some sites can easily get into double-figures of them, and hit several tens of plugins).  This can make updating both difficult, and a full-time job.

With security issues and feature updates being found and added daily, there's often at least one plugin which requires an update.  If it's not the plugins, then there's the theme which may need updating, or even the core CMS platform.  What do you do, though, if one of the plugins isn't compatible with another following an update, or if updating the core CMS causes things to break with plugins you have?

This isn't scaremongering, it's a reality.  These are all things which you need to consider when picking a platform for your website, as it's your window to the outside world, and how the world views you.

Fortunately, there's some things you can do to reduce the issues.  Firstly, and most importantly, have a separate environment dedicated to testing.  This should be on a completely separate server (virtual or otherwise) so any changes which need making don't break the live website.  If you don't think there's a risk in having them on the same server, consider this: if your website is running on Linux and you have a kernel update you need to apply which needs a server restart (they usually do), how do you check that only in test?  Also, most of the CMS systems I listed, and the most popular ones available, run on PHP.  How do you test them easily on a different version of PHP, or update a PHP module, or add a new one to try, without applying it to the live website at the same time?  Some things will only need the web server restarting - that's still down-time needed, however small.  And if you get the configuration wrong ahead of the restart, it could be down longer than you think.

Don't have your live and test environments separated?  Go and do it now!  This article will still be here when you get that sorted.  Oh, and make it identical to your production environment where possible!

Once you have the different test and production environments set up, the next thing on your list should be to conduct an audit of each of the plugins which are installed.  This should include the functionality they are used for, and where they are used.  You should be able to establish if there are some which are installed and no longer used.  If this is the case, remove them (first in the test environment, then in live once it's proven to be safe to remove).  The chances are that if a plugin is not used (be it disabled or active but not actually used), then it will be missed or skipped when updates are applied.  This is a surefire way to leave security holes in your application or site.  These audits should be conducted regularly to ensure all plugins are still relevant and required.

Once you only have the plugins and extensions you need left within the CMS, it is then time to apply the updates.  Again, this should be one at a time in the test environment to ensure compatibility, and then again in the live environment.  It's always tempting to press the "update all" button and be done with it, but if something did go wrong it could be a significant undertaking to the root cause of the issue, and fix it.  This, in turn, could lead to extended periods of down-time, which isn't good for anyone.

Finally, once everything is audited, updated, and working as it was before, it's time to keep on top of those updates.  Ideally this would be checked daily, and plugins updated as soon as possible.  But this isn't always practical.  Weekly is more realistic so it's not taking up someone's day every day.  Worst case, do it monthly.  Any longer than that and things become risky.

Some updates will take longer than others, and some might not even be possible due to them being unsupported by an update in the core CMS (such as going from Wordpress 4 to 5, or Magento 1.9 to 2.1).  When this happens, it's time to reconsider the functionality and hunt for a new plugin to do the same thing.  This may require paying for some functionality within a premium plugin, or removing functionality from your application.  Either way, there's still more testing to be done to either remove altogether or change to something different.

There is an alternative to all of this.  A custom build.  It's not always perfect, but you can get the features and functionality you want built in, and work through iterations until it's right.  Need something new? Ask your developers (internal or external).  Same if something isn't quite right.  If a plugin for a common CMS system doesn't work how you would like, or the functionality changes as part of an update, you're out of luck.  With a custom solution you can have what you want - anything is possible with sufficient time and resources.

Show Comments