When the Block Editor Will Not Work

Quick triage: open the browser console before touching anything else. The block editor is a JavaScript application that talks to WordPress through the REST API, and nearly every failure is either that API being blocked or a script error stopping the application from finishing its startup — the same holds for the site editor, which runs on the same JavaScript foundation. Work through the following causes roughly in order of how often they turn out to be the culprit.

Read the console first

Press the browser's developer tools shortcut and open the Console tab, then reload the editor screen. A red error naming a script file and a line number points directly at the offending plugin or theme code. A string of 403 or 404 errors pointing at /wp-json/ addresses points at the REST API rather than JavaScript. Doing this first turns "the editor is broken" into a specific, searchable error instead of a guess, and it is the fastest way to tell the next few causes apart without testing each one blind.

The REST API being blocked

This is the single most common cause. The block editor loads posts, saves drafts and fetches block types entirely through REST API requests running in the background, and if anything on the server intercepts those requests, the editor screen loads its shell but never finishes populating, often sitting on a spinner or a blank content area indefinitely.

Typical blockers:

• A security plugin or firewall rule denies requests to /wp-json/* by default, mistaking API traffic for an attack.
• A maintenance-mode or coming-soon plugin intercepts every request, including REST calls, and returns its holding page instead of JSON.
• Permalinks are set to "Plain," which can leave the REST API without the rewrite rules it needs to resolve its routes cleanly.
• A hosting-level firewall or CDN rule blocks the wp-json path specifically.

Test it directly: visit yoursite.com/wp-json/ in a browser tab. It should return JSON text describing the site's available routes. An HTML error page, a redirect, or a blank response confirms the API is not reachable, and the fix is to find and remove whatever rule is intercepting it rather than anything inside the editor itself.

A JavaScript error from a plugin or theme

Any plugin or theme that enqueues its own script on the editor screen can throw an error that halts the rest of the editor's JavaScript from initialising, even if that script has nothing to do with content editing. A calendar widget's admin script, an analytics snippet loaded everywhere including wp-admin, or an outdated plugin using a deprecated JavaScript API are all plausible culprits.

Narrow it down by deactivating plugins one at a time — or all at once, then reactivating in batches — and reloading the editor after each change, watching the console for the error to disappear. A theme's editor-specific styles or scripts, registered for block editor compatibility, are worth suspecting too if the problem persists with every plugin off.

Browser extensions

Ad blockers, privacy extensions, and script blockers running in the browser itself can strip out requests or scripts the editor depends on, and they will not show up in a plugin-deactivation test because the interference is happening client-side, not on the server. Reload the editor in a private or incognito window with extensions disabled by default. If the editor works there, an extension is the cause, and the fix is a site-specific exception rather than anything in WordPress.

A custom post type missing show_in_rest

The block editor is only available for a post type when that post type is registered with show_in_rest set to true, because the editor needs the REST API endpoints that flag creates. A custom post type registered without it — common with older or poorly maintained plugins — falls back to the classic editing screen, or in some setups shows no proper editing interface at all for that content type.

register_post_type('project', [
    'label'       => 'Projects',
    'public'      => true,
    'show_in_rest' => true, // required for the block editor
    'supports'    => ['title', 'editor', 'thumbnail'],
]);

If the block editor fails for exactly one post type and works everywhere else, this is the first thing to check, and it is a code fix rather than a settings toggle — it lives wherever that post type is registered, as WordPress custom post types explained covers in more detail.

Memory limits on very long posts

PHP memory limits and the browser's own resources both matter here. A very long post with many blocks — often the result of inserting a large block pattern rather than building block by block — especially many images or embedded content, can exceed PHP's memory limit during autosave or save, producing a save failure or a 500 error from the REST API rather than a visible editor crash. The browser side has its own ceiling: an extremely long single post can make the editor sluggish or unresponsive well before PHP is involved, simply because rendering and re-rendering hundreds of blocks is expensive.

Raising the PHP memory limit helps the server-side symptom; splitting an unusually long post into fewer, larger blocks or across multiple pages addresses both. How to speed up a WordPress site covers memory and performance settings more broadly if this turns out to be a recurring pattern rather than one oversized post.

The classic-editor fallback as diagnosis, not a fix

Switching a post to the Classic Editor, or installing a plugin that restores it, will get content published while the real cause is still unresolved — it does not touch the REST API, the failing script, or the missing show_in_rest flag. It is useful as a diagnostic step: if content edits and saves cleanly in the classic editor, that confirms the underlying save pipeline works and narrows the fault specifically to the block editor's JavaScript or its API calls, per how to restore the classic editor in WordPress.

Common mistakes

• Guessing instead of reading the console. The error usually names the exact script or request that failed.
• Treating the classic editor as a permanent fix. It hides the symptom without resolving the cause.
• Deactivating plugins without testing the REST API first. If /wp-json/ itself is blocked, no plugin toggle will fix it.
• Overlooking browser extensions. They interfere client-side and survive every server-side test.
• Forgetting show_in_rest on a custom post type. The editor cannot appear without it, regardless of anything else on the page.

Verify

Reload the editor in a clean, extension-free browser profile and check the console for errors on load. Visit /wp-json/ directly and confirm it returns JSON rather than an error page. Save a test post and confirm the change persists after a hard refresh, and if a specific post type is affected, check its registration for show_in_rest. If problems persist, enabling WordPress debug mode surfaces PHP-side errors the browser console cannot show.