WordPress 7.0 shipped on May 20, and the first 7.0 hotfix is already out. It just didn’t come from a WordPress release. The fix for a scrambled publish screen on non-block editors is being distributed through the Hotfix and Classic Editor plugins, while 7.0.1 itself waits for the middle or end of June. If you look after a pile of client sites, that detail matters more than any feature list, because the version number no longer tells you whether a site is patched.
What broke?
The problem is ticket #65286. In the core dev chat on May 27, Aaron Jorbin described it plainly, and the whole exchange is summarized on Make WordPress Core.
No actions are blocked, but the publishing screen on the non block editor looks extremely messy.
So nobody is stuck in the “I cannot publish” sense. The screen with the Publish button and the status box renders badly wherever the block editor is not in charge. That covers three groups of sites: the ones running the Classic Editor plugin, the ones that disable the block editor with a filter, and custom post types registered without block editor support. David Baumwald confirmed in the same chat that CPTs are hit even when the Classic Editor plugin isn’t installed, which ended the comfortable assumption that this only affects editor holdouts.
The report also came in through WP Rocket’s issue tracker, where a ticket was already open, so some of what you’ll see in the wild this month is third-party plugins absorbing a core regression. That’s normal and it works, but it means the same bug gets patched in more than one place.
Why fix it in plugins instead of 7.0.1?
Because 7.0.1 isn’t urgent enough. The summary says there are issues in the milestone but nothing that deserves an immediate release, and the current target is the middle or end of June, once a call for volunteers goes out. A messy screen that still lets you publish doesn’t justify pulling a maintenance release forward.
Install counts decided where the fix lives. Jonathan Desrosiers made the case for the Classic Editor plugin by reach: Classic Editor is active on more than 9 million sites, while the Hotfix plugin has around 4,000. One plugin update pushed through auto-updates repairs a lot of sites overnight. But Jb Audras flagged the gap, since a fix in Classic Editor does nothing for sites that disable the block editor with a hook or in CPT registration. So core shipped the fix in both plugins. The Hotfix plugin also got a featured spot in the directory so people can find it.
Which of my sites see the broken screen?
The direct test is to log in and open a post type that doesn’t use the block editor. If the publish box looks wrong, you have it. Across a roster of client sites, the faster check is to look at code, because the condition is always one of three things: the Classic Editor plugin, a use_block_editor_for_post filter, or a post type registered with show_in_rest set to false.
# Sites that turn the block editor off land on the old publish screen.
grep -rln --include="*.php" \
-e "use_block_editor_for_post" \
-e "'show_in_rest' => false" \
~/client-sites/*/wp-contentAnything the grep turns up is a site to check by hand. I’d start with the custom builds, since off-the-shelf themes rarely disable the editor on their own. (I haven’t tested this across multisite, but the same three conditions should apply network-wide.)
If you’d rather not audit the whole roster yourself, this is the sort of sweep I do for clients: find which sites run the old editor path, update the two plugins, and leave a short note about what changed. Get in touch and I’ll take the list.
Is the WordPress 7.0 hotfix in core yet?
No, and it won’t be until 7.0.1 lands in June. Until then, patched is a plugin question. The Hotfix plugin update went out the day after the chat, and the same fix is planned for a Classic Editor update, so on any given site you check two things instead of one: the WordPress version, and the versions of those two plugins. Sites without Classic Editor can install Hotfix and get the same repair. Across a fleet, wp plugin update hotfix classic-editor does it in one pass.
Check the auto-update settings while you’re in there. The whole distribution plan leans on plugin auto-updates, and plenty of client sites have them switched off, so those sites will sit on the broken screen until someone visits manually. I wrote more about what auto-updates at scale mean for the sites you run if you want the longer version, and there’s a plugin-by-plugin breakdown in my earlier post on which hotfix to install for WordPress 7.0.
On a client site this week I’d work in this order: confirm where the block editor is disabled, update Hotfix and Classic Editor wherever they’re installed, then turn on auto-updates for those two plugins. The bug is cosmetic and nothing is blocked, but it sits on the screen your client’s staff open every day.
