How to fix "The editor has encountered an unexpected error" in WordPress

The block editor shows this when one of its scripts fails while the screen is being drawn. Your saved post is untouched in the database. Save a copy first, then read the text behind "Copy error". It names the script that failed, and the folder in its path names the plugin or theme.

By: WP Ministry
Published: October 8, 2026
Tested on: WordPress 7.1.3, PHP 8.3.35

In short

The message means a script failed while the editor was drawing the screen. The post as last saved is untouched in the database.
Check what "Copy contents" gave you. On WordPress 7.1 it can copy nothing, so paste it into a text file and look.
With WP-CLI, write the saved post to a file in your home folder before you try any fix.
"Copy error" holds the real error. The first address in it that is not under /wp-includes/ names the plugin or theme.
If one post fails and the rest open, switch to the Code editor on a post that opens, then open the one that fails.
Do not delete the post, and do not save from an editor that only half loaded.

"The editor has encountered an unexpected error." means a script failed while the block editor was drawing the screen. WordPress caught the failure and put this notice where the editor should be. The notice is the same whatever failed. The real error is behind its "Copy error" button and in the browser's console.

Your post is not lost. What you last saved is in the site's database, and an editor that fails to draw changes nothing there. Anything you typed since the last save exists only in that browser tab, so get a copy before you reload. The first fix shows how.

Check that this is the message you have

The editor has smaller messages for smaller failures. They look alike and mean different things.

What you see	What it means
"The editor has encountered an unexpected error." in place of the whole editor, with "Copy contents" and "Copy error"	The whole editor stopped. This page.
"This block has encountered an error and cannot be previewed." inside one block	One block's script failed. The rest of the editor works. The console names the script, as below.
"Block contains unexpected or invalid content." with "Attempt recovery"	A different message. One block's saved markup is not what the block expects, and the editor itself works.
A notice that a named plugin "has encountered an error and cannot be rendered."	One plugin's panel failed. The notice names it. Update that plugin or switch it off.
"Updating failed." or "Publishing failed."	The editor loads and saving fails. See how to fix "Updating failed".
"There has been a critical error on this website."	PHP failed on the server, not a script in your browser. See the critical error page.

Read the real error

Press "Copy error" and paste into a text file. It looks like this:

text

ReferenceError: exampleFunction is not defined
    at https://example.com/wp-content/plugins/plugin-folder-name/build/editor.js?ver=1.2:2:134
    at mf (https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:105:412)

The first line says what went wrong. Each line that begins "at" is a script that was running, the nearest to the failure first. Read down for the first address that is not under /wp-includes/.

That address runs through	It names	Go to
`/wp-content/plugins/` and a folder name	That plugin	Switch off the plugin the error names
`/wp-content/plugins/gutenberg/`	The Gutenberg plugin	Bring Gutenberg and WordPress into step
`/wp-content/themes/` and a folder name	The theme	Rule out the theme
A cache folder, or one file that holds many scripts	Combined scripts	Stop the dashboard's scripts being combined or delayed
`chrome-extension://` or `moz-extension://`	A browser extension	Rule out your browser
Nothing but `/wp-includes/` and `/wp-admin/`	Nothing yet	The test below

The browser's console shows the same error, and others the notice leaves out, such as a script that failed to load. WordPress.org's page on using your browser to diagnose JavaScript errors has the keys for each browser.

When the error names only WordPress's own files, one test narrows it. Open a different post, then start a new one.

Every post fails: the fault is in what the editor loads. Work through the plugin, Gutenberg, theme, browser and script fixes in that order.
One post fails and the rest open: something saved in that post trips it. Go to "Open the one post that fails".

What not to do

Do not save from an editor that only half loaded. If the canvas is blank or blocks are missing, Save or Update writes what the editor holds, which may be less than the post.
Do not delete the post or start it again. The saved content is intact. Deleting the post is the one step that could lose it.
Do not restore a whole backup for this. A restore removes everything that arrived since the backup was taken, and nothing here needs it.
Do not switch off every plugin on a live site to test. Troubleshooting mode does the same for your login alone.

If you would rather hand the search over, our one-time fix covers one issue on one site and starts with a free diagnosis, which gives you a written cause and a fixed quote.

Where it goes wrong

A page request passes through each of these in turn. This one comes from WordPress itself.

Browser
DNS
HTTPS
CDN or firewall
Web server
PHP
WordPress (this error comes from here)
Database and files

What causes it

A plugin's editor script fails
Common
Plugins add scripts of their own to the editor. One that fails outside its own block or panel takes the whole editor down. It often begins with an update to the plugin or to WordPress.
Fix: Save a copy of the post before you try anything, or Switch off the plugin the error names
One post's content trips the fault
Sometimes
The editor opens for other posts and fails on one. Something saved in that post, usually one block, is what the failing script cannot handle.
Fix: Save a copy of the post before you try anything, or Open the one post that fails
The Gutenberg plugin and WordPress are out of step
Sometimes
The Gutenberg plugin swaps the editor that WordPress ships for a newer one. A block plugin written for one can fail on the other, and an old copy of Gutenberg can fail on a new WordPress.
Fix: Save a copy of the post before you try anything, or Bring Gutenberg and WordPress into step
The theme's editor script fails
Sometimes
A theme can load scripts and styles into the editor, as a plugin does, and they fail the same way. A theme.json that cannot be read does not cause this message by itself, but it is quick to rule out.
Fix: Save a copy of the post before you try anything, or Rule out the theme
A browser extension, or an old copy of a script in the browser
Sometimes
An extension can change the page the editor is drawn in. A browser can also hold on to a script from before an update.
Fix: Save a copy of the post before you try anything, or Rule out your browser
Something combines, defers or delays the dashboard's scripts
Sometimes
The editor is many scripts that must run in order. A feature that merges them, or holds them back until the page has drawn, can break that order. WordPress, optimization plugins and CDNs each have such a feature.
Fix: Save a copy of the post before you try anything, or Stop the dashboard's scripts being combined or delayed
The editor's requests to the REST API fail
Rare
WordPress puts the first answers the editor needs into the page, so the editor can draw while the REST API is failing. Code that takes a later answer for granted can still fail on a 403, a 404 or an answer that is not JSON.
Fix: Save a copy of the post before you try anything, or Check that the REST API answers

How to fix it

Save a copy of the post before you try anything

Easy
No risk
About 10 minutes
Steps tested on WordPress 7.1.3

Step 1: Keep the tab open
Do not close it. While you write, the editor keeps a backup of unsaved changes in the browser's session storage, which belongs to that one tab. It survives a reload and is cleared when the tab closes. When the editor next opens the post in that tab, it offers the backup: "The backup of this post in your browser is different from the version below.", with the button "Restore the backup".
Step 2: Press "Copy contents", then look at what you got
Paste into a plain text file. On WordPress 7.1 the paste can be empty. The button asks the editor for the post at the moment you press it, and an editor that has stopped has already let go of the post. An empty paste does not mean the post is empty.
3
Step 3: If the paste is empty and you had unsaved changes
Open the browser's developer tools with F12, or Cmd+Option+I on a Mac, and click Console. Paste the line below with your post's ID in place of 123, then press Enter. The ID is the number after post= in the address bar. For a page, write 'page' where the line says 'post'. Chrome asks you to type allow pasting first.

It copies the post as the tab still holds it, unsaved changes included. Paste it into the text file.
javascript
```
copy( ( ( r ) => typeof r.content === 'function' ? r.content( r ) : r.content )( wp.data.select( 'core' ).getEditedEntityRecord( 'postType', 'post', 123 ) ) );
```
4
Step 4: Save what the database holds
Over SSH, from the folder that holds wp-config.php, with the same ID:

The first line writes the post as last saved to a file in your home folder. That is outside the folder the site is served from, so nobody can download it. The second prints the start of the file, so you can see that it is your post.
bash
```
wp post get 123 --field=post_content > ~/post-123.html
head -c 300 ~/post-123.html
```

Without SSH, skip the last step. The saved post stays in the database whatever you do to plugins, the theme or your browser.

The WP-CLI step is the one a test site can run. The buttons and the console are in your own browser.

Switch off the plugin the error names

Easy
Low risk
About 15 minutes
Steps tested on WordPress 7.1.3

Step 1: Take the plugin's folder name from the error
It is the part straight after /wp-content/plugins/.
2
Step 2: Deactivate that plugin
On the Plugins screen, select Deactivate under its name. With WP-CLI, use the folder name:
bash
```
wp plugin deactivate plugin-folder-name
```
Step 3: Reload the editor
If it opens, that plugin was the cause. Blocks the plugin provided now show a notice that begins "Your site doesn’t include support for". Leave them as they are: they work again when the plugin is back.
Step 4: Update the plugin, or report the error
A corrected version may already be out. If not, send the plugin's author the text from "Copy error" and your WordPress version, and keep the plugin off until it is fixed.

If the error names no plugin, search by removal. The Health Check & Troubleshooting plugin has a mode that switches every plugin off and uses a default theme for your login only, so visitors see no change. It cannot switch off must-use plugins. How to find and fix a WordPress plugin conflict walks through that mode and through bringing plugins back one at a time. If you cannot reach the Plugins screen at all, see how to deactivate plugins when you are locked out.

A test site can show that WordPress stops sending a plugin's script to the editor once the plugin is off. Whether the message then goes can only be seen in your own browser.

To undo it: Activate the plugin again.

Open the one post that fails

Takes care
Back up first
About 20 minutes
Steps tested on WordPress 7.1.3

Do the first fix before this one, so you hold a copy of the post.

Step 1: Switch to the Code editor on a post that opens
Open any post that works. Click the three dots at the top right, and under "Editor" choose "Code editor". The keys are Ctrl+Shift+Alt+M, or Shift+Option+Command+M on a Mac. A bar reads "Editing code". WordPress remembers the choice for your user.
Step 2: Open the post that fails
The Code editor does not draw the blocks, so a post that fails while a block is drawn opens here as markup in a text box. Each block sits between two comments, such as  and . If the message shows here too, use a revision or the Classic Editor, below.
Step 3: Find the block and take it out
A plugin's block carries the plugin's prefix and a slash, as in . Look for a block from the plugin the error named, or for the last thing you added before the post stopped opening. Cut everything from its opening comment to its closing comment, keep the cut text in your file, and save.
Step 4: Select "Exit code editor"
If the post now draws, the block you removed was what tripped the fault. Build that part again, or put it back once the plugin is fixed.

Or go back to a revision that opened. WordPress stores each save as a revision. List them, newest first, with the post's ID:

bash

wp post list --post_type=revision --post_parent=123 --orderby=ID --order=DESC --fields=ID,post_date,post_name

A name that ends in autosave-v1 is an autosave. To see a revision first, open https://example.com/wp-admin/revision.php?revision=456 with its ID. That screen does not use the block editor, and its button reads "Restore This Revision".

The next command replaces the post's content with the content of revision 456. What it replaces is in the file you saved in the first fix.

bash

wp post get 456 --field=post_content | wp post update 123 -

Or read the post without the block editor. The Classic Editor plugin, maintained by the WordPress team, restores the earlier Edit Post screen. With it active, the post opens with two tabs, "Visual" and "Code", and the Code tab shows the same markup. Use it to read and copy a post while the cause is found. The fault stays where it was. Which editor opens is set under Settings, then Writing.

A test site can run the two commands above. The Code editor and the Classic Editor are screens in your own browser.

To undo it: Paste the copy you saved back in, or restore the revision from before your change.

Bring Gutenberg and WordPress into step

Easy
Low risk
About 15 minutes
Steps tested on WordPress 7.1.3

Every WordPress release includes the editor from one version of the Gutenberg plugin: WordPress 7.1 includes Gutenberg 23.6. Nobody needs the plugin to use the editor. While it is active, the editor's scripts come from the plugin's folder and not from WordPress.

1
Step 1: See whether the plugin is installed
Look for "Gutenberg" on the Plugins screen, or run:

A list with no rows means it is not installed, and this fix does not apply.
bash
```
wp plugin list --name=gutenberg --fields=name,status,version,update
```
Step 2: Update WordPress, Gutenberg and your block plugins
The mismatch is an old Gutenberg on a new WordPress, or a block plugin behind both. The Gutenberg listing on WordPress.org states the oldest WordPress it needs. How to update WordPress safely covers taking a backup first and updating one thing at a time.
3
Step 3: If the editor still fails, switch Gutenberg off
Reload the editor. It is now the one that came with WordPress. If it opens, report the error to the author of the block plugin it named, with both version numbers.
bash
```
wp plugin deactivate gutenberg
```

A test site can show the editor's scripts moving from the plugin's folder back to WordPress's own. Whether the message goes depends on the plugins in your site.

To undo it: Activate the Gutenberg plugin again.

Rule out the theme

Takes care
Back up first
About 20 minutes
Steps tested on WordPress 7.1.3

Step 1: Test with a default theme, for your login only
Do not switch the live theme to test: visitors would see the change. Use the troubleshooting mode described under the plugin fix. It uses a default theme for you alone. If the editor opens there with your plugins switched back on, the theme is the cause.
2
Step 2: Check that theme.json can be read
A theme's theme.json holds its colors, fonts and spacing for the site and the editor. Run this with the theme's folder name:

"No error" means the file is sound. "Syntax error" means it is not valid JSON.
bash
```
wp eval 'json_decode( file_get_contents( "wp-content/themes/theme-folder-name/theme.json" ) ); echo json_last_error_msg(), PHP_EOL;'
```
3
Step 3: Know what a broken theme.json does
WordPress does not stop on it. It passes over the file, so the theme's colors, fonts and spacing go missing from the editor and the site while both still load. With the debug log on, WordPress writes a line like this:

How to turn on WordPress debug mode shows how to switch the log on and off.
text
```
PHP Notice:  wp_json_file_decode(): Error when decoding a JSON file at path /var/www/html/wp-content/themes/theme-folder-name/theme.json: Syntax error
```
4
Step 4: Put a sound copy of the theme back
Upload theme.json again from the theme's original files. For a theme from WordPress.org, the command below fetches the theme again. It replaces every file in the theme's folder, so changes made to those files are lost.
bash
```
wp theme install theme-folder-name --force
```

If the error names a script in the theme's folder and the theme is up to date, report it to the theme's author with the text from "Copy error".

A test site can run the check and fetch the theme again. Troubleshooting mode is a screen in your own browser.

To undo it: Restore the theme folder from your backup.

Rule out your browser

Easy
No risk
About 5 minutes

Step 1: Open the editor in a private window
In Chrome, press Ctrl+Shift+N, or Command+Shift+N on a Mac, and log in again. Extensions do not run in an Incognito window unless you allowed them to, and the window starts without the site data your usual one holds.
Step 2: Try a second browser
WordPress.org's advice is that a fault in one browser only points at that browser or an extension, and a fault in every browser points at a script from a plugin or the theme.
Step 3: If the private window works
Turn your extensions off one at a time in the usual window, starting with ad blockers and privacy tools. If none is the cause, clear the browser's cache for the site. The cache keeps parts of pages, and clearing it gets you the current version.

Stop the dashboard's scripts being combined or delayed

Takes care
Back up first
About 20 minutes
Steps tested on WordPress 7.1.3

1
Step 1: Switch off WordPress's own combining
WordPress joins the dashboard's scripts into one request to load them faster. Its documentation says to try switching that off when JavaScript fails on an administration screen. Add this line to wp-config.php, above the line that says "stop editing":

Reload the editor. If nothing changes, take the line out again.
wp-config.php
```
define( 'CONCATENATE_SCRIPTS', false );
```
Step 2: Switch off an optimization plugin's JavaScript features
Turn off minifying, combining, deferring and delaying of JavaScript together, empty the plugin's cache, and reload the editor. If it opens, switch the features back on one at a time. How to minify CSS and JavaScript in WordPress explains what each one does.
Step 3: Check the CDN
Cloudflare's Rocket Loader defers all of a page's JavaScript until the page has drawn. Cloudflare's own advice for script trouble is to disable it and test again. A Configuration Rule can turn it off for addresses under /wp-admin/ and leave it on for visitors.

A test site can show WordPress sending the scripts one by one once the line is in place. A plugin's or a CDN's feature has to be tested on your own site.

To undo it: Remove the line from wp-config.php, and switch the features back on.

Check that the REST API answers

Takes care
Low risk
About 20 minutes
Steps tested on WordPress 7.1.3

The editor gets its data from the site's REST API, at addresses that begin /wp-json/. WordPress puts the first answers into the page, so a failing API does not by itself stop the editor drawing. Check it when the console lists failed requests to /wp-json/, each with a status such as 403 or 404.

1
Step 1: Ask Site Health
Go to Tools, then Site Health. "The REST API is available" under passed tests means the server reached its own API. Three other results name a fault:
- "The REST API encountered an error": the request got no answer at all.
- "The REST API encountered an unexpected result": the answer had a status other than 200. Open it to read which, on the line that begins "REST API Response:".
- "The REST API did not behave correctly": an answer came, and it was not the JSON expected.
2
Step 2: Ask for the status yourself
From your own computer or over SSH, with your domain:
bash
```
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-json/
```
3
Step 3: Check that the answer is JSON
Over SSH, where PHP is to hand:

"No error" with a status of 200 means the API answers, and it is not your cause.
bash
```
curl -s https://example.com/wp-json/ | php -r 'json_decode( stream_get_contents( STDIN ) ); echo json_last_error_msg(), PHP_EOL;'
```

Result	What it means	What to do
200 and "Syntax error"	Something is printed along with the JSON	"If the answer is not JSON", below
404	WordPress or the web server does not know the address	"If the status is 404", below
403	A rule refused the request	"If the status is 403", below
401	The API wants a login, which this command does not have. A plugin that closes the API to visitors answers this way and still serves the editor	Go by Site Health, which asks as you
500	PHP failed while answering	The critical error page shows how to find the line

If the answer is not JSON. Print the start of it with curl -s https://example.com/wp-json/ | head -c 300 and read what comes before the first {. A PHP message there names a file and a line, and the error message decoder explains it. Anything else was printed by a file as WordPress loaded. This finds the file:

bash

wp eval 'echo headers_sent( $file, $line ) ? "Output started at $file:$line" : "Nothing was printed while WordPress loaded", PHP_EOL;'

Open the file it names at that line and remove what is outside the PHP tags, as "headers already sent" shows. If it is a file of your own in wp-content/mu-plugins, the must-use plugins folder, moving it out switches it off:

bash

mv wp-content/mu-plugins/file-name.php ~/

If the status is 404. WordPress keeps a stored list of the addresses it answers. Rebuild it:

bash

wp rewrite flush

If the 404 stays, the web server is not passing the address to WordPress. "Updating failed" has the fix for a missing .htaccess, and 404 errors on posts and pages that exist has the rest.

If the status is 403. Look for a rule in .htaccess that names the API:

bash

grep -n "wp-json" .htaccess

Download a copy of the file first. Then delete the rule the command found, along with any RewriteCond lines directly above it, which belong to it. If the file holds no such rule, a security plugin or the host's firewall is refusing the request. 403 Forbidden covers both.

A test site can run every command here. Site Health and the editor are screens in your own browser.

To undo it: Move the file back, or put the rule back in .htaccess.

When to get help

Stop when the editor still fails with every plugin off, a default theme and a private window, when the error names only WordPress's own files, or when the one post that fails is a page you cannot afford to rebuild and no earlier revision opens. Stop too if you have unsaved work in the tab and no copy of it yet.

Common questions

Is my content lost?

No. The post as you last saved it is in the database, and the editor failing to draw does not change it. Unsaved typing is at risk only if you close the tab before copying it. The editor also keeps a backup in the tab and offers it when the post next opens there.

Why does "Copy contents" paste nothing?

The button asks the editor for the post when you press it. On WordPress 7.1 the editor has already let go of the post by then, so the answer can be empty. Use the console line or the WP-CLI command in the first fix.

What happened to "Attempt Recovery"?

WordPress 6.1 shows three buttons: "Attempt Recovery", "Copy Post Text" and "Copy Error". WordPress 6.7 shows the last two, and WordPress 7.1 shows "Copy contents" and "Copy error". Where the first button is gone, reloading the page is what is left.

Do visitors see this error?

No. The notice belongs to the editor screen in the dashboard. The pages visitors load are built from the saved content and do not run the editor.

The error names only files in wp-includes. Is WordPress itself broken?

Not usually. The address is where the failure showed, and code from a plugin or the theme often runs inside WordPress's own scripts. Test with every plugin off and a default theme. If it began with a WordPress update, see the runbook for an update that went wrong.

In short

Check that this is the message you have

Read the real error

What not to do

Where it goes wrong

What causes it

A plugin's editor script fails

One post's content trips the fault

The Gutenberg plugin and WordPress are out of step

The theme's editor script fails

A browser extension, or an old copy of a script in the browser

Something combines, defers or delays the dashboard's scripts

The editor's requests to the REST API fail

How to fix it

Step 1: Keep the tab open

Step 2: Press "Copy contents", then look at what you got

Step 3: If the paste is empty and you had unsaved changes

Step 4: Save what the database holds

Step 1: Take the plugin's folder name from the error

Step 2: Deactivate that plugin

Step 3: Reload the editor

Step 4: Update the plugin, or report the error

Step 1: Switch to the Code editor on a post that opens

Step 2: Open the post that fails

Step 3: Find the block and take it out

Step 4: Select "Exit code editor"

Step 1: See whether the plugin is installed

Step 2: Update WordPress, Gutenberg and your block plugins

Step 3: If the editor still fails, switch Gutenberg off

Step 1: Test with a default theme, for your login only

Step 2: Check that theme.json can be read

Step 3: Know what a broken theme.json does

Step 4: Put a sound copy of the theme back

Step 1: Open the editor in a private window

Step 2: Try a second browser

Step 3: If the private window works

Step 1: Switch off WordPress's own combining

Step 2: Switch off an optimization plugin's JavaScript features

Step 3: Check the CDN

Step 1: Ask Site Health

Step 2: Ask for the status yourself

Step 3: Check that the answer is JSON

When to get help

Common questions

More on this subject

Would you rather we fixed it?