In short and in plain language
WordPress will soon get a big new version. It is called 7.2. It is due on 8 December. That is right in the busy Christmas weeks.
Some shops install new versions by themselves. In December that can cause trouble. Check how your shop is set up before then.
Test the new version on a copy of your shop first. Put it into the real shop only after the holidays.
Updates that fix security holes are different. Install them right away. Even in December.
We can help with this. We test the new version first. We install it when you say yes.
WordPress 7.2 is scheduled for 8 December 2026 (Make WordPress Core) as the last major release of the year. For a shop running on WordPress, that date lands in the middle of the two months that account for 18.5 percent of annual retail revenue (HDE), just days after Black Friday and Cyber Monday. Beta 1 is planned for 20 October, seven weeks before release. That is enough time to test the update calmly on a test copy, provided someone starts now. This article shows how to find out whether your shop will update itself on 8 December, what a test from Beta 1 onwards looks like, and why security updates and the major release are two separate decisions in December. It ends with a plan that runs into January.
Key takeaways
- WordPress 7.2 is scheduled for 8 December 2026 (Make WordPress Core), with Beta 1 on 20 October and RC1 on 17 November. The date falls in the months that account for 18.5 percent of annual retail revenue (HDE).
- Since WordPress 5.6, fresh installations update to major releases by default (WordPress Developer Resources). The dashboard setting, the WP_AUTO_UPDATE_CORE constant and any hosting-panel automation need checking before 8 December.
- Betas and release candidates belong on a staging copy, not in the live shop: test checkout with every payment method, shipping, order emails and custom extensions from 20 October, and repeat with RC1 on 17 November.
- Decide on security updates and the major update separately: apply security releases such as 7.1.3 with 7 security fixes (WordPress.org News) right away, test 7.2 before 8 December and take it live only after the peak.
- The plan runs into January: roll out 7.2 in a maintenance window with a fresh backup, not in the same week as the PHP upgrade, and record the deferral with its reason, as BSI IT-Grundschutz requires for patches that are not applied.
What is planned for WordPress 7.2
The core team keeps the schedule on a dedicated project page. Beta 1 is planned for 20 October 2026 (Make WordPress Core). Betas 2 to 4 follow weekly on 27 October, 3 November and 10 November (Make WordPress Core). The first release candidate is due on 17 November, together with the Field Guide that collects all developer notes for the version (Make WordPress Core). Two more release candidates are scheduled for 24 November (Make WordPress Core) and 1 December 2026 (Make WordPress Core), followed by a dry run with a 24-hour code freeze on 7 December (Make WordPress Core). WordPress 7.2 is due to be released the day after.
The same page states that 7.2 will be the final major release of 2026 (Make WordPress Core). The planning proposal from December 2025 set out a return to three major releases in 2026, roughly one every four months (Make WordPress Project). 7.0 and 7.1 have shipped, and 7.2 completes the set. For a shop maintenance plan, this translates into the following phases:
| Date (planned) | Stage | What the shop does in this phase |
|---|---|---|
| 20 October | Beta 1 | Move the staging copy to the beta and test the core shop flows |
| 27 October to 10 November | Beta 2 to Beta 4 | Retest the issues found and collect feedback from extension vendors |
| 17 November | RC1 with Field Guide | Read the developer notes and repeat the full test run on the release candidate |
| 24 November | RC2 | Finalise the approval list and decide on the auto-update setting |
| 27 to 30 November | Black Friday to Cyber Monday | No changes apart from security updates, on-call cover in place |
| 1 and 7 December | RC3 and dry run | Collect the last extension updates, take nothing live |
| 8 December | Release 7.2 | Move staging to the final version, the live shop stays on 7.1.x |
| January 2027 | after the peak | Roll out 7.2 in a maintenance window with a fresh backup |
Why the date sits so late in the year is explained in the planning proposal itself: the 7.2 date is the least flexible of the three, because earlier dates collide with Black Friday, Cyber Monday and Giving Tuesday, while later dates get too close to the major holidays and the end-of-year break (Make WordPress Project). So the project deliberately avoids the sale days, but not the Christmas trading season as a whole. This is nothing new: WordPress 6.9 was released on 2 December 2025 (WordPress.org Releases), one day after Cyber Monday, which fell on 1 December in 2025 (HDE).
All of these dates are planned, not promised. This year shows how far plan and release can drift apart. The proposal named 9 April for WordPress 7.0 (Make WordPress Project), and 7.0 actually shipped on 20 May 2026 (WordPress.org Releases). WordPress 7.1, by contrast, arrived as planned on 19 August 2026 (WordPress.org Releases). A maintenance plan anchored to 8 December therefore needs buffer, and someone who follows the schedule up to release and adjusts the shop's own dates if anything moves.
Why the date falls in the middle of the peak
November and December carry the most weight in retail. According to the German retail federation, 18.5 percent of annual retail revenue falls in the last two months of the year (HDE). For online retail, the federation forecast Christmas-season revenue of 22.2 billion euros for 2025 (HDE). For the two sale days, Black Friday and Cyber Monday, it expected revenue of 5.8 billion euros in 2025 (HDE). In these weeks, any checkout disruption costs more than it would in February, and it hits a team that is already stretched by orders, shipping and customer enquiries. How to set up a change freeze for this period is described in Change freeze before the peak season: the maintenance plan.
A major update is exactly the kind of change that gets in the way during this phase. Major releases bring new features, editor changes and new programming interfaces; maintenance releases fix bugs and security issues. The WordPress plugin directory draws its own conclusion from this: the readme field stating which version an extension was tested against ignores minor versions, because extensions should not break with a minor update (WordPress Plugin Handbook). Put the other way round: if an extension breaks, it is mostly at a major release. In a shop, that covers not only the shop extension itself but also payment and shipping integrations, invoicing and legal-text modules, filters, search and the theme.
On top of that, a major release keeps moving until shortly before the date. For 7.1, the project reported more than 145 updates and fixes in the first release candidate since Beta 4 alone (WordPress.org News). Anyone who tests the beta in October and not again afterwards has checked a version that will not ship in that form. Testing is therefore not a single appointment but a series that ends with the release candidate.
The rule for December
Will 7.2 arrive on its own?
Whether a shop jumps to 7.2 without anyone acting on 8 December depends on how it was installed and what has been configured since. Automatic background updates have existed since WordPress 3.7 (WordPress Developer Resources). For a long time they covered only maintenance and security releases. Since WordPress 5.6, fresh installations update to new major releases by default as well, unless WordPress detects a version control checkout (WordPress Developer Resources). Older installations keep their previous behaviour until someone enables automatic major updates in the dashboard, through a constant or with a filter (WordPress Developer Resources).
For a shop this means: if the installation was set up fresh in recent years, or if someone switched on automatic updates for all new versions under "Updates" in the dashboard, 7.2 can arrive without any further action as soon as it is rolled out. The major update then runs in mid-December, untested on staging and with nobody standing by.
Two more places are invisible in the dashboard. The WP_AUTO_UPDATE_CORE constant in wp-config.php overrides the setting administrators choose on the Updates screen (WordPress Developer Resources). And the control panels of some hosting providers bring their own WordPress update automation, configured outside WordPress (WordPress Developer Resources). Who applies which updates should therefore also be settled in the hosting contract; the split is described in Hosting provider or maintenance: who patches what. On the command line, a few WP-CLI commands capture the current state:
# Installed version and available core updates
wp core version
wp core check-update
# Is the constant set? An error message means: not set
wp config get WP_AUTO_UPDATE_CORE
# Plugins and themes with an available update
wp plugin list --update=available
wp theme list --update=availableFor the peak season, a deliberate setting beats a forgotten checkbox. The value minor allows core maintenance and security releases automatically and switches major releases off; true allows all updates, false none (WordPress Developer Resources). With minor, core keeps receiving its security fixes without delay while 7.2 waits for approval:
// Maintenance and security releases automatically,
// major releases only after testing and approval
define( 'WP_AUTO_UPDATE_CORE', 'minor' );If you prefer to apply minor updates in a controlled way as well, as some maintenance contracts provide, you need a fixed fast track with a defined response time. Otherwise December opens exactly the gap the automation is meant to close. BSI IT-Grundschutz explicitly requires defining how auto-update mechanisms are to be handled (BSI IT-Grundschutz). A setting that nobody chose deliberately does not meet that requirement.
Without a dedicated setting, WordPress updates plugins and themes automatically only in special cases, namely when the security team triggers an update through the WordPress.org API for a critical vulnerability (WordPress Developer Resources). Anyone who switches off all plugin updates with a filter also blocks these forced security updates, according to the documentation (WordPress Developer Resources). For December, that is the wrong direction.
Since WordPress 6.6, core rolls back an automatic plugin update if it triggers a fatal PHP error (Make WordPress Core). The error is detected with a request to the site's own homepage (Make WordPress Core). That protects against a white screen, but not against a checkout that loses a payment method, wrongly calculated shipping costs or order emails that stop arriving. Only a test that actually runs through the shop's flows finds errors like these; what that looks like in practice is covered in Update testing: avoiding regressions after shop updates.
Test Beta 1 on staging, not live
For betas and release candidates, the project is clear: they should not be installed, run or tested on production or mission-critical websites (WordPress.org News). The right place is a staging copy that matches the live shop in PHP version, extensions, theme and data. How to build such an environment, and why the database copy should be anonymised, is explained in Staging environments for safe shop updates.
The test is not about the homepage, it is about the path the money takes. On the beta, at least these flows should run through once from start to finish:
- Cart and checkout through to the order confirmation, with every payment method offered, including the payment provider's callback to the shop
- Shipping cost calculation, tax display and vouchers, including delivery countries outside Germany
- Customer account: registration, login, password reset and order history
- Order, shipping and invoice emails, plus generated documents such as PDF invoices
- Product pages, filters and search, especially pages with custom blocks or theme templates
- Order processing in the back end and the interfaces to inventory management, shipping and accounting
- Scheduled tasks such as stock synchronisation, product feeds and reminder emails
Custom extensions need the most attention. An extension from the plugin directory is tested alongside you by many site owners and by its vendor; an extension built specifically for your shop is tested by nobody but you. If it registers its own blocks, hooks into the editor or relies on internal core functions, the risk rises. With RC1, the project publishes the Field Guide with all developer notes for the version (Make WordPress Core). It is the list to check custom extensions against before the final version ships.
For third-party extensions, the readme field "Tested up to" is the public signal. With the first release candidate, the project asks developers to conclude their testing and set this field to the new version (WordPress.org News). The plugin directory shows a notice when an extension does not support the last three major releases (WordPress Plugin Handbook). Under this rule, once 7.2 is out, that applies to every extension whose readme names 6.9 or lower. Such an extension is not automatically broken, but it belongs on the list of questions for the vendor before the major update. For paid extensions, updates also often depend on a valid licence; how to sort that out before the peak is described in Extension licence expiry: keeping shop updates flowing.
A green beta test is not an approval
Decide on major and security updates separately
In December, two kinds of updates run side by side. Major releases such as 7.2 ship on a schedule; maintenance and security releases ship whenever a vulnerability needs closing. Since 7.1 came out, three such releases arrived by early October: 7.1.1 on 17 September, 7.1.2 on 22 September and 7.1.3 on 6 October 2026 (WordPress.org Releases). 7.1.2 fixed a critical security vulnerability (WordPress.org News), and 7.1.3 brought 7 security fixes and 4 bug fixes (WordPress.org News). For security releases, the project recommends that you update your sites immediately (WordPress.org News).
That leads to a simple split. A security update for core or an extension does not wait for the peak season to end, not even during Black Week. BSI IT-Grundschutz states the principle plainly: patches should be applied promptly after release (BSI IT-Grundschutz). How short the window between disclosure of a vulnerability and the first attacks can be is shown in our article on the patch window for WordPress vulnerabilities. A major update, on the other hand, is a planned change with new features. For planned changes, the same module requires taking the current situation of the affected business processes into account (BSI IT-Grundschutz), and the Christmas trading season is exactly such a situation.
| Update | Example | In December | Reason |
|---|---|---|---|
| Core security release | 7.1.x, after 8 December also 7.2.x | right away, via the fast track if needed | closes known vulnerabilities, the project recommends updating immediately |
| Security update of an extension | fix for a reported vulnerability | right away, after a short checkout and payment test | attacks on known vulnerabilities do not wait until January |
| Maintenance release without security relevance | bug fixes only | after assessment, in a maintenance window | weigh benefit and risk per fixed bug |
| Core major release | WordPress 7.2 | test yes, roll out after the peak | new features and interfaces, risk for extensions |
| Feature update of an extension | new version with new features | after the peak | changes flows without security benefit |
Deferring 7.2 on purpose is a decision that needs to be recorded. IT-Grundschutz requires that when a patch is not applied, the decision and the reasons for it are documented (BSI IT-Grundschutz). One line in the maintenance plan is enough: version, reason, date to catch up, responsible person. How we prioritise and apply security updates by severity is described on the security updates page.
What if a fix only ships for 7.2?
Only the most recent WordPress version is officially actively supported (WordPress.org News). So far, security fixes have also been passed to older branches as a courtesy, currently back to 4.7 (WordPress.org News), with no commitment for the next vulnerability. How this works in detail is covered in WordPress security updates: what older branches still get. For December this means: a few weeks on 7.1.x are justifiable, as long as every 7.1 security release is applied right away. If a fix ships only for 7.2, the test before 8 December is the safeguard. A tested 7.2 is then ready, and the switch becomes a planned fast track rather than a leap in the dark.
The plan through January
By 19 October: take stock
Record the installed version, the auto-update setting in the dashboard, the constant in wp-config.php and the hosting provider's automation. Build a list of all extensions with version, "Tested up to" and licence status, and flag custom developments.
20 October to 10 November: beta on staging
Move the staging copy to Beta 1 and run through the core shop flows. Report bugs to the vendors and retest with every further beta.
17 November to 1 December: release candidate
Read the Field Guide, check custom extensions against it and repeat the full test run on the release candidate. At the latest now, suspend automatic major updates until approval.
27 to 30 November: sale days
Only security updates via the fast track, no other changes. On-call cover, contacts and the way back are settled.
8 December: watch the release
Move the staging copy to the final 7.2 and run a short test. The live shop stays on 7.1.x and receives its security releases right away.
January: roll out and reset
Roll out 7.2 in a maintenance window with a fresh backup and a rehearsed way back. Then reset the auto-update setting to normal operation and close the entry in the maintenance plan.
Record the installed version, the auto-update setting in the dashboard, the constant in wp-config.php and the hosting provider's automation. Build a list of all extensions with version, "Tested up to" and licence status, and flag custom developments.
Move the staging copy to Beta 1 and run through the core shop flows. Report bugs to the vendors and retest with every further beta.
Read the Field Guide, check custom extensions against it and repeat the full test run on the release candidate. At the latest now, suspend automatic major updates until approval.
Only security updates via the fast track, no other changes. On-call cover, contacts and the way back are settled.
Move the staging copy to the final 7.2 and run a short test. The live shop stays on 7.1.x and receives its security releases right away.
Roll out 7.2 in a maintenance window with a fresh backup and a rehearsed way back. Then reset the auto-update setting to normal operation and close the entry in the maintenance plan.
When exactly "after the peak" is depends on the product range. For many shops it does not end on 24 December: voucher redemptions, exchanges and returns run on into January. A sensible date is one when the shop is usually quiet and the team is reachable. How to find it and put the shop correctly into maintenance mode in the meantime is described in Maintenance windows: shop updates without revenue loss.
A second date belongs in the same calendar. Security support for PHP 8.2 ends on 31 December 2026 (The PHP Group). If your shop still runs on 8.2, January brings two major changes. Putting both into the same maintenance window makes troubleshooting needlessly hard: if something breaks afterwards, it is unclear whether PHP or WordPress is the cause. A sequence with some distance between the steps is better, as described in PHP EOL management: planning safe upgrades.
Before the rollout comes a fresh, verified backup of files and database. WordPress offers no way back to the previous major version in the dashboard; the reliable way back is the backup, and specifically one whose restore has been rehearsed beforehand. How backups are set up, stored encrypted and restored regularly is described on our backup service page.
What this means for maintenance and on-call cover
The decisions in this article cannot be made once and then forgotten. The auto-update setting is changed before the release and reset in January, security releases may need applying on a weekend in December, and the test run repeats with every beta. This is work for a fixed maintenance plan with clear responsibility, not for the moment the update notice appears in the dashboard. BSI IT-Grundschutz also requires a defined procedure for fast-tracking important changes (BSI IT-Grundschutz). In December, that is the fast track for security fixes.
In our WordPress maintenance, we distinguish between minor updates carrying security fixes and major updates carrying new features, and treat them differently: we apply security fixes promptly, and we check every update on a staging copy first. We typically replace automatic updates with controlled, tested updates in defined maintenance cycles. For December, that means in practice: we check 7.2 on a staging copy of your shop before the rollout, including checkout, payment and search, and the rollout happens after your approval in an agreed maintenance window. Response times for the fast track are set out in the SLA maintenance contract, and our monitoring keeps watch over availability and business-critical functions such as the checkout.
Related Articles
Shop Server Logs: How Long IP Addresses May Be Stored
How long may IP addresses stay in server logs? What the GDPR requires, what the five weeks from the BfDI mean, and how rotation, truncation and backups fit in.
WordPress security updates: what old branches still get
WordPress 7.1.2 closed a critical flaw and the fix was backported to 4.7 as a courtesy. What older branches receive, what they do not, and when to move up.
Discount codes in Black Week: detecting abuse early
Discount codes in Black Week: code length, a rate limit at the coupon field, alerts on failed attempts and new-customer discounts that resist multiple accounts.