What PHP 8.2 end of life means for your site
The PHP 8.2 end of life deadline is 31 December 2026, when upstream security support ends under the published PHP support timetable. Most maintained websites should move to a supported PHP version through staging and business-critical testing. The deadline alone is rarely a reason to rebuild.
Your website will not necessarily stop running on that date. PHP 8.2 may remain available on your server, but it will no longer receive upstream security fixes. Your hosting provider may keep it temporarily, replace it automatically or offer its own extended support.
Those are three separate issues: upstream PHP support, whether the site still executes and the host’s policy. Hosting warnings often compress them into one alarming message.
Ask your provider these questions:
- Will PHP 8.2 remain available after upstream support ends?
- Will the selected version be changed automatically?
- If so, which PHP version will replace it and when?
- Does continued PHP 8.2 use attract an extended-support charge?
- Can you create a staging environment using the proposed version?
- How quickly can the previous version be restored if deployment fails?
A working site can still carry avoidable risk. If a vulnerability is found in an unsupported runtime, an upstream correction may never arrive. Delaying also increases the chance that a future hosting change becomes an urgent production problem rather than planned maintenance.
This does not make every PHP 8.2 site an automatic UK GDPR breach. UK GDPR Article 32 requires security measures appropriate to the risk, while the ICO identifies in-support software and patching as ways to manage software vulnerabilities. The NCSC also advises organisations to use vendor-supported software because security updates cease when support ends.
The practical response is evidence-led maintenance: understand the application, test the supported destination and keep a rollback route.
Check your PHP version and identify every dependency
For WordPress and WooCommerce, start in the dashboard. WordPress documents Tools > Site Health > Info as the place to inspect the site environment. Open the server section and look for the PHP version.
Your hosting dashboard may also show the selected WordPress PHP version. Labels and controls vary by provider, so treat the dashboard as a useful second check rather than an invitation to change the live setting.
For a Laravel or bespoke application, ask the developer or technical team to confirm:
- The PHP runtime used by the live application
- The framework and application version
- The Composer packages and locked dependency versions
- Any worker, queue or scheduled-task runtimes
- The PHP versions supported by the complete dependency set
Do not discover a bespoke application’s compatibility by experimenting in production. The main web pages might load whilst background jobs, imports or payment callbacks fail out of sight.
Create a short inventory before deciding the scope:
| Area | What to record |
|---|---|
| Application | WordPress core, WooCommerce, Laravel or bespoke system version |
| Presentation | Active theme and any child theme or custom front end |
| Extensions | Plugins, Composer packages and privately maintained modules |
| Commercial functions | Checkout, subscriptions, refunds, stock and customer accounts |
| Integrations | Payment services, CRM links, email providers and external APIs |
| Background work | Scheduled tasks, queues, imports, exports and webhooks |
| Custom code | Who owns it, where it is stored and whether it has documentation or tests |
Confirm that you have working access to the website administration, hosting account, domain settings and source code where relevant. A backup also needs to be restorable. A download whose contents and recovery process nobody has checked is weak protection.
Should you move to PHP 8.3, PHP 8.4 or PHP 8.5?
PHP 8.4 is a sensible destination for many current sites because it provides a longer support window. The published timetable gives PHP 8.3 security support until 31 December 2027 and PHP 8.4 until 31 December 2028.
That does not make PHP 8.4 the correct choice for every application. The whole stack must support the selected release, including the framework, theme, plugins, packages, hosting environment and custom code.
For WordPress, the core team documents WordPress 6.8 and later as fully supporting PHP 8.4. Themes and plugins still require separate checks. A compatible core version cannot repair an abandoned extension.
For WooCommerce, the published server requirements recommend PHP 8.3 or greater and document testing through PHP 8.4. Store-specific extensions, payment gateways and integrations remain part of the test scope.
Laravel compatibility depends on the framework release and Composer packages. Laravel 13 supports PHP 8.3 through 8.5 and is scheduled to receive security fixes until 17 March 2028. An older application may need framework and package upgrades before its Laravel PHP version can change safely. We work with these dependencies as part of our Laravel development service.
We would not select PHP 8.5 merely because it has the highest version number. New runtime support can lag across hosting platforms and application dependencies. Even individual point releases matter: WordPress hosting guidance identifies a SimpleXML regression in PHP 8.4.27 and 8.5.12 that can crash PHP in certain cases.
Our usual decision order is:
- Use a compatible PHP 8.4 point release when the complete application supports it.
- Use PHP 8.3 as a controlled interim destination when a required dependency blocks PHP 8.4.
- Choose PHP 8.5 only after confirming support throughout the application and hosting environment.
An interim move still needs a recorded follow-up. Otherwise, one deferred compatibility problem simply becomes the next deadline.
Use a staged upgrade rather than a live hosting toggle
WordPress advises owners to back up the site, update supported software and test PHP changes on staging. We use the same principle for WooCommerce, Laravel and bespoke applications, with tests adapted to what the system does for the business.
A safe sequence looks like this:
- Record the live setup. Capture the application version, PHP version, enabled extensions and relevant hosting configuration.
- Verify recovery. Confirm that files and data are backed up and that the restoration route is understood.
- Create staging. Copy the application and representative data into an environment separated from real customers and transactions.
- Update supported dependencies. Bring core software, plugins, themes, frameworks and packages to versions that support the target PHP release.
- Change PHP on staging. Apply the intended runtime there first and review visible errors and application logs.
- Test business-critical journeys. Loading the home page is insufficient.
- Prepare rollback. Record who can restore the previous runtime, code and data if deployment fails.
- Deploy during a quiet period. Apply the tested changes, then monitor the same critical journeys in production.
For a marketing site, testing should cover navigation, forms, search, administration, media uploads and email delivery. For WooCommerce, add products, baskets, checkout, payment responses, account access, tax, shipping, stock updates, refunds and transactional emails.
For Laravel and bespoke systems, test authentication, permissions, forms, uploads, exports, API integrations, scheduled tasks, queues and background workers. Include administrative functions that customers never see. They are often where older code survives longest.
A rollback plan should cover more than switching the PHP selector back. Code changes and database migrations may also need reversing. Decide that process before touching production.
Read upgrade failures as evidence, not a rebuild verdict
Compatibility failures vary in significance. A maintained plugin with a released update presents a straightforward upgrade task. A small custom function using changed PHP behaviour may justify a bounded repair.
More serious findings include:
- A business-critical plugin or package that has been abandoned
- An unsupported framework with no credible upgrade route
- Custom code whose source, purpose or ownership cannot be established
- Several integrations depending on undocumented behaviour
- No staging environment, recovery route or reliable production configuration record
- Interdependent failures that make each isolated patch expose another problem
One failing extension does not justify throwing away an otherwise maintainable website. Replace or repair the component where the boundary is clear.
The calculation changes when remediation preserves an unsupported structure and leaves the business facing the same risk after substantial work. At that point, rebuilding can remove more risk than repeated compatibility patches. Our custom web development work follows that test rather than treating a runtime deadline as a sales argument.
Decide whether to upgrade, repair or rebuild
| Route | When it usually fits | Expected scope |
|---|---|---|
| Upgrade | Core software and important dependencies are maintained and support a current PHP release | Updates, staging, compatibility testing, deployment and monitoring |
| Repair and upgrade | A limited number of plugins, packages or custom functions block the target version | Replace or amend those components, then complete the staged upgrade |
| Rebuild | Unsupported foundations, abandoned dependencies or undocumented custom code make remediation prolonged and fragile | Specify required behaviour, replace the weak architecture and migrate necessary content or data |
Age alone is a poor rebuild criterion. A mature application with controlled dependencies, tests and clear ownership may be safer to upgrade than a newer site assembled from unsupported extensions.
Before accepting a proposal, ask the supplier to state:
- Which target PHP release and point version will be used
- Which dependencies are confirmed compatible
- Which journeys and integrations will be tested
- What remains outside scope
- How deployment and rollback will work
- What evidence would cause the recommendation to change from upgrade to repair or rebuild
A credible timescale or fixed quote depends on this discovery. We inspect the application before fixing the scope because the hosting warning reveals the runtime version, not the condition of the software running on it.
Treat the production PHP control as the final deployment step. Inventory, staging, testing and rollback planning should already be complete before anyone changes it.
If you need us to assess the safest route for your WordPress, WooCommerce, Laravel or bespoke site, start a project conversation.