Don’t Update Your WordPress Website

Not Really

The title of this post is designed to grab your attention and make the following points. Please do not tell folks, Shane, at FatLab told you to never update your WordPress site, it won’t make either of us look good 😉

I recently started working for a new client and task #1 was to reinstate their site, which had been down, within a new web hosting account. The reason it was down was that it had fallen victim to a malware attack. The site had been cleaned up by and it was ready to be redeployed.

Though cleaned of the attack, one of the first things I noticed was how out of date the WordPress core was and just about every plugin was a few versions behind. The client was by no means oblivious to this fact and they requested one of the first things I do is to look into bringing the site up to date. Here is where the catch was given…

The original developer had warned them not to update the site because it ‘might break something’.

Sadly, this is not the first time I have heard of a developer telling a client not to update their site. When I hear this I immediately figure one of the following scenarios is in play (in order of worse to slightly better):

1) The developer ‘hacked’ core

Simply put they modified the core files within WordPress and these changes will be wiped out when the update is applied. Customizing WordPress is a great way to scale it to your particular needs, however, there are ways and best practices to customizing it so that updates will not affect such customizations in the future.

Depending on how much the core has been ‘hacked’, this can lead to a very ugly, risky, and potentially expensive proposition for the site owner. Do they not update their site, leaving it vulnerable as it becomes more and more out of date, or do they risk losing their customizations, or are they put into the situation to pay (again) for a developer to recreate those customizations outside the core?

2) The developer did not use a child theme

When modifying a commercial theme there is a technique called a ‘child theme’ that basically allows a developer/designer to make modifications to a theme without affecting the main theme files. This is a best practice as it protects against losing all customization upon updating the parent theme.

If a developer makes customizations within the main theme files without first creating a child theme, then it basically makes it so that theme cannot be updated. I consider this a ‘rookie mistake’, found mostly in sites built by a less experienced developer. We all have to learn, right?

3) The developer modified a plugin

This is a lesser evil and more common. As long as any modifications to a plugin are evaluated and there are no potential security issues to not updating a plugin, it is simply important that it be documented so any other site administrator knows not to update the plugin.

There are also functions a developer can add to hide pending updates for a modified plugin so functionality and customizations are not accidentally lost with an update.

4) The developer doesn’t want a call when the client accidentally ‘breaks’ the site.

Most WordPress core, theme, and plugin updates go off without a hitch. However, there is always a chance that a change made to the core, a plugin, or a theme will not be compatible with something in your site and/or your server environment. It’s totally reasonable for a developer to warn a non-technical client not to make updates as long as they or someone else is managing the site and regularly running through pending updates. The key here is that if you are told not to update your WordPress website, ask who will.

One of the greets attributes of using a platform like WordPress is that it has a very active community and when a security threat is identified it is usually quickly patched. However, by not updating your site you are not taking advantage of this, leaving your site more and more vulnerable as time goes by.

Don’t Accept it!

Do not accept a WordPress website that the developer warned you to never update and doesn’t provide you with an alternate update policy/plan. Quite simply, it means it was not built right.