WordPress Block Editor Crashes or Goes Blank: How to Fix It

This article is a localized edition of the Japanese original. Read the Japanese original

You open the post editor and the block editor stays blank, or it shows "The editor has encountered an unexpected error.", or a single block says "Block contains unexpected or invalid content." Most of these symptoms come from a JavaScript error running in the browser. This article walks through how to find the error, how to identify the plugin or theme behind it, and how to repair broken blocks. The on-screen messages are those of WordPress as of October 2026.

Symptoms and common causes

Step 1: Check the error in the browser console

First, find out which file is throwing the error.

1. With the editor open, press F12 (Option + Command + I on a Mac) to open the developer tools
2. Open the "Console" tab and reload the page
3. Look at the lines shown in red and check the file name (URL) on the right

If the URL contains /wp-content/plugins/plugin-name/, that plugin is the suspect; if it contains /wp-content/themes/theme-name/, the theme is. Even when the error is reported in a file under /wp-includes/, another script that called that file may be the real cause, so move on to the isolation steps below.

The "The editor has encountered an unexpected error." screen has a "Copy Error" button that copies the error details. Use it when you report the problem to the plugin author.

Load unminified scripts to make the error readable

WordPress core scripts are minified, so the line numbers in an error can be hard to trace. Add the following to wp-config.php above the /* That's all, stop editing! */ line to load the unminified scripts.

<?php
// wp-config.php: enable only while you investigate
define( 'SCRIPT_DEBUG', true );

Remove it or set it back to false when you are done.

Step 2: Rule out the browser

Ad blockers and script-blocking extensions can stop the editor's scripts from loading. Open the editor in a private window (where extensions are disabled) or in another browser and see whether the problem still occurs. If the other browser works, the cause is an extension or the cache in your original browser.

Step 3: Deactivate plugins to find the cause

Turning off every plugin on a live site at once affects your visitors too. Use one of the following methods instead.

Method A: Use the Health Check & Troubleshooting plugin

The troubleshooting feature of the "Health Check & Troubleshooting" plugin from wordpress.org disables plugins and applies a default theme for you alone, while you are logged in. The site your visitors see does not change, so you can isolate the problem even on a production site.

Method B: Deactivate with WP-CLI (for staging environments)

On a staging environment, or when you can reach the server over SSH, WP-CLI is faster. Save the list of active plugins first so you can restore it.

# Save the list of currently active plugins
wp plugin list --status=active --field=name > active-plugins.txt

# Deactivate everything and check whether the editor opens
wp plugin deactivate --all

# Reactivate one at a time; the one that brings the problem back is the cause
wp plugin activate plugin-slug

# When you are done, restore the original set in one go
wp plugin activate $(cat active-plugins.txt)

You can do the same in the admin under "Plugins" → "Installed Plugins" with the "Deactivate" bulk action.

Step 4: Switch themes to check

If no plugin is to blame, switch to a WordPress default theme and check again. You can see the slugs of the default themes you have installed with wp theme list.

wp theme list
wp theme activate twentytwentyfive

If the editor works with the default theme, your theme's scripts are the cause.

Step 5: Fix how your theme or custom code loads scripts

The front-end wp_enqueue_scripts action does not run on the block editor screen. As long as you load front-end scripts with wp_enqueue_scripts, those scripts cannot break the editor. The scripts that affect the editor are the ones loaded with these hooks:

If you load a front-end-only script with enqueue_block_assets or admin_enqueue_scripts, it also runs in the editor and can throw errors there. Move front-end scripts to wp_enqueue_scripts and load only editor scripts with enqueue_block_editor_assets.

<?php
// functions.php: load front-end and editor scripts separately

// Front end (public pages) only. Does not run in the admin or the editor
add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_script(
		'my-theme-main',
		get_template_directory_uri() . '/js/main.js',
		array(),
		'1.0.0',
		true
	);
} );

// Load only the script meant for the block editor
add_action( 'enqueue_block_editor_assets', function () {
	wp_enqueue_script(
		'my-theme-editor',
		get_template_directory_uri() . '/js/editor.js',
		array( 'wp-blocks', 'wp-dom-ready' ),
		'1.0.0',
		true
	);
} );

If your editor script uses WordPress scripts such as wp.blocks, list them as dependencies (the third argument), as with wp-blocks above. Without that, your script may run before the WordPress scripts and fail with Cannot read properties of undefined.

Remove another plugin’s script only on the edit screen

If a script that another plugin loads across the whole admin is the cause, but you want to keep using the plugin, remove the script only on the post edit screens (post.php and post-new.php). Replace conflicting-script with the handle of the offending script. You can find the handle as the first argument of wp_enqueue_script() in the plugin's source.

<?php
// functions.php: remove the given script only on the post edit screens
add_action( 'admin_enqueue_scripts', function ( $hook_suffix ) {
	if ( in_array( $hook_suffix, array( 'post.php', 'post-new.php' ), true ) ) {
		wp_dequeue_script( 'conflicting-script' );
	}
}, 100 );

The priority is 100 so that the script is removed after the plugin has enqueued it at the default priority (10). Any feature that relied on the removed script will stop working on the edit screen. The real fix is a plugin update or a report to its author.

Step 6: Repair a block flagged as “invalid content”

When a block shows "Block contains unexpected or invalid content.", try the following in order.

1. Click the "Attempt recovery" button shown on the block. In many cases the block is rebuilt in its current format
2. If that does not help, open the options (⋮) menu next to the "Attempt recovery" button and choose "Convert to HTML". The content is kept as a Custom HTML block
3. Check the content and, if needed, rebuild it with new blocks

Before you start, it is safer to keep a copy of the post content. With WP-CLI, the following command shows and saves the body HTML (123 is the post ID).

wp post get 123 --field=post_content > post-123.html

If the post has revisions, you can also go back to the state before the block broke from "Revisions" in the editor's right sidebar.

Step 7: If nothing works, fall back to the Classic Editor

If finding the cause will take time and you need to update a post now, the official "Classic Editor" plugin lets you switch to the old editor temporarily.

wp plugin install classic-editor --activate

Keep in mind that editing a block-built post in the Classic Editor can lose the block boundaries. Use it only as a temporary workaround and deactivate it once the cause is fixed.

Summary

• Start by finding the file that throws the error in the browser console. Turning on SCRIPT_DEBUG temporarily makes it easier to read
• Use a private window or another browser to rule out extensions
• Isolate plugins with Health Check & Troubleshooting or WP-CLI. With WP-CLI, save the list of active plugins first
• Only scripts loaded with enqueue_block_editor_assets, enqueue_block_assets or admin_enqueue_scripts affect the editor. wp_enqueue_scripts does not run in the editor
• When removing another plugin's script, call wp_dequeue_script() only for post.php and post-new.php
• Repair "invalid content" blocks with "Attempt recovery" or "Convert to HTML"

Related articles:

• How to fix JavaScript errors in WordPress
• What to do when WordPress meta boxes do not appear

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)