Gutenberg Editor Problems: Blank Editor, Invalid Blocks

The block editor that ships with WordPress, still widely called Gutenberg, is where most people write their pages and posts now. When it misbehaves, it tends to do so in one of three ways. The screen stays white or grey after you click Edit. A yellow or grey box appears inside your content saying “This block contains unexpected or invalid content.” Or the whole editor collapses into a message reading “The editor has encountered an unexpected error.”

Each of these has a different cause, and treating them as one problem wastes time. Below we take them one at a time, then look at the Classic Editor question, which comes up whenever the block editor starts causing trouble.

First, a few things worth knowing about how the editor works

The block editor is a JavaScript application that runs in your browser. It loads your post through the WordPress REST API, lets you change it, and saves it back the same way. That has two practical consequences.

• Anything that breaks JavaScript in the admin area, from a plugin script to a browser extension, can stop the editor from drawing at all.
• Anything that blocks or corrupts REST API requests, such as a firewall rule, a security plugin or a PHP warning printed into the response, stops it loading or saving content.

Keep those two points in mind and most editor faults stop looking mysterious. For the broader family of WordPress errors and where each is explained, see our WordPress errors and fixes guide.

Problem 1: the editor will not load

You open a post and get a blank white area, a grey screen, or a spinner that never stops. The admin menu may still be visible around it.

Likely causes

1. A plugin script error. Plugins that add panels or blocks to the editor run their own scripts there. One bad script after an update can stop the rest.
2. The REST API being blocked. Security plugins, server firewalls and some CDN rules block requests to /wp-json/. The editor then cannot fetch your post. Site Health (Tools > Site Health) usually reports this as a REST API problem, which we explain in our post on the REST API error in Site Health.
3. Browser extensions. Grammar checkers, ad blockers and password managers sometimes interfere with the editor’s text areas.
4. Old cached admin scripts. After a WordPress update, a cache or CDN still serving the previous versions of the editor’s files can leave it half-built.

What to try

1. Open the same post in a private window with extensions off, or in a different browser. If it works there, the cause is on your machine.
2. Press F12, open the Console tab and reload. Red errors that mention a file path inside wp-content/plugins/ point straight at the plugin involved.
3. Clear your caching plugin and CDN, then reload with a hard refresh.
4. Check Tools > Site Health for REST API or loopback warnings.
5. With a recent backup in hand, deactivate plugins that touch the editor (block libraries, SEO plugins, custom field plugins, page builders) and test after each. On a busy site, do this on a staging copy instead.

Problem 2: “This block contains unexpected or invalid content”

The editor opens, but one or more blocks show a warning instead of your content, with an Attempt Block Recovery button. The front end of the page often still looks fine.

What it means

Every block is saved as HTML wrapped in special comments. When the editor loads a post, it rebuilds each block from its settings and compares the result with the HTML stored in the database. If the two do not match, the block is flagged as invalid. Nothing is lost at this point; the editor is simply refusing to guess which version is correct.

Why the HTML stops matching

• Someone edited the post in the Code Editor, or pasted HTML, and changed the markup by hand.
• A plugin that provides the block updated and changed how the block is saved, without code to handle older versions.
• Content was imported from another site, or run through a search-and-replace that altered the HTML.
• A security or optimisation filter stripped attributes from the content when it was saved.

How to handle it

1. Make a copy of the post content first. The three-dot menu at the top right of the editor lets you switch to the Code Editor; select all and paste it into a text file.
2. Click Attempt Block Recovery. For simple blocks this usually rebuilds the block from its stored settings and clears the warning.
3. If recovery changes the block in a way you do not want, use the block’s own menu. It typically offers options to resolve the difference by comparing the two versions, or to convert the block to HTML or to a Classic block, which keeps the content exactly as stored.
4. If many blocks from one plugin are invalid at once, the plugin update is the cause. Check its changelog and support forum before recovering dozens of blocks by hand; a fix may already be on its way.

Problem 3: “The editor has encountered an unexpected error”

This is the editor’s own crash screen. It usually offers buttons to attempt recovery, copy the post text and copy the error. Use Copy Error first and save the text; it normally names the script or block that failed.

The cause is almost always a block or plugin script throwing an error the editor could not handle. Common triggers are a block from a plugin that was just updated or deactivated, a theme that adds editor styles or scripts badly, and two plugins both trying to modify the same editor panel. The fix is the same plugin-by-plugin test as above, starting with whatever changed most recently. If you can reproduce it on one particular post, look at which unusual blocks that post contains.

Developers can add define( 'SCRIPT_DEBUG', true ); to wp-config.php on a staging site. WordPress then loads the full, readable versions of its scripts, so the error messages in the console become far more useful.

Saving fails, but the editor loads

A close relative of these problems is the red notice that appears when you click Update, complaining that the update failed because the reply was not valid JSON. The editor is fine; the save request is being blocked or corrupted on the way back. That one has its own causes and fixes, set out in our article on the invalid JSON response error.

Should you switch back to the Classic Editor?

The official Classic Editor plugin restores the older single-box editor. It is a legitimate choice, but it is worth being clear about what it does and does not solve.

One more point: some posts open in the classic screen even without the plugin. That happens when a custom post type is registered without REST API support, or when a theme or plugin uses a filter to turn the block editor off for that type. If only one kind of content opens in the old editor, that is usually by design, not a fault.

Things that are not editor bugs at all

• The page looks different from the editor. The editor uses editor styles supplied by your theme. If the theme supplies poor ones, the editor view will never match the front end exactly. That is a theme limitation.
• Changes saved but the live page has not changed. Usually a cache. Our post on edits that do not appear on the live site walks through each cache layer.
• The page is built in Elementor or another builder. In that case the block editor is not the tool doing the work, and the builder’s own editor is where the fault will be. Our page on Divi, WPBakery and other builder problems covers that side.

Keeping the editor stable

• Stick to one main block library. Several overlapping block collections increase the chance of script clashes and invalid blocks after updates.
• Avoid editing block markup by hand unless you know how blocks are stored. The Code Editor is useful for copying content, less so for rewriting it.
• Test plugin updates that touch the editor on a staging copy before running them on a large site.
• Keep an eye on Site Health. REST API and loopback warnings there are often the first sign the editor is about to start failing.
• Keep the theme up to date. A theme that has not been updated in years is a common reason the editor and the front end slowly drift apart.

When it is time to ask someone

If the console errors point at a plugin you cannot do without, if the REST API is being blocked by a rule at your host that you cannot see, or if invalid blocks appear across hundreds of posts after an import, it stops being a five-minute job. If you would like us to look, send the copied error text or a screenshot. We will take a backup, reproduce it on a copy, and tell you plainly what we find. Our WordPress bug fixing service page sets out how we work.

Next in this series: WooCommerce Orders Not Showing? Where They Go and Why