The classic editor hotfix advice going around is one line: if you use the old editor, update Classic Editor and move on. That’s right for most sites and incomplete at the edges. WordPress 7.0 broke the extra action buttons that plugins and hand-written code attach to the classic publishing panel, and not every site with that setup got there through the Classic Editor plugin.
The core team posted the announcement on Make WordPress Core about a week after 7.0 shipped. Install Classic Editor 1.7.0 or Hotfix 1.4 to cover the problem, and expect a permanent fix in 7.0.1. Only classic editor users who extended the post publishing panel are affected, which is why this got a plugin hotfix instead of an out-of-band core release. A vanilla install with nothing hooked into the publish box is fine.
What the bug touches
The publish box is one of the last admin areas core still documents for direct extension, and two actions carry most of it: post_submitbox_start for anything at the top of the submit box, and post_submitbox_misc_actions for the minor rows under Status and Visibility. Buttons added on either hook stopped working after the 7.0 upgrade. Ticket #65286 on Trac tracks it, and the action reference lists the hooks if you want to see which one your code leans on.
In practice this means workflow and editorial plugins, revision tools, and in-house snippets that add a second or third button next to Publish. If those buttons vanished or stopped responding after the upgrade, this is your ticket. If nothing on the site extends the publish box, it can’t be, no matter which editor is active.
Which classic editor hotfix to install
Classic Editor 1.7.0 is the boring option, which is a point in its favor. If the site already runs the plugin, the fix rides in on an update you’d apply anyway, through the same updates screen, with release notes attached. There’s nothing new to install and nothing to uninstall later. The plugin is maintained by contributors who work on core, which is how it can carry a core fix in the first place.
Hotfix 1.4 covers the sites the first option misses. Plenty of codebases turn the block editor off with a filter in a mu-plugin or a functions snippet instead of installing Classic Editor, and WooCommerce stores do this often to keep product screens predictable for the people who edit them all day. Those sites never receive a Classic Editor update, so the small Hotfix plugin is how the fix reaches them. It also changes nothing about the editor itself, which matters when a client has opinions about the plugin list.
I’m reading the announcement as Classic Editor 1.7.0 fixing the sites that run it, and Hotfix covering everyone else. If that reading is wrong and the plugin fix only applies under certain settings, Hotfix is still the safe pick, because it exists to do exactly this one job. There’s a third option too: waiting for 7.0.1. If the only publish box extension is an internal workflow someone uses occasionally, waiting is defensible. If editors click those buttons every day, don’t.
How to check whether a site is affected
Before deciding anything, find out whether the site extends the publish box at all. Both hooks are string-searchable, so one grep over the content directory answers it:
grep -rn --include="*.php" "post_submitbox" wp-contentThat covers plugins, mu-plugins and themes in one pass. Any hit needs a look, so open a draft and check that the buttons render and fire. It takes about ten minutes per site. The usual hit is old client code nobody remembers writing, because publish box buttons from a 2019 build don’t get touched until an editor reports them missing. No hits means #65286 can’t affect that site.
After 7.0.1 lands
The permanent fix is targeted for 7.0.1, so this has an end date, the same way 6.9.1 closed out its own bug list. When it ships, Classic Editor stays what it always was, a plugin you keep updated. The Hotfix plugin turns into dead weight, and I don’t know whether 1.4 disables itself once core carries the fix, so I’d deactivate it after confirming 7.0.1 on the site rather than leave fix code running with nothing to fix.
My picks, then: a client site already on Classic Editor, the kind I wrote about when looking at the Write editor for client sites, gets the 1.7.0 update and nothing else. For a site with a custom editor replacement, it’s Hotfix 1.4 plus a note to remove it after 7.0.1. Anything uncertain gets the grep above before the maintenance release arrives, because once 7.0.1 is live the symptom disappears and so does the evidence. If you want someone to look at a store or a client site before that window closes, that’s work I do regularly; send the URL and I’ll tell you which fix it needs.
