The release week of Drupal12 has been written into the official schedule, whether the site schedule should be moved up to reserve a window

📅 2026-11-01 👁️ 0

Needed. The release schedule of open source projects is predictable, the Drupal official core release rhythm page has already specified the next major version to be in the week of December 2026, and the same page also lists the nodes where some branches will end security support. The established schedule means that the upgrade window can be scheduled in advance in the annual maintenance schedule, rather than handling it temporarily on the day of the announcement.

What the official schedule can tell the site

The release rhythm page provides two types of information: the time points of the main version and the deadline for security support of each branch. The former is used to arrange pre-release and human resources, and the latter is used to determine which sites must complete follow-up within this period. It does not tell you how much the compatibility cost is, nor does it decide whether to follow up for you, but it is enough to change 'passive response' to 'scheduling treatment'.

Conversely, it is common to treat the schedule as a basis for no action. The time point is the release, not the completion of migration by your site, and there are still two stages of regression test and data inspection in the middle.

How to allocate windows for the three scheduling methods

Type Trigger method It is recommended to reserve time Major Action
Major Version Upgrade Official Schedule Announcement Estimate feasibility based on page type and custom code amount, do feasibility verification first Full regression in pre-release environment, template and field verification
Minor Version Update Release with new features One workday plus one round of regression Pay attention to whether the new default behavior affects existing content
Security repair According to the rhythm of announcements, usually announce the time window in advance Complete within the announcement window Backup, upgrade, verify, file

The major version is the project scheduling, the security repair is the value class action, both mixed in the same table are easy to miss the latter. Security announcements usually specify the release time window, the site should reserve the maintenance period according to that window, rather than assume that it can be temporarily inserted during the business low season.

Three things before clearing the window

  1. Rollbackable backup. The scope should include the database and static files, only the recovery exercise of the backup library will expose the problem when the image is lost; after the backup is completed, perform a real recovery, not just confirm that the files exist.
  2. Independent pre-release environment. It is used to verify templates, fields and interface calls, and is meaningful only with the same version and configuration as production. Deploying a copy of the site using Docker images is fast, and for panel one-click deployment, it needs to be confirmed that the environment can be copied.
  3. Content freeze period. New content added during the upgrade is likely to fall between two sets of structures, so the release action should be switched to pending release status, wait for verification to pass before unified launch, which is cheaper than after-the-fact repairs.

The third point is often ignored. On the day of the upgrade, if there are still some people writing new articles on the site, when rolling back, it is necessary to decide whether these contents are to be retained or redone, and it is more convenient to freeze in advance than to make an on-the-spot judgment.

On the day of the upgrade and after.

Follow these four steps: First, confirm that the backup is available; then upgrade the running environment and the program itself; next, verify the list page, detail page, form submission, and backend login one by one; finally, record the version number, time taken, and any issues encountered in the site ledger.

The credential processing should be completed on the same day. For example, version v3.6.6 fixed two high-risk issues of SQL injection in list sorting parameters and login credentials being forged during site switching, the upgrade recommendation also requires the rotation of site signature keys and the modification of the administrator password; only upgrading the program without moving the credentials is equivalent to leaving the path that can be forged intact. Similarly, after the change of the one-time ticket mechanism, it needs to be confirmed whether the old session is still valid.

Write the version follow-up into the annual maintenance table

Three lines are enough: schedule line (known main version release weeks and security support deadlines), responsible person line (who allocates windows, who performs verification), and inspection line (confirm backup recoverability every quarter, pre-release environment still in place). The value of the maintenance table lies in being able to immediately know which site to move when a security notice comes, rather than looking for the responsible person at a moment's notice.

Common questions

Question: Can we wait for the large version to stabilize before following?Answer: Yes, but it is necessary to distinguish between major versions and security fixes. Postponing the major version is a strategy, while postponing the security fix is a risk exposure. Both should not be written into the same decision.

Question: Must the pre-release environment have the same configuration as the production environment?Answer: Try to keep the same version and configuration, otherwise the verification conclusion is unreliable. At least ensure that the runtime version, database type, and program version are consistent.

Question: How to handle the worst-case scenario of upgrade failure?Answer: Go back to the backup point before the upgrade. That's why the backup should be done before the upgrade and should be verified for recoverability before the window, as temporary backups often do not have time to be verified.

Related articles

The self-hosted CMS on the selection list requires PHP 8.4 to start, how to check each environmental dependency item by item?

The environment dependencies of self-hosted CMS need to be divided into four columns: language runtime, framework version, database, and optional extensions for item-by-item verification. Then, consider the upgrade window and dependency conflicts brought by the major runtime version. When the system in the list requires PHP 8.4 as the starting point, it means that the existing host needs to change the PHP version; in comparison, the GoLang single binary deployment has fewer host-side dependencies, with the default port and reverse proxy being the main verification items. It's more convenient to fill out the table before buying the host than to supplement the environment after deployment.

2026-11-01

The official migration list lists the theme styles as items that cannot be taken away. Should the template be redone?

The migration list puts the theme style as an item that cannot be taken away, which does not mean that the template must be rewritten from scratch. The judgment sequence is to first list the content and fields that can be taken away, and then estimate the working hours according to the number of page types, field structure, and special components: the text and media go through batch import, the field structure is supported by the content model, and the style layer is remade according to the template rules of the new system. Before making changes, make a backup of the template and static files, keep a rollback point, and then preview each page with a draft to check.

2026-11-01

The hosting platform puts invoicing and email marketing in the low-price tier, where should these items be supplemented for the self-built official website?

The hosting platform built invoicing and mass email sending in the low-price tier, for self-built websites, you need to supplement three links: order management and financial reconciliation, email reminders and email subscriptions, and public account docking and member grouping. Distinguish which modules are built-in in the background, which require external services, and which rely on interfaces and AI tools to fill in the gaps, and then take the notification frequency, unsubscribe entry, and form anti-robot measures as acceptance items before going online, and find functions closer to the actual workload according to the package tier.

2026-11-01

List the differences on the official comparison page of the website building platform, can self-built sites be verified by themselves?

The official comparison page of the hosting platform lists the features of two companies side by side, and self-built sites can convert the verifiable items into practical tests: check whether the price items include domain names and transaction fees, measure memory and concurrent carrying capacity with the same load口径, and see if the backup recovery and data export can run through as a set. Convert subjective items into

2026-11-01

Open-source website building tools have written order callback and login modification into the new version, can the corporate website use it?

The open-source website building tool incorporates order callback, registration login modification, and AI expansion into the new version, which may not be necessary for corporate websites. The criteria for judgment are data ownership and whether additional services need to be resident: orders and finance belong to business system integration, login and group permissions directly affect the back-end security boundary, and editor and template updates are the parts that the content team feels strongly about in daily life. Do not hang externally if it can be covered by built-in modules, and confirm the interface scope first if external system cooperation is needed.

2026-11-01

The announcement writes the authentication bypass and marks it as 9.8 points, should we stop this kind of temporary login function first?

Seeing the bypass of authentication with a high-risk score, it is not necessary to immediately shut down all at once, but it is necessary to first judge whether it is in use, whether it is accessible from the outside, and whether there is an alternative path. The attack surface of temporary login functions is in three points: who can apply, how long the validity period is, and whether it is protected by secondary verification. The disposal sequence is to collect the exposed range, concentrate on credential rotation, supplement session invalidation and log verification, and then decide on patches or shutdown, while confirming that the back-end authentication entry has anti-automation protection.

2026-11-01

The third-party vulnerability library can list entries by plugin name, should the plugins installed on the site be checked individually?

Public vulnerability library organized by component name and version entries, the premise of site verification is to have a component ledger first. This article provides the minimum information of the ledger, the verification order based on external accessibility priority, and the differences between the two types of disposal actions with official patches and those without official patches, and explains why the system's built-in injection filtering and content audit layer cannot replace this investigation.

2026-11-01

More than half of the references in AI answers come from natural ranking, is it still worth making a separate plan for keyword positions?

BrightEdge's continuous tracking of AI Overview references for 16 months shows that the proportion of overlapping pages with natural ranking has increased from 32.3% to 54.5%, with a relative increase of 69%. More than half of the references were originally from the top positions of natural ranking, so the keyword position plan is still a basic investment; GEO is responsible for writing content that can be cited independently, both sides use the same set of content assets, and it is not recommended to transfer the budget from one side to the other as a whole.

2026-11-01