So Outside Technology Security CMS
AnQiCMS
Online Demonstration

The major versions of the program are all released in the first week of December, how to stagger the upgrade window?

📅 2026-11-01 👁️ 0

The program major versions are all released in the week of December, how to stagger the upgrade window? First, look at the day's perspective: The Drupal core scheduling page indicates that the 12th version will be released in the week of December 7th, at the same time, the 10th version will reach the disable date on December 9th, and the page also specifically points out that these two events are in the same week; The WordPress release page indicates that version 7.2 will be officially released on December 8th. The key to staggering is not to pick a 'good day', but to group the sites according to the exposed surface, push them in batches, and leave out a re-examination time between each batch.

Two things in December coincide in the same week

The release of a new major version means changes in functionality and theme updates, the deactivation of old branches means that no further repairs will be made thereafter. When both are implemented at the same time, the actions of the site are actually two types: one is whether to upgrade to a new version, and the other is to leave the old version. The former can be evaluated calmly, and the latter has a firm deadline. Mixing them in a weekend increases the risk of verification overlap - on the same day, there is both a major version switch and a deactivation migration, and it is unclear which type of change caused the problem.

Why do upgrades at the same time interfere with each other

The occupation occurs in three places. In terms of manpower, the same group of people needs to do data backup, template adaptation, and content verification at the same time; in terms of verification, each site needs to run the core process once, and the verification window only makes sense for 24 to 48 hours; in terms of rollback, if multiple sites share a machine or the same deployment, a failure at one place will drag other sites back to the old version. Business factors are also叠加 at the end of the year: marketing activities and order peaks are usually arranged in December, and businesses that cannot be stopped will compress maintenance time accordingly.

The scheduling method of phased advancement

First classify the sites, and then advance in batches.

Batch Site type Action Verification requirements
The first batch Display type, no login, no transaction First do the migration of the disabled branch Page rendering and site map can be crawled as soon as possible
Second batch With form or member login Migration plus compatibility verification Login, submit, and message three processes in order
Third batch Transaction and main station Determine according to the major version situation, you can stop first at the supported branch The full process related to order and payment must cover all aspects, and the rollback points must be practiced.
The fourth batch Testing and internal sites New features used to verify the major version The conclusion is written into the plan for the next year

The schedule must reserve two buffers: at least one working day between batches, and the last batch must not be pressed after the disabled day. The major version itself is left for batches after the first batch to evaluate, to avoid dealing with two things at the same time during the same week.

How to group multiple sites without disrupting business

Site management is a prerequisite for batching: when managing multiple sites with one backend, the upgrade status between sites must be clearly distinguishable, otherwise the sentence 'only move two sites' cannot be executed. The dimension of grouping is recommended to be based on exposure surface rather than business department - anonymous accessible pages should be moved first, followed by pages that require an account, and finally, pages involving funds

Use time-limited release on the content side: Schedule the online time of year-end marketing content outside of the batch window to avoid the overlapping scenario of 'just upgraded pages and batch releases'; hold down the drafts that are already in the draft release state before the batch re-inspection passes

The deployment method determines the rollback speed. For Docker image deployment, rollback refers to rolling back to the previous tag and pulling up again; for deployment using Baota panel or LNMP commands, rollback involves the database and static files, so it is necessary to confirm the availability of backups before each batch starts, not just for the first batch.

Common questions

Can we skip the old branch and upgrade directly to the latest major version?Yes, but do one thing at a time: first solve the shutdown issue, and leave the new features of the major version to the next batch for evaluation, as mixing them in the same batch can cause the rollback scope to be out of control.

What will happen if we do not upgrade after the shutdown date?The site can still run, but there will be no more repairs from now on, new vulnerabilities will not be fixed by anyone, the risk accumulates over time, and it is not suitable for long-term stay.

Should the small site also be divided into four batches?Not necessary. For a single site, you can follow the three steps of 'backup and practice first, then migration, and finally verification' and it is sufficient. The value of batching only manifests in multi-site scenarios.

Related articles

A fixed maintenance window every month, how do sites arrange their own maintenance plans

The upstream fixes the release of the secure version on the same day of each month, so the site should also fix the maintenance plan to a monthly window: one week before the window, do a checklist check and backup drill, on the day of the window, only handle the hits and make changes to the features that are not convenient, after the window, revalidate the version, cache and response headers and leave a record. The content scheduling uses timed publishing to avoid the window period, and the recovery speed is determined by the deployment method, the rollback cost difference between Docker and panel deployment is an order of magnitude.

2026-11-01

The patch says the problem has been fixed but it's still there, why do we need to patch it again?

The first patch not fixed cleanly is the norm rather than the exception: the upstream will issue a follow-up announcement for the same defect again, indicating that the fix only covers part of the code path or exposed surface. After applying the patch, it is still necessary to verify four things - whether the version is really in the fixed range, whether the page cache still contains old content, whether the response header still exposes objects that should not be cached, and whether the rollback point is still there. The cost of verification is far lower than that of a second vulnerability being exploited, and it is also safer than blindly applying another patch.

2026-11-01

After a year, there are more than 50,000 records of vulnerabilities accumulated, and the site should be handled in what order.

The five-plus records in the vulnerability library, accumulated over the years and covering the total amount of the plugin ecosystem, are not equal to the to-do list on this site. The processing order is divided into three steps: first, reduce the component list to the entries truly related to this site, then classify according to whether an account is needed and whether it can be triggered remotely, and finally decide which one to move first by using the backup and rollback capabilities. The total amount of the library reviewed on the day and the impact range of the announcement of the content module can all be reordered according to this order, rather than following the item time sequence one by one.

2026-11-01

Can adding data to the content improve the proportion of what the AI can see?

Adding data to the content indeed improves the visibility to AI, the amount reviewed on the same day is that the AI visibility increases by about 41% after the addition of statistical data. The premise is that the data must be accompanied by scope, time, and source, and it should fall within the conclusion section. The writing that can be extracted independently is: the conclusion at the beginning, followed by a sentence with the subject number and source, and then using a comparison table to reveal the differences, so that the title and description can be understood without relying on the text.

2026-11-01

Where does the difference lie in a self-built program that can run with 1GB of memory and 256MB?

The difference in memory threshold of self-built programs mainly comes from the running mode rather than the number of functions: the stack of resident application servers and databases consumes more memory than the combination of single-process running and lightweight storage. The criteria reviewed that day clearly divides the two types of thresholds, and the selection should be judged by three factors: concurrency, whether multiple sites are shared, and whether expansion is necessary, rather than ticking off the feature list. Memory usage belongs to the official approximate criterion and cannot be taken as an exact multiple.

2026-11-01

When connecting a large model, should it be done using a third-party module or the built-in capability, and where do the risks differ?

The risks of the two routes differ in who holds the key and permissions, and whether the entry point of the capability is controlled. The third-party module packages the model key, write permissions, and call links into the extension, and needs to be upgraded in bulk once the upstream issues an announcement; the built-in capability converges the entry point within the program, and can set the exposure range by domain and perform operation approval by round. The selection should consider the density of announcements and the boundary of permissions, not just whether this feature exists.

2026-11-01

After AI capabilities entered CMS, why does the background also need to be managed as an attack surface?

The AI ability makes the background go from 'viewing content' to 'being able to act': one conversation can write libraries, change configurations, and adjust interfaces, making the login state and interface credentials high-value targets. The management method is to tighten three types of login-free interfaces separately, set exposure ranges according to ability domains, retain operation approvals, and pay attention to security changes at the version level. The two types of high-risk issues fixed in the current version exactly illustrate that the input on the backend side and the login tickets should be treated as attack surfaces.

2026-11-01

The total number of vulnerability libraries is increasing day by day, should the webmaster pay attention to the total amount or the increase?

The total number of responses is about whether the ecosystem is expanding or contracting, and the new responses are about whether there are any entries related to you today, both cannot be mutually exclusive. The executable approach is to filter the newly added entries using the component list, leaving only those related to this site and versions within the affected range, and then arrange them in order of whether they can be triggered anonymously. The list check can be exported in bulk via an interface, and there is no need to manually flip through pages.

2026-11-01