Most business owners never choose a PHP version. Their website was built on a content management system or framework that runs on PHP, the hosting company installed whatever version was current at the time and nobody has looked since. The site keeps working, so the question never comes up.

That quiet is the problem. PHP versions have published end dates, after which they stop receiving security fixes. When a site keeps running on an unsupported version, every newly discovered flaw in that version stays open. And because the version lives on the server rather than in the site’s dashboard, many owners have no idea which one they are using or who is responsible for changing it.

This article explains how PHP support works, why the end of the year is a natural checkpoint and which questions to put to your host so the answer is never “we’re not sure.”

How PHP support periods work

PHP releases a new major version roughly once a year. Each version then goes through a period of active support, when bugs and security issues are fixed, followed by a period of security-only fixes, and finally end of life.

In its October 2, 2024 post PHP Core Roundup #19, the PHP Foundation explained a change to that schedule. Under the updated release cycle, all PHP versions from 8.1 onward get two years of security fixes instead of one, after the existing two years of active support. Support and end-of-life dates were also aligned to December 31 of the relevant year to make them more predictable.

The post published the resulting dates. PHP 8.1 reached end of life on December 31, 2025. PHP 8.2 is scheduled to reach end of life on December 31, 2026, PHP 8.3 on December 31, 2027, and PHP 8.4 on December 31, 2028. For anyone reading this in late 2026, that means a site still on PHP 8.2 has only a couple of months of security fixes left, and anything older is already past its end date.

Why your content management system cares

Your site’s software has its own view of which PHP versions it supports. WordPress, which runs a large share of small business sites, sets both a minimum supported version and a recommended one.

In a January 9, 2026 post, Dropping support for PHP 7.2 and 7.3, the WordPress core team said support for those versions would be dropped in WordPress 7.0, then scheduled for April 2026, raising the minimum supported version to PHP 7.4.0. The post said the minimum recommended version would remain PHP 8.3. It explained that the project has historically used 5 percent usage as the threshold a version must fall below before support is retired.

The post also clarified what happens to sites left behind. Sites running PHP 7.2 or 7.3 would remain on the WordPress 6.9 branch once 7.0 was released. While only one branch officially receives security updates, it said, fixes are backported to older branches as a courtesy when possible.

Note the gap between “minimum supported” and “recommended.” A version can still be allowed by your content management system long after PHP itself has stopped fixing security problems in it. The WordPress post itself shows the pattern: it kept PHP 7.4 as the minimum supported version while recommending PHP 8.3. Supported by your software is not the same as safe.

Hands in green sleeves tick empty checkboxes with a coral pen beside a light blue desk phone.

What happens when flaws are exploited

Older PHP versions are not a theoretical risk. Attackers actively look for servers running vulnerable software.

On June 12, 2024, the Cybersecurity and Infrastructure Security Agency added two vulnerabilities to its Known Exploited Vulnerabilities Catalog based on evidence of active exploitation. One was CVE-2024-4577, a PHP-CGI OS command injection vulnerability. The agency said such vulnerabilities are frequent attack vectors for malicious cyber actors, and it strongly urged all organizations, not only federal agencies, to prioritize timely remediation of catalog vulnerabilities as part of their vulnerability management.

That particular flaw affected specific configurations, but the broader lesson applies to every site. Security fixes only help if they reach your server. A version that no longer receives fixes cannot be patched when the next issue is found.

Signs your site may be on an old version

You do not need server access to suspect a problem. A few clues are worth noticing.

If the site has not had a significant update in several years, if the developer who built it is no longer involved or if the hosting plan was set up long ago and never reviewed, the PHP version is likely old. If your dashboard shows warnings about the server environment, or plugins refuse to update because of version requirements, the server is probably behind.

Many content management systems include a site health or system information page that lists the PHP version. In WordPress, for example, the built-in Site Health screen shows server details. Your hosting control panel may show it too. If you cannot find it, ask your host directly; it is a routine question.

Once you know the version, compare it with the dates the PHP Foundation published. If your version is past its end-of-life date or close to it, put the upgrade on the schedule now.

Different hosting, different responsibilities

Who handles PHP depends heavily on the type of hosting you have, and contracts are not always clear about it.

On shared hosting, the provider runs the server and usually offers a menu of PHP versions. They may move customers to newer versions on a schedule, or they may leave each site on whatever it was set to until the owner changes it. Some providers keep offering old versions long after they stop receiving security fixes, sometimes for an extra fee.

On managed hosting built for a particular content management system, the provider often takes more responsibility, testing and applying upgrades for you. Even then, confirm how they handle sites with plugins or custom code that might not be compatible.

On a virtual private server or dedicated server, the operating system and PHP are usually your responsibility or your developer’s. The host keeps the hardware running; everything above it is yours.

Read your hosting agreement or support pages for the words “PHP version,” “end of life” and “legacy.” If the answer is unclear, ask for it in writing.

Questions to ask your host

Hosting arrangements vary widely. On some plans, the host manages PHP versions automatically. On others, you or your developer choose the version in a control panel. On a dedicated or virtual server, updates may be entirely your responsibility. The first step is finding out which situation you are in.

Ask your host these questions, and write down the answers.

Which PHP version is my site running right now, and is it receiving security fixes? Who is responsible for moving my site to a newer version: you, me or my developer? Do you apply PHP security releases automatically, and how quickly after they are published? Will you notify me before a version I am using reaches end of life, and what happens on your platform after that date? Can I test my site on a newer PHP version before switching, for example on a staging copy? If an upgrade breaks something, how quickly can we roll back? Do you charge extra for continued use of old versions, or for help with upgrades?

Clear answers to these questions tell you whether PHP is being looked after or simply left alone, and they give you a baseline to compare against next year too.

Upgrading without breaking the site

PHP upgrades usually go smoothly, but they can expose old code. A theme or plugin written years ago may use features that newer versions have removed, and a custom integration may depend on behavior that has changed.

The safest approach follows a simple order. Back up the site and confirm the backup can be restored. Create a staging copy and switch it to the newer PHP version. Update the content management system, themes and plugins to their current releases. Then test the parts of the site that matter most: forms, checkout, bookings, logins and any integrations with outside services.

Watch error logs during testing. Warnings about deprecated features are an early sign of code that will break on a future version, even if it works today.

When staging looks good, schedule the live switch for a quiet time and recheck the same pages immediately afterward. Keep the old version available for a quick rollback if something unexpected appears.

An older man in a light blue shirt smiles at a laptop in a green armchair.

When old code is holding you back

Sometimes the upgrade cannot happen because a key plugin has been abandoned or a custom feature was built for an old version and never updated. That situation deserves attention rather than delay.

Options include replacing the abandoned plugin with a maintained one, having a developer update the custom code or, in some cases, rebuilding that feature in a simpler way. The cost of doing this is usually smaller than the cost of staying on an unsupported version until something goes wrong.

It is also a good moment to remove what you no longer use. Every inactive plugin and old theme is code that has to be compatible with each new PHP version and kept secure. Deleting it shortens testing, reduces the number of things that can break and leaves fewer forgotten files for attackers to probe.

Keeping everyone informed

PHP upgrades touch people beyond the developer. Staff who update content, process orders or manage bookings may notice small changes after a switch, and they are often the first to spot a problem.

Before an upgrade, tell the team when it will happen and what to check afterward. Give them one place to report anything odd. Afterward, confirm that everything is working and note the date and new version in your website records, so the next review starts from accurate information.

Building a yearly PHP checkpoint

Because PHP end-of-life dates now fall on December 31, the end of the year is a natural moment to review. Put a recurring reminder on the calendar for October or November. Check which version the site runs, compare it with the published support dates, ask your host about plans and schedule any upgrade before the holidays rather than during them.

Pair the PHP review with your content management system, theme and plugin updates, and with a check that backups and monitoring still work. Together they cover most of the technical upkeep that keeps a business site healthy.

Getting help with the upkeep

PHP versions are one of many details that keep a website secure and running. If you would rather not track them yourself, Motta’s website maintenance plans include version monitoring, staging tests and upgrades. Our web hosting keeps supported PHP versions current, and our content updates service handles the edits that come with a well-maintained site.