PHP 8.2's security support is only until the end of 2026, how to arrange the upgrade plan for sites still running old versions

PHP 8.2's security support is only until the end of 2026, this date is not 'end of feature updates', but 'the official will no longer release security fixes for this branch'. For websites, after the demarcation line, each new vulnerability must be borne independently. For websites still running old versions, the correct approach is not to temporarily grab a patch, but to arrange a schedule of upgrade plans according to the support cycle, listing the end dates, business importance, and rollback paths into an executable schedule.

What is the support cycle page reading?

php.net's support policy is two-phase: each officially released branch enjoys a two-year full support period during which regular version updates will fix defects and report security issues; after two years, it transitions to a two-year critical security support period, dealing only with issues deemed critical. In terms of dates, the official security support end dates are 8.2 to December 31, 2026, 8.3 to December 31, 2027, 8.4 to December 31, 2028, and 8.5 to December 31, 2029.

Read this table and there are three key points. First, the cut-off date looks at security support, not active support, don't judge the remaining window by the frequency of feature updates. Second, after entering the critical security support phase, ordinary defects will no longer be repaired, and the priority of handling compatibility issues will also decrease. Third, when multiple branches coexist, we should converge to the latest usable level instead of shifting between the middle branches.

What will happen after the security support is stopped?

Once the branch has passed the cut-off date, the reality that the site faces is as follows:

What is really easy to ignore is the fourth line: many plugins and themes on the old branch will stop adapting one step ahead, and what you are facing is not 'PHP old' but 'the entire dependency chain aging'.

The three-step method of upgrading scheduling

Step one, perform a runtime inventory. Record the actual versions of each site, pay attention to distinguishing between the command line version and the interpreter version actually used by the site, as discrepancies between the two are a common source of accidents. Also, inventory the extension modules, listing compiled extensions (such as image, encryption, database drivers), as these are the most likely to break across major versions.

The second step is to classify by business importance. Label each site: external transaction and customer acquisition entry, internal system, event page, or long-tail content site. The purpose of classification is to determine the window rather than the strictness of the priority order - the first category should be scheduled during the daytime of weekdays with backups, monitoring, and immediate rollback capabilities, and the third category can be placed in the batch maintenance window.

The third step is to break the migration into several reversible steps. The recommended order is: first, run the new branch and all extensions in the test environment; then hang a new version entry next to the production environment, verify the same code; only after confirming that there are no errors can you switch to the default version; retain the old interpreter for a period of time to facilitate rollback. Before the entire process, there must be a complete backup. AnQiCMS's backup capability includes data and static files, so there is no need to manually fill in images and attachments when rolling back, which can significantly shorten the time for fault recovery.

The deployment method is also included in the schedule. AnQiCMS supports one-click deployment for Baota panel and aaPanel, command deployment under the LNMP environment, and Docker image deployment, with the default listening port 8001 forwarded by the reverse proxy; if sites in the same batch are mixed with several deployment methods, the length of the upgrade plan window and the fallback method should be written separately, and cannot share a time table.

Can this cycle be omitted when changing the runtime?

Cannot be completely omitted, but it can significantly reduce the surface area that needs to be synchronized for updates. The content system developed in GoLang (AnQiCMS's technology stack includes GoLang, Iris framework, and GORM) is delivered as a compiled product, with the language runtime and business code packaged together, the site no longer maintains a separate 'script engine version', and there is no longer a need to perform compatibility tests for interpreter extensions. Therefore, the boundary of responsibility for security fixes is clearer: upgrading the content system itself is equivalent to upgrading the runtime layer, and there will be no intermediate state where 'the program has been updated but the underlying layer is still on an old branch'.

This does not mean that you can ignore the version announcement. On the contrary, the upgrade of the compiled stack should pay more attention to the authentication and key change requirements in the release notes, as it incorporates more capabilities into the same upgrade.

Common questions

It's just the corporate website, with not much traffic. Can't we wait until it's no longer supported?

It is not recommended. The website is usually an entry point for acquiring customers. Once it is hacked, the cost of recovery is much higher than a planned upgrade, and search engines will take action against pages containing malicious jumps, and it will take time to recover the inclusion.

What should we do if there are multiple sites running different branches on the same server?

Manage with parallel entry of multiple versions, direct the parsing of each site to its respective interpreter, and record the corresponding relationship of 'site—branch—deadline' in the table to prevent subsequent maintenance from mistakenly thinking that the overall upgrade has been completed.

How do you know which version the site is actually running?

Check the system information page in the background or execute the language version query command on the server; it is unreliable to only look at the version labels in the program settings, as those are just configuration items and not the actual runtime settings.