Platform versions, updates and end of life

Software has a supported lifespan, whether or not anyone using it is aware of it, and the version currently running behind a site’s admin login is worth checking directly rather than assumed to be current. This applies to a self-hosted CMS core, to the language it runs on underneath, and to hosted platforms in a quieter but real way too.

What “end of life” (EOL) actually means

A specific version of software eventually stops receiving security fixes from its maintainers or vendor, once a newer version has superseded it for long enough — the industry’s own shorthand for this point is EOL (end-of-life), and a vendor sometimes distinguishes it from EOS (end-of-support), a slightly earlier date after which only critical patches, not full support, are still issued. A site still running a version past its EOL date is not necessarily broken — it may continue working exactly as before — but any vulnerability discovered in that version from that point on will never be patched, because nobody is maintaining it any longer. This is functionally identical to the abandoned-plugin risk covered in plugins and extensions, and the dependency you inherit, applied to the core platform itself rather than to an add-on.

Why this is quieter on hosted platforms

Shopify, Squarespace, Wix and Webflow generally update their own underlying software continuously and invisibly, without asking the site owner to do anything — the version question mostly disappears as a visible concern on a hosted platform, which is one of the genuine, if rarely stated, things the subscription is buying. It has not vanished entirely: a hosted platform can still discontinue a specific feature, app integration or theme format, which is its own version of an end-of-life event, covered in what happens when a platform is discontinued.

Why this is a genuine, ongoing task on a self-hosted CMS

WordPress’s own core software has a defined update cycle, and the language it runs on underneath — PHP, in WordPress’s case — has its own, separate end-of-life schedule, set by the language’s maintainers rather than by the CMS itself. A site can be current on the CMS core while running on a PHP version that has already stopped receiving security fixes, which is a genuine and commonly overlooked gap, because updating PHP is a hosting-level task rather than something the CMS admin screen prompts anyone to check.

What to actually check, and how

Most self-hosted CMS admin dashboards display the current core version on the main screen, and many hosting control panels display the server’s PHP version directly. Comparing both against the platform’s and the language’s currently supported versions — published openly by their respective projects — takes a few minutes and answers a question that otherwise goes unchecked indefinitely. A host or developer should be able to state both figures immediately if asked.

Why old versions accumulate quietly rather than dramatically

Nothing forces the issue the way a payment failure or an expired domain does. A site on an unsupported core version, or an end-of-life language version, simply continues running, often for years, with the risk accumulating invisibly rather than announcing itself. This is precisely the gap maintenance exists to close — a scheduled check, rather than a dramatic failure, is what actually prevents it.

Why version currency can be a compliance question too, for some organisations

Beyond the general security risk, a business handling payment card data, health records or other regulated information may have a specific compliance obligation to run only currently supported, patched software versions as part of a broader security standard it is required to meet — for that kind of organisation, an EOL version is not just a risk to manage on its own judgement, it can be a stated compliance failure regardless of whether an incident has actually occurred.

Why version currency is also a compatibility question, not only a security one

Beyond the direct security exposure, running a genuinely old core or language version can start silently limiting which current plugins, themes and integrations a site can actually use, because newer software increasingly assumes a reasonably current underlying version and stops supporting anything too far behind it. A business that has fallen behind on versioning may find it cannot install a plugin it actually needs, discovering the version gap only at the point it becomes an active obstacle rather than a quiet risk.

The specific risk of jumping several versions at once

A site that has gone a long time without updates faces a materially harder update path than one kept current continuously — jumping several major versions in one attempt is more likely to surface a breaking incompatibility than a series of smaller, regular updates would have been, because each individual step has not been tested along the way. This is one of the clearest arguments for a regular update cadence over an eventual, larger catch-up effort: the larger the gap, the riskier and more expensive closing it becomes.

A rough rule of thumb worth adopting

If nobody can immediately state the current core and language version behind a site, that is itself the signal that this check has not been happening on any schedule at all, regardless of how the site currently appears to be running.

Hosted platforms are not entirely exempt from this conversation

Even where the platform itself updates invisibly, individual apps and integrations added to a hosted store or site can still fall behind and stop being supported by their own developers, which is a smaller-scale version of the same versioning risk covered above, worth checking periodically regardless of platform.

A note on how quickly this can be fixed once identified

Unlike some of the other risks in this section, an out-of-date version is usually straightforward to remedy once it is actually noticed — the harder part is noticing it at all, which is why building the check into a routine rather than relying on someone stumbling across it is the genuinely valuable habit here.

Where to go from here

What a sensible update cadence actually looks like, and why “if it isn’t broken” is the wrong test to apply to a security-relevant update, is set out in software updates and website security. And who is actually responsible for checking any of this on an existing site is covered in who holds the keys to your website.