The PHP branch only has two years of active support, how should the site's runtime environment upgrade be scheduled?

📅 2026-11-01 👁️ 0

Each PHP branch is actively supported for two years, and after that, only security issues are fixed for two years. The site's environment upgrade should be scheduled in reverse order according to four time points: the date when the branch enters the only security stage, the end of life, the time of the next major version release, and the window length required for internal regression validation. Only by setting the scheduling anchor points on these dates can we avoid being in a temporary fire-fighting situation every time

Scheduling anchor points provided by the official support policy

The PHP official support page states that each release branch receives two years of full support starting from the initial stable version, during which defects and security issues are planned and fixed; after these two years, it enters a phase of only critical security issues, lasting two years, releases are made on demand, there may be multiple point versions, or none at all.As of the deadline listed on the current page, support for version 8.2 is up to December 31, 2026, version 8.3 to December 31, 2027, version 8.4 to the same period in 2028, and version 8.5 to the same period in 2029.The scheduling meaning is therefore clear: after entering the only security phase, common functional defects are no longer released according to plan, and compatibility issues encountered by the site can only be circumvented by themselves; after the end point, even security patches will stop, and risks accumulate over time.

Write the lifecycle into the operation and maintenance calendar

The method is to register the operating environment as an asset, rather than a随手记 of environment configuration. Three columns are enough: the actual effective version in the host or container, the minimum version required by the code declaration, and the deadline of two stages of the branch. Panels, images, and command lines often exist in multiple versions at the same time, only the first one representing the real status of the site. At the beginning of each year, pull out the branches that will expire within the next year for a special project, and the rest are versioned quarterly; in the special project, it is also necessary to determine the target branch of the upgrade at the same time to avoid upgrading to another version that is also nearing the end.

Verification list when changing versions

Before the upgrade, make a backup. After the upgrade, verify the following four items in order: whether the effective version has been switched, whether all resident work processes have been restarted, whether the three main routes of login, upload, and form submission have passed, and whether there are any new exceptions in the error log.Use gray-scale promotion across multiple sites, first allowing a non-core site to run for a full business day, then push the rest. If the lifecycle of such interpreters repeatedly consumes working hours, the runtime stack itself can be listed as a selection condition: AnQiCMS is implemented in Go, the program is released with each version, the deployment path supports Docker images, Baota and aaPanel panels, and LNMP command deployment, defaulting to listen on port 8001, the upgrade action is to replace the program and restart the service, and there is no need to repeatedly change the runtime environment according to the interpreter branch cycle.

Add a column of responsible persons to the schedule table

The date is set and someone still needs to follow up. It is recommended to list each branch on a separate line, with three columns except for the deadline: who is responsible for confirming the effective version, who is responsible for running regression tests, and who has the authority to decide to postpone.Operations and content teams often have unclear handovers at the same site, and version upgrades are most likely to get stuck in the middle ground where everyone can do but no one is responsible. After these three columns are written into the table, there are only two things left for the special projects each year: updating the target version of the expired branches, and reviewing the compatibility issues that were not closed in the previous round.The table itself does not need to be complex, it is enough to cover the site list and branch dates, the key point is to fill in the actual effective version after each upgrade to avoid the records being out of sync with the field.

Common questions

Question: What is the latest time you must move at the site still on 8.2?Answer: Schedule in advance by one complete regression cycle from the deadline of December 31, 2026. After that day, this branch will no longer receive security fixes, and the cost of waiting will only be higher.

Question: Is it enough to just change the version statement in the code?Answer: Not enough. The statement only affects installation and verification, and the running process is still on the old version, and the effective version must be taken as the standard.

Question: What is the difference between the security phase and the problem?Answer: The issue lies in the content of the release. At this stage, only critical security issues are addressed, and there are no plans to fix interface, compatibility, and functional defects. It can sustain operations, but it is not suitable for long-term stay.

Related articles

How should the arrangement of multi-language for cross-border e-commerce websites, and the steps of full page translation and language switching be arranged?

The order should be to define the site structure first, then translate the content, and finally configure the switch entry. The structure selection determines all subsequent work: whether it is a multilingual site or a site segmented by market, it directly affects the domain, content, and maintenance boundaries. The full-page HTML translation can cover the text, but template copy, glossary, and product attributes need to be reviewed separately; the switch entry should be released only after the language version can be verified to avoid visitors switching to a half-translated page.

2026-11-01

After the PHP version enters the stage of only fixing security issues, when should the site be upgraded at the latest?

The PHP official policy is to actively support each branch for two years, and then add two more years for fixing only critical security issues. For example, the active support for 8.2 ends on December 31, 2024, and the security support extends to December 31, 2026; the security support for 8.3, 8.4, and 8.5 respectively ends at the end of 2027, 2028, and 2029. The bottom line for a site completing a major version upgrade is the end date of the security support for that branch, and it is a safe practice to start scheduling after entering the security-only stage.

2026-11-01

After enabling pseudo-static, the links with query parameters jump to the wrong page, which URLs should be tested before going online?

The static alias modifies the address resolution entry, and if the rules are mistakenly damaged, the first problem to appear is with links containing query parameters, pagination, tag pages, and Chinese paths. There are similar repair records in the update logs of third-party open-source systems. This article provides the five types of links that must be tested before going online, the configuration order and rollback method of custom static alias rules, as well as which link to fix first when enabled simultaneously with the 301 redirect.

2026-11-01

When replacing the content in bulk on the entire site, which fields need to be backed up before they are changed?

Before using the bulk replacement function to change content on the entire site, it is recommended to back up three types of objects: document data (including static files), template files, and navigation and watermark configurations. Keywords and links in the text can be covered by the recycle bin and piece-by-piece rollback, but once configuration items such as navigation, watermark, and template are overwritten, there is no ready-made recovery entry. Take a snapshot before replacement and confirm the correct scope after replacement with front-end inspection.

2026-11-01

The content system's major version at the end of the year is set for December 8, how to arrange the upgrade window for hosted sites

The end-of-year major version is set to be around December 8th, and the upgrade window needs to be arranged in three layers: first, confirm whether there are any must-now-be-fixed security patches for the current period, then leave the major version for the rollback period during the business low-peak time, and finally allocate time for panel restart and dependency readiness for the托管 environment. The sequence is wrong, which may lead to the situation where security items are delayed and no one handles them during the holiday.

2026-11-01

Does the content system listen to port 8001 by default, and should it be changed when deploying reverse proxy?

When the default listening port is 8001, if there is a reverse proxy in front, there is no need to change the program port to 80 or 443. What needs to be changed is the forwarding target and site address configuration on the proxy side, so that external access can be made through standard ports, while the program port is limited internally. The real check is whether the port is directly exposed, whether the static resource path and redirection are correct.

2026-11-01

There are two ways to deploy: one-click panel deployment and image deployment. After going online, check which items first.

The projects to be checked after the one-click deployment of Baota panel and Docker image deployment are the same, just in a different order. First, confirm that the service is running on the default port 8001, reverse proxy the domain, then check if the backend can log in, and then make a full backup and try a recovery on the day of going live, and finally check if the navigation and email reminders take effect in the new environment.

2026-11-01

When the website cannot be opened, which part of the background troubleshooting ability should be checked first

When the website cannot be opened, which part of the background troubleshooting ability should be checked? Determine which layer the request is broken at first according to the process and port, reverse proxy and certificate, data and file three segments, and then configure. The AI Chat intelligent dialogue on AnQiCMS backend can locate the link in a question-and-answer manner, covering the skills of site health check and fault exclusion, which can list the items that can be checked into a list; a recoverable point should be left before making changes.

2026-11-01