Core and Plugin Updates - Zephyra Studio

What core and plugin updates are and who they are for

Core and plugin updates mean installing the newest released versions of WordPress itself, your theme, and every plugin running on the site. The update is not a single click in the dashboard. It is a cycle: take a full backup, clone the site to a staging copy, apply the updates there, check that nothing broke, then push the tested versions to the live site and watch it for a few days afterwards.

This service is for any site built on WordPress or a similar system with a plugin ecosystem, where a stack of third-party components accumulates over time. If you run a webshop with a payment plugin, a booking plugin, an SEO plugin, a form plugin, and a caching plugin, you are carrying five or more external codebases. Each of them ships its own updates. Each of them can break the others. That is the situation this service exists for.

It is also for sites that were handed over as a finished project and then left untouched. A site that went live two years ago without a single update now carries every security patch and every compatibility fix that was published in the meantime, all missing at once.

Why updating on a schedule beats the alternatives

The alternative most owners choose is reactive updating: nothing gets touched until something visibly breaks, then one frantic round of updates on the live site. This is the approach that produces white screens and broken checkouts, because an untested update lands directly on production with no backup of the working state right before it. Doing updates on a schedule on a staging copy reverses the order of risk: you find the incompatibility in a sandbox, not in front of your customers.

The other alternative is the opposite extreme: never update, on the theory that a working site should not be touched. That reasoning holds until a vulnerability in an outdated plugin gets exploited, or until your hosting provider drops support for the old PHP version your stack depends on. Because updates arrive continuously from many independent plugin authors, the two real choices are controlled, tested updates at a steady rhythm, or an emergency handled under pressure after the site is already down.

This is a different job from general site maintenance. General maintenance covers backups, uptime checks, and performance (see the parent Website maintenance page). Core and plugin updates are specifically about version management and dependency conflicts, which is why they need their own process and their own staging step.

Where it gets genuinely tricky is the stack-wide picture. Suppose a plugin author adds support for a newer version of another plugin, but that new version no longer supports the PHP version your host runs. Core, plugins, and themes form a dependency chain, and updating one link can force the others into a coordinated move. That is the part a scheduled, tested process handles well and a once-a-year panic does not.

How we handle core and plugin updates

Stefan handles this directly with you, working remotely, one person across the whole cycle. The workflow is fixed: a full backup runs first, then the site is cloned to a staging copy, then core, theme, and plugin updates are applied on staging only. We walk through the site there, front end and admin, checking the pages and flows that depend on the plugins you actually use running, forms submitting, payments processing, pages rendering. Only after that does the live site get the tested set of versions. After the deployment we watch the live site for a few days, and if something turns out wrong we roll back to the backup taken at the start of that cycle.

We keep a short record per site of which plugin versions are in play and which ones have known interactions, so each round starts from a known state instead of guessing. When a plugin's update is risky enough that testing is not conclusive, we hold that specific component back and update it separately once the vendor publishes a fix, instead of forcing the whole stack forward.

You hear from us at the start: we answer any query within 24-48 hours, and we will flag before applying anything that looks likely to break your particular setup. Two rounds of design revisions are included in our standard project work, but updates do not involve design revisions, they involve testing and applying versions.

Indicative pricing

Price depends on the size of the stack, how many plugins and customizations your site carries, and how often you want the update cycle to run. There is no fixed number we can put here. Tell us what your site runs and we will walk you through the figures through the calculator or a short conversation, and payment follows our standard terms: 50% advance before the work starts, the remaining 50% on delivery.