Fix the WordPress Block Editor Not Loading

Most of the time, a WordPress block editor that won’t load is a JavaScript error — one broken script from a plugin or theme halts the entire React app, and the editor never finishes rendering. Open your browser’s developer console (F12, or Cmd+Option+I on Mac), reload the edit screen, and read the red error. It almost always names the file that threw. That one line tells you which plugin to disable, and you can usually be back to writing in under five minutes. Reinstalling WordPress, bumping the PHP memory limit, and switching to the Classic Editor are the three most common suggestions online, and all three are usually the wrong move.

Why the editor breaks the way it does

The block editor (Gutenberg) is a single-page React application that runs inside wp-admin/post.php and post-new.php. WordPress enqueues a stack of script packages — wp-blocks, wp-element, wp-editor, wp-edit-post — and the app bootstraps through wp.domReady(). JavaScript stops executing on the first uncaught exception. So if any enqueued script throws while the editor is initializing, everything after it dies with it. Your carefully written post area collapses into a blank white pane or the message “The editor has encountered an unexpected error.”

By default WordPress also concatenates admin scripts into fewer requests. That means one plugin’s broken JS can drag down unrelated scripts loaded in the same bundle, which is why the culprit isn’t always obvious from behavior alone. The console is.

The second failure mode looks different: the editor loads, but saving throws “Updating failed. The response is not a valid JSON response.” That is not a JavaScript problem. The editor talks to the REST API at /wp-json/wp/v2/, and it expects clean JSON back. If a plugin or your theme’s functions.php emits a PHP notice, warning, or fatal before the JSON — or a security plugin blocks the REST route, or a redirect plugin rewrites the URL — the response is polluted and the editor can’t parse it.

How to fix it, fastest first

1. Read the console. Reproduce the failure with DevTools open. An error like Uncaught TypeError ... some-plugin/build/index.js points straight at the offending plugin. This single step resolves the majority of cases and saves you from blind bisecting.

2. Rule out the browser. Hard-refresh (Cmd/Ctrl+Shift+R), then try an incognito window with extensions off. Ad blockers and privacy extensions occasionally strip admin scripts. If it works in incognito, the problem is a browser extension or stale cache, not your site.

3. Check the REST API directly if you saw the “not a valid JSON” message. Visit https://yoursite.com/wp-json/ in a browser. You should get a wall of JSON. If you get HTML, a 500, or a login redirect, that is your bug — a plugin is breaking the REST response, not the editor itself.

4. Bisect your plugins. Deactivate all of them, confirm the editor loads, then reactivate one at a time until it breaks again. If you’re locked out of wp-admin entirely, do it over SFTP by renaming the folder:

mv wp-content/plugins wp-content/plugins_off

WordPress deactivates everything when the folder disappears. Rename it back, then move plugins in and out individually.

5. Test the theme. Switch to Twenty Twenty-Four. A theme that enqueues broken editor JS or throws PHP in functions.php produces the same symptoms.

6. Turn on the log and read the real error. For the REST/JSON failures especially, enable debugging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

The fatal gets written to wp-content/debug.log with the exact file and line number. If that stack trace is dense — namespaced class names, require chains, a fatal buried under ten lines of trace — paste it into our WordPress error log decoder to see, in plain terms, which plugin and line actually triggered it. That’s the difference between “something is broken” and “line 214 of this specific plugin is broken.”

If you suspect script concatenation is masking the real culprit, force each script to load separately so the console error points at exactly one file:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

What not to do

Don’t install the Classic Editor plugin and call it fixed. It doesn’t fix anything — it hides the block editor so you stop seeing the error. The broken JavaScript or broken REST response is still there, and it will bite you again in the site editor, in widgets, or the next time you update. Diagnose first; fall back to Classic only if you’ve made a deliberate choice to stop using blocks.

Don’t raise the PHP memory limit on reflex. It’s the internet’s favorite copy-paste fix, but a blank editor is rarely memory exhaustion. Real exhaustion throws a specific fatal — “Allowed memory size of N bytes exhausted” — which you will see in debug.log. If that line isn’t there, more memory changes nothing.

Don’t reinstall WordPress core. Core files are byte-identical on every install. If core were the problem, every WordPress site on earth would have a broken editor right now. The fault is almost always in your plugins or theme, and reinstalling core risks overwriting things while fixing nothing.

Don’t blindly clear or disable your cache plugin as step one. Aggressive JS minification and concatenation can break the editor, so it’s worth testing — but check the console before you go flushing caches at random. Guessing is how a five-minute fix turns into an afternoon.

Still stuck?

If the console is clean, the REST API returns valid JSON, and a full plugin-and-theme bisect still leaves the editor dead, the answer is almost always sitting in debug.log. Enable WP_DEBUG_LOG, reproduce the failure once, and run the resulting fatal through the error log decoder. The stack trace names the file — start there.