Why the host's deadline is real
Every PHP branch gets two years of full support and then two more years of security fixes only, after which it is end of life. On 11 October 2026 the PHP project's page showed branch 8.2 with security support ending on 31 December 2026, 8.3 in security-only support until 31 December 2027, 8.4 in active support until 31 December 2026, and 8.5 released on 20 November 2025. WordPress's requirements page recommends PHP 8.3 or greater and describes older setups, such as PHP 7.4, as possibly still working but past end of life and potentially exposing a site to security vulnerabilities. A host that announces a retirement date is therefore doing what the schedule requires, and one old plugin can become the reason a site cannot follow.
- Check which branch your site runs under Tools, Site Health, Info.
- Ask your host for the retirement date for that branch on your plan.
- Choose a target version with your host, not simply the newest one.
What a compatibility scanner proves
PHPCompatibility is a set of rules for the PHP_CodeSniffer tool that reads source files and reports code that was removed or changed between versions. Its README explains that if you give it a target version it also reports features newer than that target, and that a range reports anything affecting any version in it. It is good at finding removed functions, changed signatures and deprecated syntax across a whole plugin folder in seconds. It is not a test of behaviour: it reads the code without running it, it says its own coverage is not 100 percent, and some of its checks work from name prefixes, so they can flag your own functions by mistake. A clean scan is therefore necessary evidence, not sufficient evidence.
- Run the scan with an explicit target version, otherwise you only see deprecations and removals.
- Install a tagged stable release of the scanner and record its version with the results; on 11 October 2026 the project's latest stable release was 9.3.5 and 10.0.0 was only an alpha pre-release.
- Record the plugin version scanned with the results.
- Treat each finding as one of: fix, justified to ignore, or unknown.
Running the plugin is the second half of the proof
After the scan, run the plugin on a staging copy at the target version and read the PHP log while exercising each function you care about: saving a form, rendering a shortcode, importing a file, a scheduled task. New deprecation notices naming the plugin's folder are findings the scanner missed. Compare behaviour with the old version, because a function can stop producing an error and start producing a different result. The plugin header field Requires PHP only states the maker's minimum; it says nothing about which newer versions were tested, so a plugin that claims to need at least 7.4 may never have been run on 8.4.
- List three to six functions that must work before you start.
- Switch a staging copy, not the live site, to the target version.
- Keep the previous version available so you can switch back.
Patch, update or replace
The first question is whether the plugin's maker has already published a version that supports the target. If yes, install that on staging and you do not need a patch. If the plugin is custom-built for you or abandoned, you can patch its code, but a patch to an abandoned plugin is yours to maintain, and a patch to a plugin that updates will be overwritten. Replacing the plugin with a maintained one that does the same job is often the more durable choice when the function is common. The decision depends on how special the function is, whether the licence lets you modify the code, and whether the code is readable at all: encoded or obfuscated plugin code cannot lawfully or reliably be patched.
- Never edit a maintained plugin's files inside the live site.
- Ask whether the function can be done by WordPress itself.
How the paid patch job is accepted
The single-plugin job has a published test price of GBP 295 and covers one plugin and one target version. It is accepted when the scan of the plugin folder reports no errors for the agreed target, each agreed function passes on a staging copy at that version, no new PHP error naming the plugin appears in the log, and the site's home page, login and Plugins screen load with it active. It excludes more than one plugin, server changes such as installing an extension, encoded code, and switching the live site. Prices are untested proposals and payment follows the agreed checks.
- Send the plugin name and version, current and target PHP versions and the function list, never code or logins.
- If two or three plugins are involved, ask for a wider quote instead.
Sources and limits
- PHP: supported versions Checked 2026-10-11.
- On 11 October 2026 the page listed 8.2 (security support to 31 December 2026), 8.3 (active support ended 31 December 2025, security support to 31 December 2027), 8.4 (active support to 31 December 2026, security to 31 December 2028) and 8.5 (released 20 November 2025).
- Each branch has two years of active support and two more of security fixes only; after four years it is end of life.
- WordPress: requirements Checked 2026-10-11.
- It recommends PHP 8.3 or greater, and says older setups such as PHP 7.4 may still work but are past end of life and may expose a site to security vulnerabilities.
- PHPCompatibility README Checked 2026-10-11.
- It is a set of sniffs for PHP_CodeSniffer that checks cross-version compatibility; setting testVersion to a single version or a range also detects code that uses features newer than the target.
- Coverage is not 100 percent, and some sniffs use name prefixes and can clash with your own functions.
- PHPCompatibility releases Checked 2026-10-11.
- On 11 October 2026 the latest release marked stable was 9.3.5, and 10.0.0 was available only as alpha pre-releases (10.0.0-alpha1 on 21 October 2025 and 10.0.0-alpha2 on 28 November 2025).
- WordPress plugin handbook: header requirements Checked 2026-10-11.
- The Requires PHP header declares the plugin maker's minimum PHP version; it is not a statement of which later versions have been tested.