WordPress 7.0.1 Release Schedule: Bug-Fix Plan for July 9

The scope is narrow on purpose. From the announcement: “WordPress 7.0.1 is intended as a bugfix only maintenance release. Tickets will be included provided they are issues introduced during the 7.0 cycle or intentionally deferred at the end of the 7.0 cycle.” Translation: no new features, no enhancements, no performance refactors. If your favorite long-standing papercut is not a 7.0-introduced regression, it will not ride along.

Important context for what 7.0 actually changed and therefore what kind of bugs are likely to surface: per the official WordPress 7.0 Field Guide, the release shipped the new AI Client and Connectors screen, the Modern color scheme, the Command Palette, an iframed post editor, visual revisions, responsive block visibility, PHP-only block registration, Block Bindings pattern overrides, and an expanded Interactivity API — on top of 419+ core tickets and a much larger pile in the editor and dashboard. That is the surface area being scrubbed right now.

The release schedule also opens the 7.0.2 milestone on June 25, which is the polite way of saying: the team already expects a second dot. If you have reported a 7.0-era bug, that is where it goes if it does not make the July 9 cut. You can follow the live list of fixes via Trac report 4 and the 7.0.x GitHub project board referenced in the announcement.

One more piece of timing nobody is talking about, but should: 7.1 beta 1 lands July 15 under the 7.1 roadmap and the 7.1 release squad announcement. That gives the project a six-day gap between shipping 7.0.1 and entering 7.1 beta. The squads are deliberately staggered, but the testing community is the same group of people, and they are going to be busy.

Why it matters for WordPress / WooCommerce people

If you have already updated client sites to 7.0, July 9 is when you can expect the first wave of “ah, that fixes the thing” emails. The Command Palette, the iframed editor, the new visual revisions UI and AI Connectors are exactly the kind of surface area where regressions hide in edge cases — RTL admin, custom blocks that rendered fine in 6.9, REST consumers that did not expect the new fields. Bug-fix dot releases are where those land.

If you have not updated to 7.0 yet — and there are plenty of agency clients still on 6.9.x — 7.0.1 is the version to standardize on, not 7.0. We typically wait for the first dot before rolling a major across the fleet. The pattern has held for years and there is no reason 7.0 will break it.

For WooCommerce builds the calendar gets tighter. WooCommerce 10.9 is in beta with native variation galleries, color swatches, the dual API and email template updates per the 10.9 beta post, and a 10.9 release falls in the same window as WordPress 7.0.1. If you run a stack with both, you want to test the combination before either ships, not after.

And for hosts: dot releases are the moment when auto-update telemetry actually means something. If you are reporting “X% of sites updated within 24 hours” on a major, the number is half-meaningless because it includes cautious admins waiting. On a 7.0.1, the number tells you something real about your update plumbing.

What I would do (or not do) about it

Three concrete moves for the next three weeks.

First, audit your 7.0 client list this week and tag every site with a release readiness state: “auto-updates on, ride 7.0.1”, “manual update window scheduled”, “blocked by plugin X, needs vendor patch first”. You want this list ready before July 9, not on July 9. If a vendor plugin still flags a 7.0 incompatibility, file the bug now and reference whether it is in the 7.0.1 milestone via Trac report 4.

Second, if you reported a 7.0 regression that has not been triaged, push it. Bug scrubs happen on June 23, 25 and 30. That is when triagers are actively reading new comments. A reproducible test case in a PR or a Playground blueprint converts faster than a paragraph of prose. The scrub calendar is in the schedule post; #core on Slack is where it happens.

Third, do not stack your own deployments on July 9 or July 10. 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 if something does need investigation, you want clean attribution. A change that ships the same day as a core update will get blamed for everything that goes wrong, fairly or not.

One thing I would not do: skip 7.0.1 and wait for 7.1 in August. 7.1 has a much larger surface area (React 19 returning behind a flag, AI Client streaming, Connectors auth expansion, Notes, three new blocks per the 7.1 roadmap). Going from 7.0 to 7.1 without sitting on 7.0.1 first means you carry the regressions of one and inherit the surface area of the other in the same upgrade. That is a worse risk profile, not a better one.

Dot releases are not glamorous. They are the part of the maturity curve that most CMS pretenders never get to. Mark July 9 in the calendar and run the boring play.

I have a soft spot for dot releases. They never make the headlines, they never trend on socials, and they almost always say more about a project’s maturity than the headline major they follow. You can see how seriously a team treats its users by how quickly and quietly they ship the first round of fixes after a big launch.

WordPress 7.0 went out the door on May 20, 2026 with a big surface area: AI Client, Connectors, Command Palette, an iframed editor, visual revisions, new blocks. Over four hundred Trac tickets in a single release. After a month in the wild, the inevitable list of small regressions and rough edges is now in the queue, and the team has put a schedule on the wall.

That schedule is what I want to walk through today, because the dates affect anything you have planned for the next three weeks on a 7.0 site.

What is actually new

On June 18, 2026, the WordPress core team published the 7.0.1 release schedule on Make/Core. The release is co-led by Carlos Bravo (@cbravobernal), Estela Rueda (@estelaris), Daniel Richards (@masteradhoc), and Aaron Jorbin (@jorbin). Four co-leads on a dot release is not nothing — it tells you the team intends to triage aggressively and ship on time.

The dates, taken straight from the post:

• June 18, 2026 — Bug Scrub (already happened)
• June 23, 2026 — Bug Scrub
• June 25, 2026 — Bug Scrub, and the 7.0.2 milestone opens (anything not landing in 7.0.1 starts queueing for the next dot)
• June 30, 2026 — Bug Scrub
• July 1, 2026 — Release Candidate 1
• July 7, 2026 — Bug Scrub
• July 9, 2026 — General Release

The scope is narrow on purpose. From the announcement: “WordPress 7.0.1 is intended as a bugfix only maintenance release. Tickets will be included provided they are issues introduced during the 7.0 cycle or intentionally deferred at the end of the 7.0 cycle.” Translation: no new features, no enhancements, no performance refactors. If your favorite long-standing papercut is not a 7.0-introduced regression, it will not ride along.

Important context for what 7.0 actually changed and therefore what kind of bugs are likely to surface: per the official WordPress 7.0 Field Guide, the release shipped the new AI Client and Connectors screen, the Modern color scheme, the Command Palette, an iframed post editor, visual revisions, responsive block visibility, PHP-only block registration, Block Bindings pattern overrides, and an expanded Interactivity API — on top of 419+ core tickets and a much larger pile in the editor and dashboard. That is the surface area being scrubbed right now.

The release schedule also opens the 7.0.2 milestone on June 25, which is the polite way of saying: the team already expects a second dot. If you have reported a 7.0-era bug, that is where it goes if it does not make the July 9 cut. You can follow the live list of fixes via Trac report 4 and the 7.0.x GitHub project board referenced in the announcement.

One more piece of timing nobody is talking about, but should: 7.1 beta 1 lands July 15 under the 7.1 roadmap and the 7.1 release squad announcement. That gives the project a six-day gap between shipping 7.0.1 and entering 7.1 beta. The squads are deliberately staggered, but the testing community is the same group of people, and they are going to be busy.

Why it matters for WordPress / WooCommerce people

If you have already updated client sites to 7.0, July 9 is when you can expect the first wave of “ah, that fixes the thing” emails. The Command Palette, the iframed editor, the new visual revisions UI and AI Connectors are exactly the kind of surface area where regressions hide in edge cases — RTL admin, custom blocks that rendered fine in 6.9, REST consumers that did not expect the new fields. Bug-fix dot releases are where those land.

If you have not updated to 7.0 yet — and there are plenty of agency clients still on 6.9.x — 7.0.1 is the version to standardize on, not 7.0. We typically wait for the first dot before rolling a major across the fleet. The pattern has held for years and there is no reason 7.0 will break it.

For WooCommerce builds the calendar gets tighter. WooCommerce 10.9 is in beta with native variation galleries, color swatches, the dual API and email template updates per the 10.9 beta post, and a 10.9 release falls in the same window as WordPress 7.0.1. If you run a stack with both, you want to test the combination before either ships, not after.

And for hosts: dot releases are the moment when auto-update telemetry actually means something. If you are reporting “X% of sites updated within 24 hours” on a major, the number is half-meaningless because it includes cautious admins waiting. On a 7.0.1, the number tells you something real about your update plumbing.

What I would do (or not do) about it

Three concrete moves for the next three weeks.

First, audit your 7.0 client list this week and tag every site with a release readiness state: “auto-updates on, ride 7.0.1”, “manual update window scheduled”, “blocked by plugin X, needs vendor patch first”. You want this list ready before July 9, not on July 9. If a vendor plugin still flags a 7.0 incompatibility, file the bug now and reference whether it is in the 7.0.1 milestone via Trac report 4.

Second, if you reported a 7.0 regression that has not been triaged, push it. Bug scrubs happen on June 23, 25 and 30. That is when triagers are actively reading new comments. A reproducible test case in a PR or a Playground blueprint converts faster than a paragraph of prose. The scrub calendar is in the schedule post; #core on Slack is where it happens.

Third, do not stack your own deployments on July 9 or July 10. 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 if something does need investigation, you want clean attribution. A change that ships the same day as a core update will get blamed for everything that goes wrong, fairly or not.

One thing I would not do: skip 7.0.1 and wait for 7.1 in August. 7.1 has a much larger surface area (React 19 returning behind a flag, AI Client streaming, Connectors auth expansion, Notes, three new blocks per the 7.1 roadmap). Going from 7.0 to 7.1 without sitting on 7.0.1 first means you carry the regressions of one and inherit the surface area of the other in the same upgrade. That is a worse risk profile, not a better one.

Dot releases are not glamorous. They are the part of the maturity curve that most CMS pretenders never get to. Mark July 9 in the calendar and run the boring play.

Related