We see it all the time.  We or our clients install a content management system plugin to extend the functionality of their CMS…whether it’s WordPress, Drupal, Joomla or some other platform.  The plugin does something fantastic, makes the website better and then, once day…fails…wreaking havoc on the blog or corporate website.  Sometimes something small breaks like a photo gallery or signup form and other times the entire website stops working.  And, of course, there’s always our favorite, when things go so wrong, the hosting provider simply shuts down the website.

Such was the case just this week when a very popular plugin caused so much trouble on the hosting provider’s server that they shut the entire site down until things got sorted out.  Here’s what happened (without getting overly technical), the plugin initiated automatic communications with the server for administrative purposes.  A glitch in the code caused those communications to happen way more frequently than necessary, which resulted in overloaded processes on the server.  In some cases this caused the server to respond slowly and in others the server stopped responding.  From one point of view, the plugin caused an unintentional “denial of service” attack on the website.  Dear clients, you may proceed to panic.

So what now?  Your website is in trouble and solutions seem hard to come by.  OK, if you’ve still got access to your CMS, we’d suggest disabling the content management system plugin that’s causing the problem.  Does the problem go away?  Good.  Move on to looking if there is an updated version of the plugin that solves the problem.  Sometimes it is the updated plugin that caused the plugin, if that’s true, see if you can roll back to a previous, stable version…or wait for the developer to fix the updated version.

But what if you can’t access your CMS admin panel?  Hold on doom and gloom…there’s still an answer for you.  Most popular Content Management Systems use PHP and MySQL for their functionality.  If you’ve got access to hour hosting control panel, then you can start digging into MySQL to disable the content management system plugin at the database level.  Each CMS database is configured differently but by way of example, WordPress keeps its plugin information in the wp_options table in an entry called active_plugins.  Removing reference to the plugin in the table will disable it in the CMS and things should start to behave more normally.

We should probably note that working in MySQL takes some guts (and experience) and is more often than not best left to the professionals.  Also, any time you make changes to a database, it’s always a very good idea to make a backup first…consider it your get-out-of-jail card if things go south fast.

Once things are back on track, it’s probably time to take a good look at the plugins you use.  Are they actively developed?  Do the developers respond quickly when things go wrong?  Are others reporting problems with their content management system plugin list?  Plugins are awesome, but like many things in technology, have the potential to torque steer off road right into a milk truck.  Do your research and implement prudently.