WordPress plugins – the good, the bad and the ugly

Table of Contents

Ancient Geekery Wordpress Plugins

Synopsis

There are, as I write, just over 55,000 plugins available in the WordPress repository and the news is, you don’t have to use all of them! This article explains how to go on a plugin diet and the risks to health if you don’t …

This article is designed for new and casual users of WordPress and talks about the issues that can arise through ‘plugin bloatware’ and the effects it can have on your website and server.

Ok, so, you’ve just got a fresh WordPress install and you go to take a look at your new, shiny website and well, it’s all a bit uninspiring so you load a new theme and things start to look a little more like a website and you start building-out some content but it’s not long before you realise you need to add a bit more functionality and that’s when you start loading plugins.  Generally speaking a plugin adds some functionality or other – perhaps providing and styling social media icons or something to add a fancy menu  or add more options in the way of widgets. By now you’re in the swing of things – need something?  Add another plugin, hey they’re free so why not?  Before you know it you can have 30+ plugins loaded and all seems to be working ok.

Now, a WordPress website is not ‘fire & forget’, you need to do maintenance and I would say daily at best and weekly at worst.  Mostly maintenance will involve updating plugins and, as a casual user you’ll be happy to know that WordPress tells you what needs updating by way of a little icon in the admin bar or notices on the plugin page itself.  You just click on ‘update all’ and the job is done. But, oops, you now visit your site and notice something’s not right; something is broken.  It might just be something not displaying as it should or it might be the dreaded “500 error” where you see nothing but a scary message on your screen.

We can deal with fixing broken WordPress sites elsewhere but this article is more about taking steps to avoid them in the first place.

Two types of plugin

In my head there are two types of plugin, those that are ‘passive’ and those that are ‘active’.  By ‘passive’ I mean they make a small tweak to the way WordPress works through a small change in the code and perhaps the database and that’s that.  An example of this would be the ‘Re-add text underline and justify’ plugin – that’s what it does and is very unlikely to cause any problems to anyone, ever.  Then, at the other end of the scale are the ‘active’ plugins like WooCommerce, Elementor Page Builder and GeoDirectory which almost take over how WordPress works and have many interdependencies.  In reality there are far more than two types – like I said, that’s just inside my head.  It’s the active plugins that are most likely to cause a problem by conflicting with some other but that doesn’t mean it’s their fault – let me explain.  

No blame game

When a developer makes a plugin for WordPress they have to adhere to what’s called the ‘WordPress Codex’, a complex set of guidelines and coding standards, if they want it to feature in the official plugin repository and every plugin there will have been reviewed and approved.  If you want to know more you can read all about it here.

Now, obviously a new plugin can’t be tested will all of the other 50,000+ plugins so a plugin is reviewed on the basis that it adheres to Codex standards.  All well and good but a plugin can still adhere to those standards and cause problems – the most common of which are naming conventions.  Let’s say I make an app that requires me to pull-in some external code snippet from a library.  I may get the option of naming that snippet anything I like so we’ll call ours ‘beaver’ and any time I need to use that snippet, perhaps to make a menu animate, I just call ‘beaver’.  Now another app developer makes an app and coincidently calls their snippet of code (script) ‘beaver’ even though it’s nothing to do with flashing menus. We may have a problem now if both snippets are called in the same post on the same page or when the site loads.  Our animated menu no longer animates but our new plugin works just fine.  We have a problem.  Remember though, we’re not here to fix, we’re here to avoid so …

WordPress Plugin Best Practice

WordPress Repository Image
A typical plugin info page. Note the tabs for further information

Best practice plugin management

These are good habits to get into which will save you much time and heartache when it comes to installing plugins.

  1. Only ever install plugs from the WordPress repository and never from some dodgy link on a forum somewhere.  The exception to this rule might be a paid plugin which is downloadable from a vendors website but, do your homework and make sure you know they’re reputable.
  2. Before you hit ‘install’ read all about it.  Every entry in the WordPress repository has details about the plugin, reviews, installation info and support info so use it!  Look at the active installations – how many people are using it?  A million or just five?  The more users, the more likely it is to be a well supported app.  Have a look at reviews – not the one star or 5 stars but I find you get more objective information from the 3 star reviews (I find that with Amazon and Trip Advisor too).
  3. Check when a plugin was last updated.  I have a habit of not installing any new plugin unless it’s been updated in the last few weeks and certainly never if it’s been over a year!
  4. Check your version of WordPress and check the version it’s been tested up to.  If it lags the current version of WordPress then that’s not good (but it may not mean there’s a problem, just that it’s not been tested and reported).
  5. Check the level of PHP required against that which your host is providing.  If it lags, don’t install it.
  6. Test plugin support.  If you’re thinking of adding a plugin that provides key functionality; for example a list manager plugin on a listing website then do test the support given first.  Just ask a simple question like “Does your plugin play nicely with xyz plugin?” and judge the quality of the response you receive and how long it takes them to respond.  You need to be comfortable they can be relied upon in a crisis.
  7.  Beware plugins that ‘do it all’.  Just add a plugin which gives you the bare minimum you require.  An example is a well respected and well supported plugin called “Sassy Social Share”.  It is massively powerful and can display pretty much any social icons anywhere you like and has literally hundreds of options. All this when you only wanted a Facebook share icon at the foot of your post!  The problem is with installing a plugin that claims to be all things to all men (and women) it comes with all the code and overheads you don’t need which can bloat your site and lead to compatibility issues.  The golden rule – keep it lean!
  8.  If your website is ‘business critical’ – that is you lose money or customers when your website is down – then you need to adopt a failsafe.  You can either make a clone of your website, if your host permits (I can do one-click cloning on my Cloudways hosting), and use the clone to test plugin updates etc. before updating or installing on your production site AND/OR make certain you have access to regular backups, which you’ve tested and trust under fire, and can be restored without hassle.  Again, with Cloudways, I have robust one-click restores.

"I recently inherited a 'broken' website on behalf of a client, something I rarely do as in my experience it's often quicker and therefore cheaper to re-create the site from scratch but with this one, it was an e-commerce site with over 600 products, it was a WordPress site with WooCommerce so I was pretty confident I could mend it. My first move was to clone the whole website from its existing server over to mine and then set about working out what was broken and why. Oh boy, 86 plugins! I then made it 87 by installing WordFence - an excellent security plugin that helps find outdated, abandoned broken and hacked files. I lost count of the errors and warning it flagged-up. As it turned out, the biggest issue was an outdated version of PHP on the old host which was fixed just by moving to my server. I then discovered the site had been seriously hacked, probably due to the fact that there were 6 abandoned plugins active, one of which had been flagged in 2016 as a security risk. They were immediate deleted. I then deleted all of the plugins that dealt with aesthetics - that was some 20 or so gone in a flash. I was then left with at least a dozen WooCommerce add-ons - 6 which offered delivery options and two offering the same delivery options and were, unsurprisingly, causing the checkout to fail. As I write, the website now has only 16 'essential' plugins running and all traces of the hackers removed using WordFence and is now working well".

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share on facebook
Share on twitter
Share on linkedin