Publishing failed
You wrote it. WordPress just won't take it.
'Publishing failed' is the block editor reporting that its phone call home didn't connect. The modern editor saves by talking to your own site's REST API — and when that internal conversation is blocked, filtered, or misrouted, the editor sits there holding your finished post, unable to hand it over.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
The block editor is an application running in your browser that saves via requests to your site's REST API — a machine-to-machine doorway at /wp-json/. 'Publishing failed' means that request errored, and the disease is almost never the post itself: it's the doorway. Security plugins and firewalls block the REST API deliberately (it appears on hardening checklists, collateral damage included); hosts' WAF rules pattern-match editor requests as suspicious; permalink corruption breaks the /wp-json/ route entirely; and expired login sessions leave the editor talking with dead credentials.
The diagnosis has a wonderfully direct test: visit yourdomain.com/wp-json/ in a browser. A page of JSON means the doorway exists and the investigation moves to authentication and security filtering; an error or a 404 means the route itself is broken — usually permalinks or an overzealous block — and you've found your layer in ten seconds. It's also worth knowing the classic editor (which saves via traditional form posts) usually still works when REST is blocked: that's both a useful emergency workaround and a confirming symptom, since 'new editor fails, old editor works' is REST-blockage's signature.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
Security plugins blocking the REST API
Hardening settings that disable or restrict /wp-json/ — protection checklists breaking the editor as a side effect. The leading cause.
WAF and host firewall filtering
ModSecurity-class rules pattern-matching editor saves as attacks — sudden onset after host-side rule updates.
Permalink and rewrite corruption
The /wp-json/ route 404ing because rewrite rules broke — often after migrations or .htaccess damage.
Session and authentication decay
Long editing sessions outliving login cookies — the save fails auth, the message says 'publishing failed,' and re-login fixes it.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Visit /wp-json/ directly
JSON: doorway exists, suspect security/auth. Error or 404: the route is broken, suspect permalinks. Ten seconds, and the search space halves.
- 2
Re-login and retry once
Log fully out and back in, retry the publish. Expired sessions cause a meaningful share of these, and the fix costs nothing.
- 3
Flush permalinks
Settings → Permalinks → Save (no changes needed). Rebuilding rewrite rules resurrects a broken /wp-json/ route more often than seems reasonable.
Stop and call when…
- The security plugin's REST restrictions need surgical allowlisting — editor working, hardening kept, both at once
- Host-level WAF rules are eating saves — that's a host-ticket conversation with specifics they'll act on
- Publishing fails intermittently — timing-based causes (sessions, rate limits, resource ceilings) need methodical reproduction
From there it’s our job: same-day look, flat quote, and the $229 flat repair covers most cases of exactly this.
Single Error Fix — buy it now, skip the hunt.
One error, hunted down and fixed — 500s, white screens, redirect loops, broken pages.
Covers one specific error or broken behavior on one site. Diagnosis, the fix, and a plain-English note on what happened. If we can't fix it, you get a full refund.
Questions we hear a lot.
Why does the old classic editor still work when the new one fails?
Different transport: the classic editor saves via traditional form submission, the block editor via REST API calls. When security layers block /wp-json/, only the modern path dies. That asymmetry is a diagnostic gift — and a workaround for posting today — but the durable fix is repairing the REST path, since more and more of WordPress (and its plugins) depends on it.
Should the REST API just be disabled for security like my plugin suggests?
Blanket-disabling it breaks the editor and a growing share of legitimate functionality — it's the security equivalent of removing the front door to stop burglars. The defensible posture is scoped: authenticated access preserved, anonymous enumeration restricted, specific abuse patterns filtered. Good security plugins can do it; the checkbox that broke your publishing wasn't that setting.
What does the $229 fix cover?
The layer diagnosis (route, auth, filtering), the REST path repaired with your security posture kept intact — allowlisted, not disarmed — permalinks rebuilt if corrupted, the host ticket written with specifics if their WAF is the blocker, and a verified publish of a real post before we call it done. Your words, live, same-day.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Write. Publish. Live. The way it's supposed to go.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.