34SP.com Blog

Why do plugins break my site?

We regularly get queries along the following lines:

“Thanks for sorting out my website today! Still struggling to understand how plugins can destroy a site. If you have any advice…?”

So what’s the deal with plugins?

WordPress is amazingly versatile and extendable. The way WordPress extends is through plugins and to a lesser extent themes. These give you the ability to transform your WordPress site from a simple blog into an e-commerce site, an events calendar or pretty much whatever you can imagine.

A plugin is a bunch of code normally written in PHP and some JavaScript.  This code hooks into WordPress using a series of actions and filters. This means that a plugin can interact with lots of different parts of WordPress and affect the user experience along the way.

Code is developed by people and within the WordPress community we have a wide range of talents from all walks of life. The plugin you are using is as likely to been developed by a vicar as it is a full time professional software developer. That’s part of what makes WordPress so great, as almost anyone with basic coding experience can build a plugin.

Unfortunately building a plugin that is needed and valuable is not the same as building a plugin that performs well and is error free.

 

So why do plugins break your site?

Simply put, because most of them have bugs. I would go out on a limb and say virtually every plugin, like every piece of software including WordPress itself has some sort of bug. From the mars rover to a Boeing 747, if it has a computer with software there is a good chance it has a bug. The good news is most of these quirks don’t cause too much harm, they simply cause an unexpected result. Other software or human interaction tends to work around these bugs and they get fixed in software updates.

 

How do these bugs manifest themselves?

Well that’s the fun of bugs! There are myriad ways they can manifest themselves but the scariest when it comes to hosting and WordPress is the so-called “white screen of death”. This is where the page appears not to have loaded and instead just a white screen appears. Behind the scenes what has happened is that the plugin or something else has triggered a PHP fatal error. The word fatal gives it away, but this is bad, as it means the whole script couldn’t execute and give any output, leaving the dreaded blank white screen. In some instances you might also see an error message as some servers are configured to show error messages to the screen whilst others record them in log files on the server.

Either way the site won’t load and you are left with nothing working.

The problem is that it’s very easy to cause a fatal error, either by making a mistake in the plugin’s code or where there is a conflict with another plugin. For example:

if($test){
echo 'test';
}

won’t cause an error but this will:

if($test){
echo 'test'
}

Can you spot the issue?

Hopefully after some squinting you spotted the missing semi-colon. Now imagine trying to do that for thousands of lines of codes. Thankfully there are tools that can help identify these sorts of errors but you will be amazed how many people don’t use them or even know of their existence.

The above error would trigger every single time the plugin was used, so hopefully a developer would spot it before they released it to the public, but they may not have tested it, or made a last second change and as such the white screen of death may occur.

Another similar issue might be where two functions or classes are named the same for example:

my_amazing_function()
{
//it's amazing
}

and

my_amazing_function()
{
//it's not amazing
}

If both functions were called by different plugins, PHP wouldn’t know which function to use and so would give a fatal error. When someone says there is a clash of plugins, what they normally mean is that there are identically named functions or classes causing errors.

This type of fatal error is much harder for developers to solve, as they have no idea how other plugins are named. There are solutions built into PHP, but again many developers are not aware or choose not to use them.

A separate issue that can crop up is where a plugin modifies the output or input of a WordPress function via filters or actions to suit its needs and another plugin is expecting the output to match the original WordPress output. This can be nearly impossible to diagnose and ultimately can be responsible for a lot of the “turn off all plugins and reactivate one at a time” type answers you will hear. To make things worse, the order in which plugins activate could affect the output, so simply disabling and re-enabling plugins might fix the issue.

As a WordPress hosting company one of the problems we see regularly is where a developer has used a module for PHP or a command in PHP which is not supported on our hosting. Developers tend to work on their own local machine and may accidentally use code that only works in their particular setup. Often they assume if it worked for them it works for everyone and sadly that’s not always the case.

Sometimes we as a hosting company can provide a way to run with the special component the plugin needs, but other times it wouldn’t be appropriate (they are using something too old or insecure) for us to enable it. You can imagine this causes everyone frustration. It’s worth remembering at such times that it is most likely the plugin that is doing something unusual and that the vast majority of plugins do run fine on our WordPress hosting platform.

Fatal errors are frustrating, but not the end of the world.  If a plugin causes a fatal error then you most likely want to turn it off if you can you can do so by going to the WordPress admin area, plugins and clicking on deactivate. However in some cases the fatal error will affect the admin area. In such cases you will need to use an FTP/SFTP client like Cyberduck to access the files on your server, navigate to the plugins folder and rename (right click on the folder, select rename) the folder containing the offending plugin. If you refresh the WordPress admin page you should see that the fatal error is gone.

With your site back up, check to see if there is an update to WordPress or to the plugin available before reporting the issue to the plugin developer.

 

What if you don’t know which plugin caused the issue?

You could turn all the plugins off and re-enable one by one, however depending on how many plugins you have that could take a very long time so it’s worth looking at your error logs.

Most hosts give you access to error logs, for 34SP.com customers they are in the statistics/logs folder. Error logs look frightening but really they are just a dump of issues your site is having and you don’t need to know anything about coding to look at them. Each log has a time when the entry was made, and what triggered the entry.

This looks something like:

[16-May-2016 13:33:51 UTC] PHP Fatal error:  Call to undefined function blahblah() in /var/www/vhosts/example.co.uk/httpdocs/wp-content/plugins/example-plugin/example-plugin.php on line 2

In this case it would appear the example-plugin plugin caused this error, so we can go and disable that plugin.

It may well be that there is no plugin name there, just calls to WordPress include files. This doesn’t mean a plugin is not the issue just that it’s not what is reporting the issue, so unfortunately turning off all the plugins and enabling them one by one is the way to go.

So that covers fatal errors and white screen of death, but what about when the server just stops and hangs, how is a plugin to blame for that?

 

Hanging or timing out sites

Computers and servers make use of RAM to store things in memory. When code is run, the output is stored in memory but it also stores the calculations and all the steps in between. When finished it’s meant to give up that memory for other processes to run.

Most PHP processes take microseconds to complete, even really complicated tasks will normally complete in a matter of seconds. This means that even if lots of people visit your site, each process running to get them their post is taking fraction of second to run before releasing the memory and to a lesser extent CPU usage. However if a process takes longer to run then it’s holding on to memory as a more visitors arrive, the amount of allocated memory maximum is reached and processes start hanging, not having enough memory to complete their tasks or worse just enough to try but very slowly. This scenario slows down your site and possibly other sites.

This issue is a frustrating one for client and host alike.  The quick answer is to increase the resources available to the client.  Often, however, the additional memory will just be consumed.

The problem is that tracking down the plugin causing the issue is hard and to make matters worse there are plenty of other factors that could be causing this such as an abnormal traffic spike, so it might not be a plugin at all!

 

How do I know if a plugin is causing high load?

There is no fool proof way without going into some in depth systems administration to find a plugin’s load.  How much resources a plugin uses will vary from site visitor to site visitor and how it interacts with other plugins. It may be the load is only increased when a cron job is running for example or when a visitor does things in a certain order.

That said, there are tools that can help.  For example P3 Profiler is a plugin that will give a break down of resource usage by plugin. It’s not entirely accurate and if you run it multiple times you will get varying results but it will give you a good guide as to which plugins might be causing issues.

If you use the profiler, don’t forget to turn it off and remove it when you are done as it also uses resources and slows your site down, exacerbating any issues you might have.

While it’s hard to quantify, as you start to regularly use plugins you do get a feel for which plugins will be the misbehaving ones.  There are always exceptions but things that trigger alarm bells are large plugins with lots of features, ones with admin pages that don’t match WordPress or use lots of boxes across your admin area.

 

Caching your way out of things

If your site is slowing down, one possible solution is to use caching as a way to speed up the site.  This works by storing a version of a page or part of a page in memory or as a file on disk. Caching reduces the amount of work WordPress needs to get through, meaning plugins are not called as regularly and as a result the load on the site goes down. Caching is pretty vital for medium to large sites but all sites can benefit. There are many plugins available to help with caching, some of the popular ones include w3TotalCache and SuperCache as well as commercial offerings such as WPRocket.

Your hosting company may also offer caching as part of their hosting package. For example our WordPress Hosting package has 2 forms of caching already in place to help keep your site speedy.

Caching doesn’t fix the problem of resources all together but it helps balance and partly mitigate some badly behaving or resource intensive plugins.

 

So plugins are all bad?

Not at all, there are some amazing plugins out there and while a few will cause issues there is a plugin or theme for every occasion and it’s just a case of finding the right one.

When looking for a plugin, look at the reviews on WordPress.org – not just the 5 stars and 1 stars but the ones in the middle, are people saying it’s fiddly to get working?

Create a test site and load the plugin on your test site before you put it on your live site. Having a test site lets you iron the kinks out before use on your live site.

Ask yourself if you need all the features? Some plugins are really big, because they include everything and the kitchen sink. Do you need all the features, can they be turned off? Is it better to have 2 plugins that just have the features you want, rather than 1 big plugin that has dozens you don’t?

A common myth is you can have too many plugins.  The truth is there is no upper limit to the number of plugins you can have other then the amount of diskspace and resources you have available. You can have 100 plugins activated on most hosting plans with no issues. But, and it’s a big but, you can only have 100 low resource plugins activated; a single bad apple can consume all the resources and cause problems. So when it comes to plugins it’s not the quantity that is an issue, it’s the quality.

There will be times where you need to run a plugin that may be a resource hog, and it may need to be a resource hog to do it’s job. For example a lot of security plugins use up resources as they intercept and inspect everything coming to your site. This is perhaps the most frustrating aspect of plugins, ultimately it may be the case that to run the plugin you want to run, you simply do have to increase the resources allocated to your site.

We have covered a lot in this post, looking at what causes the white screen of death and why sites can slow down to a halt. We’ve looked at some of the ways we can profile plugins to find ones causing high loads as well as some advice on picking plugins.

Hopefully the next white screen of death you come across will be easy to fix but don’t forget your hosting company are always there to help, be it helping you to make sense of log files or recommending alternative plugins or services.

For fully tailored and optimised hosting, why not consider our WordPress Hosting? We provide a fast, secure environment where we have taken care of the security and performance side of things for you, so you don’t need to worry about adding security plugins which might increase resources or caching plugins to try to balance things.