WordPress on Composer: why your site won't break at 2am

Part 1 of 5 in Secure by Design, our series on how we build, host and maintain websites that stay stable and secure.

Every business that runs on WordPress eventually hears some version of the same story: a plugin updated itself overnight, something broke, and nobody knew until a customer complained, or worse, until the site had already been down for hours.

It's such a common experience that a lot of business owners assume it's just how WordPress works. It isn't. It's how WordPress works when nobody is managing the updates deliberately.

At Vivo Group, we build and maintain WordPress sites differently. We use a tool called Composer to manage exactly what code runs on your site, and we never let anything update itself in the background. This article explains what that means in plain English, and why it's one of the biggest reasons our clients' sites don't get 2am surprises.

Out of the box, WordPress is designed to be easy, sometimes too easy. Core, plugins and themes can all be set to update themselves automatically, with no one reviewing the change before it goes live on your website. Most of the time that's fine. Sometimes it isn't: a plugin update changes how it behaves, conflicts with another plugin, or simply ships a bug. And because it happened automatically, usually overnight, nobody finds out until someone notices the website isn't working properly.

By then, the question isn't just "what broke?" It's "what changed, and when?" If updates have been happening automatically for months, often nobody really knows. Fixing it usually means a developer logging in under pressure, trying to work out which of dozens of recent, unreviewed changes is the culprit, while your website is live and broken in front of customers.

This isn't hypothetical. When WordPress 7.1 was released on 19 August 2026, a change in WordPress itself caused a fatal error in WP Rocket, one of the most widely used caching plugins, on sites that also ran certain other plugins. One hosting company reported that 124 of its 332 production sites crashed. WP Rocket had been told about the bug six weeks earlier, during WordPress 7.1's testing phase, and released a fix the day after launch. By then, sites that had updated WordPress automatically were already down.

Plugin updates cause the same problem. In September 2026, Elementor 4.3.0, one of the most widely used page builders for WordPress, caused a fatal error on sites that also ran certain versions of Elementor Pro, and pages simply stopped loading. The follow-up release two days later shipped with the same bug, and a working fix only arrived later that day. A few months earlier, in May 2026, an update to Shortcodes Ultimate, a plugin running on more than 400,000 sites, shipped with missing files and took sites offline the moment it installed. The developer had a fix out within the hour, but any site that had already updated itself stayed down until someone stepped in.

In both cases the bug would have shown up in staging within minutes. On a site that updates itself overnight, it shows up when your customers do.

WordPress on Composer means every piece of code on your site, from WordPress itself to each plugin and theme, is installed at an exact, recorded version. Think of your website's code as a recipe, not a pile of ingredients someone keeps swapping out on the shelf. Composer is the standard tool PHP developers use to manage the code a project depends on. Roots, a well-known open-source project, uses it in Bedrock to run WordPress this way, and it's the foundation we build on. Composer writes down the exact recipe for your site: the precise version of WordPress itself, and the precise version of every plugin and theme it depends on.

Nothing on the live site changes that recipe by itself. WordPress isn't able to quietly swap in a newer plugin version on its own, because the version that's installed is defined in code, not decided on the fly by the server. If we want to change a version, we change the recipe deliberately. We don't let the kitchen rewrite itself overnight.

This is what developers call "pinning": your site runs on exact, known versions of everything, and those versions only change when we change them. No plugin update happens because a vendor pushed one out at 3am your time. No "WordPress updated itself and now the checkout page is blank." The version running today is still the version running tomorrow, unless we've deliberately decided otherwise.

That might sound restrictive, but it's the opposite: it means updates happen on our schedule, with our full attention, not on a schedule set by plugin vendors scattered around the world.

Because every version is defined in code, every change to it is recorded the same way any other code change is: in version control, with a record of what changed, when, and who approved it. If a plugin moves from version 4.2 to 4.3, that's a specific, dated, attributable change, not a silent background event.

That matters more than it might sound. If something ever does go wrong, we're not guessing what changed. We can see exactly which version introduced a problem, when it happened, and roll it back with confidence, because we know precisely what the site looked like before and after.

For our larger enterprise clients, this record isn't a nice-to-have. Universities, government-adjacent organisations and listed companies are often required to show exactly what changed in their systems, who approved it and when, whether for internal change management, security reviews or audits. A version-controlled history of every dependency answers those questions directly, without anyone reconstructing events from memory.

It's also becoming more important for everyone. AI tools are finding and publishing vulnerabilities in WordPress plugins faster than ever, so new security advisories land almost weekly. When one is announced, the first question is "are we affected?" Because we know the exact version of every plugin on every site, we can answer that in minutes, patch only the sites that need it, and show precisely when each one was fixed. We look at how AI is speeding up vulnerability discovery (coming soon), and why that makes fast, disciplined updates essential, in the third article in this series.

Because the recipe is written down, every copy of your site is built from it in exactly the same way. Your live site, the staging environment and our developers' own environments all run byte-for-byte the same code: the same WordPress version, the same plugins, the same theme.

That removes one of the most frustrating situations in web support. When you tell us how to trigger a problem on your live site, we can reproduce that exact problem on staging, rather than finding it "works fine on our end". We can then fix it, test the fix and prove it works before it goes anywhere near your customers.

Updating a pinned dependency isn't a single click. Before any new plugin or WordPress version goes anywhere near your live site, it goes through our standard process: it's proposed as a change, run through automated checks, tested in a staging environment, reviewed by a developer, and only then deployed to production deliberately.

That process is what actually prevents the 2am outage. It's not that updates never happen. They absolutely do, regularly, because staying current matters. It's that they happen while we're watching, not while everyone's asleep.

It's worth being upfront about what pinning alone does and doesn't protect against. Pinning stops an update from happening without anyone looking at it first. It doesn't automatically make the thing you're pinning to safe if the update has already been tampered with at the source, before we ever see it. That's a real and growing risk, and it's exactly why review and testing before deployment matter as much as pinning does. We cover what that looks like in practice, including real incidents where the update itself was the attack (coming soon).

• No surprise outages from an update nobody reviewed
• A clear, dated record of exactly what's running on your site, and why
• Faster, more confident fixes if something ever does go wrong, because we know what changed
• Updates that happen deliberately, on a schedule we control, not whenever a plugin vendor pushes one out
• Problems you report on your live site can be reproduced exactly on staging, so they get fixed properly the first time

It's one part of a broader approach we take to keeping client sites stable and secure. The rest of this series covers:

• How our Enterprise-grade hosting locks files down to stop the kind of attacks that plague "plain" WordPress and other content-managed sites
• Why disciplined, fast updates matter more than ever, now that vulnerabilities are found and exploited faster, and updates themselves can't always be trusted blindly
• How Cloudflare filters attacks before they reach your site
• How we bring it all together for new projects and sites we take over from other agencies

Vivo Group is a Brisbane-based web development and hosting agency. We build and maintain WordPress sites for clients who can't afford the 2am phone call. Every site we manage runs on pinned, version-controlled dependencies, with changes reviewed and tested before they ever reach your live site.

If your current website has you wondering what's actually running on it, or when it was last properly reviewed, get in touch to talk about how we manage WordPress differently.

What is Composer in WordPress?

Composer is PHP's standard tool for managing the code a project depends on. On a WordPress site, it records the exact version of WordPress and of every plugin and theme in a file kept in version control, so the site only changes when a developer deliberately changes that file.

Should I turn off WordPress automatic updates?

Only if someone is reviewing and applying updates instead. Automatic updates deliver security fixes quickly, but they can also break a site without warning. The safer approach is to pin versions and apply updates regularly through a tested process, so you get the fixes without the surprise outages.

What does pinning a plugin version mean?

Pinning means a site runs one exact, recorded version of a plugin until someone deliberately changes it. The plugin can't update itself overnight, and every change is reviewed, tested and logged.

Can a plugin update take a WordPress site offline?

Yes. In September 2026, an Elementor update caused fatal errors on sites running certain versions of Elementor Pro, and in May 2026 a Shortcodes Ultimate update with missing files took sites offline as soon as it installed. Testing updates in a staging environment first catches problems like these before they reach your live site.

What is Bedrock?

Bedrock is a WordPress setup from the open-source Roots project that manages WordPress with Composer. It's the foundation we build our WordPress sites on.

Keep reading: Read-only hosting: the simple rule that stops webshell attacks