“Golden Gate Bridge Approach” – Wibble’s take on WordPress management

In a previous post about Our partnership with Abacus Talent Group, I spoke about the principle that we adhere to within Wibble on managing the multitude of WordPress sites, that we refer to as the “Golden Gate Bridge Approach”.

The maintenance procedure for the Golden Gate Bridge is a robust and thorough one; simply put, the team of painters carry out a never-ending run of constant repair and maintenance to ensure the bridge is safe and secure for the 110,000 people that cross the bridge daily.

We would identify with this approach in the same way we look after the WordPress sites on the managed WordPress service that we offer. We carry out constant updates, patches, monitoring and fixes – all fully managed by our team of experts.

In much the same way, our Wibblers are constantly fighting against dangers out there in the real world – only in our case it isn’t rust and corrosion but bots and vulnerabilities that could cause untold damage to the sites that we manage if left to their devices.

Our fully managed WordPress hosting is a service that simply takes care of all the issues that may affect a WordPress powered site, but with our own proactive approach.

How we manage our sites

Every website that we design and develop ourselves or migrate to us on our Wibble Rescue Package is placed on a Wibble Support Package – this is where Wibble takes care of everything to ensure your website is safe, secure and online. What we cover is WordPress core updates, plugin updates, theme updates along with server management and hundreds of security precautions at a DNS level.

WordPress core updates

We take care of all WordPress core updates, irrespective of how frequent or rare they occur. They are our responsibility and they form a key part of Wibble’s security policy. Keeping WordPress up to date is, in my opinion, the single most important thing we can do to stop vulnerabilities and prevent issues arising within your website set up.

Through years of refining and tweaking our policy for updates we have come up with a rule that all Wibblers adhere to: If core updates are not critical, security updates we may not update for a little while to ensure bugs and issues have been patched. This has proven the most stable and non-intrusive approach to how we manage core updates.

WordPress plugin updates

This is the most troublesome part of the update process that we follow. We are relying on the developers of all the plugins that are installed on our sites to be tested and ready for the update to the latest version – this isn’t always the case but we have a robust system for rolling back a site should an issue occur. We tend to carry out these updates at the same time as the core updates.

WordPress theme updates

This is, generally, the easiest part of the process. Sites that we manage as part of the Wibble Support Package tend to either be sites we’ve developed ourselves or premium themes from third-party developers. With our own themes, we are very confident in the updating of them or are prepared to review and fix instantly. With premium themes, we are relying on the developers to ensure their codebase is tested and stable but we generally find no issues with updating WordPress themes.

Automated vulnerability scanning

We tend to allow major plugin and core updates time to settle before we update them but the only time this is not adhered to is when we are alerted to a vulnerability within any site that we manage. Our security set up has a huge level of automation built-in, by default. Each site is scanned every 24 hours to check for core, theme or plugin vulnerabilities against a global vulnerability database. When our team are alerted to any vulnerabilities within our setup we fix, test and monitor without delay.

Manual checking of updates – by a human

This is a huge and vitally important part of our process. We don’t just remotely push updates to your WordPress site and walk away. Our support agents manually check the major sections of your website to ensure that they do not appear to be negatively affected by updates. We then use our notification system to let you know that we have pushed updates to your site. It gives you the opportunity to check it yourself and stay informed that Wibble is managing and caring for your WordPress site.

Uptime monitoring

This feature is key – if something goes wrong and a site goes offline, we need to know ASAP. Our automated system checks every site with a small “PING” – simply a little test saying hello to the website and an active and live site will say hello back. If we don’t get a hello back we ping again and continue to do so more frequently. If a number of pings fail in a row, our support team is notified immediately. It’s a nice safety net for all our sites that comes as default.

Automatic, off site backups

All of the above are great features but are pointless if a critical and catastrophic failure should occur. We host our sites on hugely reliable and stable infrastructure but we have to take steps to prepare if something was to go wrong. Many systems run backups but store them on the server that the site is on – should the server become completely unresponsive or corrupted, this is no use. Our system automatically backs up onto a completely separate and remote server that is not in the same data centre or even with the same hosting provider to protect the integrity of the backups should they ever be needed.

We also, regularly test backups and use these to create local versions of the sites for testing and development. Having backups is great but what if they weren’t working or useable? Or would the Wibblers know how to quickly and efficiently locate, clone and launch a backup if needed? These are all key things we carry out regularly in preparation for such a scenario.

Why we use this approach

Through years of testing and tweaking, we have found that constant, small updates are much more stable and manageable than leaving it months, or longer, between updates. An approach that sees site updates only being considered when development work is needed, is prime for vulnerability exploitation.