Two weeks after a headline release is my favorite moment in a WordPress cycle. The launch adrenaline has worn off, the release notes have stopped being retweeted, and now the real signal starts arriving: what actually broke, what almost broke, what only breaks on Tuesdays in Firefox on RTL sites. This is when the boring, load-bearing work of running a CMS begins.
WordPress 7.1 “Mary Lou” shipped from WordCamp US Phoenix on August 19, 2026 with a genuinely large surface area — over eight hundred contributors, more than fifteen hundred enhancements and fixes, responsive styling, a persistent admin bar, browser-based image processing, Playlist and Tabs blocks, and the Icons API. Two weeks in the wild is enough for regressions to surface but not enough for the ones hiding in the edges. That is what a maintenance release exists to catch.
Today, September 2, the core team put the 7.1.1 schedule on the wall. The dates matter for anything you have planned on a 7.1 site between now and mid-September.
What is actually new
On September 2, 2026, Adam Silverstein published the WordPress 7.1.1 release schedule on Make/Core. The release is co-led by Adam Silverstein, Adrian Duffell, and Andra Ganescu. Three co-leads on a dot release tells you the same thing four co-leads told us on 7.0.1 back in June: triage will be aggressive and the ship date is not negotiable.
The calendar, straight from the announcement:
- Thursday, September 3, 2026 at 14:00 UTC — Bug scrub
- Friday, September 4, 2026 at 14:00 UTC — Bug scrub
- Tuesday, September 8, 2026 at 20:00 UTC — Bug scrub, and the 7.1.2 milestone opens (anything not landing in 7.1.1 queues for the next dot)
- Wednesday, September 9, 2026 at 10:00 UTC — Bug scrub
- Thursday, September 10, 2026 at 17:30 UTC — Release Candidate 1
- Tuesday, September 15, 2026 at 14:00 UTC — Bug scrub
- Thursday, September 17, 2026 at 15:00 UTC — General release
The scope is deliberately narrow. Per the announcement, 7.1.1 is “intended as a bug-fix only” release, limited to issues introduced during the 7.1 cycle or intentionally deferred at its conclusion. No new features. No enhancements. No performance refactors. If your favorite long-standing papercut is not a 7.1-era regression, it does not ride this train.
Context on what 7.1 actually changed helps predict what kind of regressions are likely to be in that queue. Per the official “Mary Lou” release announcement, 7.1 shipped responsive styling across the Site Editor, the always-on admin bar across every editor, a consolidated media editor, collaborative Notes with rich text and @mentions, browser-based image processing on WebAssembly, native AVIF and HEIC with HDR gain maps, Playlist and Tabs blocks, and a public Icons API. The post editor is now fully iframed on every theme. That is the surface being scrubbed right now, and it is the surface where regressions will emerge over the next fortnight.
The team opens the 7.1.2 milestone on September 8, which is the polite way of saying they already expect a second dot. If you have reported a 7.1 regression that does not make the September 17 cut, that is where it goes. The live queue is on Trac report 4, and the 7.1.x editor tasks board is tracked on GitHub. Bug scrubs happen in the #core Slack channel; release coordination is in the 7.1 Release Leads channel.
One timing detail worth flagging: WooCommerce 11.1 shipped yesterday, September 1, with a large block-registration performance change that alters how the plugin boots in cron, REST, and Store API contexts. A meaningful share of 7.1 sites is also running 11.1, and 7.1.1 lands in the exact window when 11.1 telemetry from your fleet starts being trustworthy. Two moving parts in the same three-week window means it matters where you stand each one up.
Why it matters for WordPress / WooCommerce people
If you have already rolled 7.1 across client sites, September 17 is when you can expect the first wave of “oh, that fixes it” emails. The Notes feature, the persistent admin bar, browser-based media processing, the iframed post editor on every theme, and the new responsive controls are exactly the kind of surface where regressions hide in edge cases. RTL admin. Custom blocks that rendered fine in 7.0. REST consumers that did not expect the new response shapes on media endpoints. Themes that assumed the editor was still using the document body. Bug-fix dot releases are where those quietly land.
If you have not moved to 7.1 yet — and there are plenty of agency clients still sitting on 7.0.4 — 7.1.1 is the version to standardize on, not 7.1. We wait for the first dot before rolling a major across the fleet. The pattern has held for years. Nothing in 7.1 changes it, and honestly the “Mary Lou” surface area is exactly the kind of release where waiting one dot pays for itself in a single Monday morning.
For WooCommerce builds the calendar is tighter than usual. WooCommerce 11.1 is now GA with the block-registration guard, native variation galleries out of the extension via Additional Variation Images integration, and the EU Order Withdrawal flow. WooCommerce 11.2 is already in developer preview with product lifecycle hook rewrites. If your stack is 7.1 plus 11.1, September 17 lands a WordPress dot on a stack that just took a Woo major two weeks ago. Test the combination on staging before the core update — not after.
For hosts, dot releases are the moment when auto-update telemetry actually says something honest. On a major, “X% of sites updated within 24 hours” is half-noise because cautious admins are holding back on purpose. On a dot release, the same percentage tells you something real about your update plumbing and the confidence your customers have in it.
What I would do (or not do) about it
Three moves for the next two weeks.
First, audit your 7.1 fleet this week and tag every site with a readiness state: “auto-updates on, ride 7.1.1”, “manual update window scheduled September 17 or 18”, “blocked by plugin X, needs vendor patch first”. You want that list closed before September 17, not on September 17. If a vendor plugin still flags a 7.1 incompatibility, file the bug now and check whether it is already on the 7.1.1 milestone via Trac report 4.
Second, if you reported a 7.1 regression that has not been triaged, push it now. Bug scrubs happen September 3, 4, 8, 9 and 15 — that is when triagers are actively reading comments. A reproducible test case in a PR or a Playground blueprint converts faster than a paragraph of prose. Working demos beat write-ups every time. I learned this the hard way back in the Macromedia Director days: a ten-line Lingo script that reproduced the crash got triaged in an afternoon, a two-page bug report sat in the queue for months.
Third, do not stack your own deployments on September 17 or 18. We block client release windows for two business days after every WP dot release. Not because dot releases are dangerous — they are usually the safest releases of the cycle — but because when something needs investigating, you want clean attribution. A change that ships the same day as a core update inherits the blame for anything that goes sideways, fairly or not.
One thing I would not do: skip 7.1.1 in the hope of standardizing on some future 7.1.3 that lines up more cleanly with 7.2 planning. 7.2 planning is already open on Make/Core. The gap between 7.1.1 and any future 7.2 will be measured in months, not weeks, and every month you sit on a first-dot regression is a month you are paying a tax you did not need to pay. Take the boring win.
Dot releases are not glamorous. They are the part of the maturity curve most CMS pretenders never reach. Mark September 17 in the calendar and run the quiet play.
Last modified: September 2, 2026
United States / English 
Slovensko / Slovenčina 
Canada / Français 
Türkiye / Türkçe