Wordpress maintenance agreements

This question is about how to deal with ongoing WordPress site maintenance, for security. While we have some understanding of security, we are not experts and would like to know what other people think, especially if security is their area of expertise.

We make WordPress websites, usually quite small, for clients with relatively small budgets. They do not have budgets for anything other than very basic maintenance.

Where we have maintenance arrangements, in terms of security we confine ourselves to dealing with issues reported by the iThemes security and Orion ManageWP plugins. What this usually amounts to is ensuring that plugins are kept up to date.

However, when checking sites in Google Lighthouse, we have noticed that security issues are often reported that the plugins have not picked up on.

In particular, we often see Lighthouse reports saying: “Includes front-end JavaScript libraries with known security vulnerabilities”. These usually refer to old versions of jquery or GreenSock gsap, that have gone out of date since the site was initially built.

It is not in our current maintenance agreements to keep an eye on these issues or respond to them in any way. However, we would like to know more about this to decide whether we should reconsider our maintenance agreements.

Thank you in advance for any feedback.

Kind regards


1 Like

At Webarchitects we don’t develop WordPress sites or have maintenance agreements for WordPress sites, we do however host a lot of WordPress sites and we do a lot of WordPress installs and initial configuration (installing some plugins for security and performance) and also sometime update WordPress and plugins. Configuration, content and maintenance is something we generally leave to clients or clients developers.

In order to try to avoid and mitigate the problems caused when WordPress sites are compromised we:

  1. Install and activate WP-fail2ban plugin at a site and server level, this slows down the rate at which botnets can run brute force attempts on logins.
  2. Install and activate the stop XML-RPC Attacks plugin, this blocks brute forcing attempts against the XML-RPC API.
  3. Ensure that there is total isolation between user account on shared servers, PHP-FPM and SSH / SFTP are both chrooted and have no way to access the data of other users.
  4. Limit what PHP functions can be used and also limit what MySQL privileges are granted.
  5. Keep an eye on load and email queues to catch accounts when the are compromised.
  6. Keep 30 days worth of backups.
  7. Run PHP scanners to check for exploits.

Almost all the code we have written to implement everything above is written in Ansible and GPL’d and available on git.coop, for larger clients we provide managed server which use the same Ansible roles to ensure everything is secure.

I’d be interested in exploring if we can help with the security and server configuration and maintenance for any other co-ops that is involved with developing and maintaining WordPress sites — we are often asked by clients for recommendations for developers.


@Felix to add onto all @chris’s great suggestions, depending on the complexity of your site then the “Companion Auto Update” plugin (installed by default in Yunohost Wordpress sites) can make this even easier: Companion Auto Update – WordPress plugin | WordPress.org

I’m no security expert, but I’d be a bit surprised if vulnerabilities in JS libraries translated into legitimate Wordpress security problems – all the authentication / authorisation is enforced by the back-end. But again, no expert.

On the wider question, comes back to “depends on the site” – if the client is worried about security (one of our clients has been targeted by hacks before) and has the budget for it, automated Lighthouse scanning sounds like a great idea.

We do develop and maintain sites, as standard there’s a built in 1 hour per month billed for security, although in reality that time has been greatly reduced by having dedicated WP hosting.

We use 34sp.com and that includes auto-updates for plugins and scanning for vulnerable plugins, themes and scripts - they send notifications. Also a few other tools they have built, and strong security for WP sites at the server level. All of which lowers the management overhead and we’ve never had a hack on any site. It’s on Nginx so you do lose .htaccess (for adding redirects and suchlike) and some other useful things compared to Apache, but nothing that can’t be done via another method. It’s also lightning fast, provides staging sites with one-click push/pull to live, has excellent support etc. Don’t particularly love their email servers but otherwise can’t recommend them highly enough.

Also recommend using UpdraftPlus for scheduled backups, and automated backups when themes/plugins update, which can save a lot of time if new plugin versions conflict or break the theme.

3rd party plugins are not needed to automatically update WordPress plugins and themes any more (though perhaps this one adds some additional features), since WordPress 5.5 you have been able to set plugins and themes to update automatically and since WP-CLI 2.5.0 you have been able to control this using the command line via wp plugin auto-updates and wp theme auto-updates.

Assuming that the security issues are potentially serious, for example if they enable a Cross Site Scripting attack to be carried out, I’d suggest something along these lines:

  1. Raise an issue with the plugin author asking them to update the library.
  2. If 1. has no response in a week or so then:
    2.1 Check if an alternative, plugin is available.
    2.2 Consider removing the plugin.
    2.3 Consider forking and updating the plugin.