WordPress Editor Not Working After an Update? Here Is What to Check

You update a WordPress plugin, open a page, and something is wrong. The editor will not scroll. Custom fields look broken. Blocks fail to load. Clicking a button does nothing.

Your first instinct may be to undo the update or start disabling plugins. Before changing anything, collect a few clues. You do not need to understand the code to capture information that can help identify the problem.

The goal is to turn “the editor is broken” into a specific, reproducible issue.

1. Find out how much of the editor is affected

Start by checking whether the problem happens:

• On one existing page or several.
• On a new draft containing only a standard Paragraph block.
• Only on pages containing a particular custom block.
• In another browser.
• For another authorized WordPress user, if someone is available to test.

Use a test draft, and avoid saving changes to an existing page while its blocks are malfunctioning.

These comparisons help narrow the investigation. If standard blocks work but pages with custom blocks fail, the custom functionality deserves closer attention. If only one browser has the problem, investigate that browser before changing the website.

Write down the exact action that triggers the failure. “Open the About page, select the team block, and the editor stops responding” is much more useful than “WordPress is glitchy.”

2. Capture the browser error

WordPress editor problems often leave messages in the browser’s Console, a panel that displays errors and other technical information.

In Chrome:

1. Open the affected editor page.
2. Press Ctrl + Shift + J on Windows or Command + Option + J on a Mac.
3. Clear old messages, then reload the page with the Console open.
4. Repeat the action that causes the problem.
5. Find the first relevant red error. Expand it using the arrow beside the message.
6. Copy the error text and the expanded details, or take a readable screenshot.

If navigation makes the messages disappear, enable Preserve log in Console settings. The expanded details are called a stack trace: they show the sequence of function calls leading to the error. See the Chrome Console documentation for more information.

You are inspecting messages here. You do not need to paste or execute code in the Console.

What does an error actually tell you?

During a recent editor investigation, I encountered an error like this:

TypeError: cannot access property "buttons", i is undefined

The associated script was:

acf-input.min.js

In plain English, the script tried to read a property called buttons from something that was not available.

The filename pointed toward Advanced Custom Fields as a useful starting point. It did not prove that ACF alone caused the problem. Another script, missing dependency, or unexpected configuration could have contributed.

Capture the complete file path, line number, and expanded trace where available. A filename without its surrounding context can leave out the most useful clue.

Also remember that one failure can trigger several later errors. Start with the earliest error associated with reproducing the problem, while recognizing that not every red message is relevant.

3. Check whether a file or request failed to load

Sometimes the editor breaks because it cannot load a required script or receive data from the server.

In the same developer tools window:

1. Select Network.
2. Reload the editor.
3. Repeat the action that fails.
4. Look for unsuccessful requests in the Status column.
5. Select one and inspect Headers and Response.

Record the request URL, status code, and relevant error message. Chrome’s Network panel records requests while developer tools are open and lets you inspect individual responses. See Chrome’s guide to inspecting network activity.

These findings suggest different next steps:

These are investigative leads, not diagnoses. For example, a 403 response does not automatically mean your security plugin is responsible.

Before sharing screenshots or copied responses, remove passwords, tokens, cookies, and private customer information.

4. Rule out a browser-specific problem

Try the same editing action in another browser or a clean browser profile.

A private window can also help, but verify that extensions are not allowed to run there. Log in normally and test the same page and action.

If the editor works in the clean session, investigate extensions, browser storage, and cached files. Disable extensions individually and retest instead of changing several things at once.

A browser-only failure does not establish which extension or setting caused it. It gives you a smaller area to investigate.

If the problem occurs across browsers, continue with the website itself.

5. Test plugin changes on a staging copy

A staging site is a separate copy where you can investigate without changing what visitors experience. Confirm that you have a current backup of both the files and database before making changes.

WordPress recommends staging for troubleshooting plugin and theme issues. Its conflict-testing guidance uses controlled deactivation and reactivation to narrow down the source.

On staging:

1. Confirm that the original problem happens there.
2. Record the active plugins and their versions.
3. Start with a recently changed plugin that is not required for the feature you are testing.
4. Deactivate it, reload the editor, and repeat the same action.
5. Record the result.
6. Restore it before testing another plugin.

Keep a simple record:

That repeatable result is stronger evidence than a single successful reload.

Do not confuse removing a feature with fixing it. If disabling ACF also removes the custom block you were testing, the disappearance of the error does not demonstrate that the block works correctly.

For a broader isolation test, preserve the dependencies required to reproduce the issue. If the custom build makes those dependencies unclear, that is a good point to involve its developer.

6. Check for code outside the normal plugin list

Some custom WordPress sites load functionality through must-use plugins, often called MU-plugins.

These appear in a separate Must-Use section on the Plugins screen. They load automatically and cannot be disabled through the normal plugin controls. Consequently, deactivating ordinary plugins does not rule out all plugin code. Read more in the WordPress documentation on must-use plugins.

This mattered in the ACF investigation I mentioned earlier. ACF was loaded through a custom MU-plugin setup.

On a development copy, moving ACF into a regular plugin installation and testing a newer version caused Gutenberg to stop recognizing the custom blocks. The field-group JSON files were still present, but that did not prove the block registration code was running correctly.

That shifted the investigation toward specific questions:

• Is the custom loader still pointing to the correct location?
• Is the block registration code executing?
• Is ACF available when that code runs?
• Are custom field-group paths still correct?
• Could the old loader and the regular plugin both be attempting to load ACF?

Those questions guide inspection; they are not confirmed explanations for the original failure.

If you see a Must-Use section, include it in your support notes. Do not move or delete those files casually: they may contain hosting integrations or essential site functionality.

7. Turn your findings into a useful help request

You do not need to solve the problem before asking for help. You need enough information to make the next step more precise.

Find version and environment information under Tools → Site Health → Info. WordPress provides details about the installation, themes, plugins, and server, along with an option to copy the information. Review it before sharing and include only what is relevant. See the WordPress Site Health documentation.

Use this template when contacting a developer or asking an AI assistant:

I need help investigating a WordPress editor problem.

Problem:
[Describe exactly what stops working.]

Steps to reproduce:
1.
2.
3.

Scope:
[One page or all pages? Standard blocks or custom blocks?
Does it happen in another browser?]

Recent changes:
[Plugin, theme, WordPress, hosting, or custom-code changes.
Include dates and previous/current versions if known.]

Environment:
WordPress:
PHP:
Theme:
Relevant plugins and versions:
Must-use plugins, if present:

Console error:
[Paste the exact error and relevant expanded stack trace.]

Failed Network request:
[URL or path, status code, and sanitized response message.]

Tests already performed:
[One change per line, with the result.]

Please separate confirmed findings from possible causes.
Suggest the next low-risk diagnostic step and explain
what each possible result would tell us.
Do not suggest a code patch without identifying what
evidence supports it.

AI can help interpret an error and organize possible causes. Treat its explanation as a hypothesis until a controlled test supports it. A suggested code change should be reviewed and tested on staging before being applied to the live site.

Need help getting the editor working again?

If the issue involves custom blocks, MU-plugins, or errors you cannot confidently interpret, send me the details you collected.

The affected page, steps to reproduce the problem, exact error, and recent changes give me a useful starting point. Even partial findings can reduce the time spent reconstructing what happened.

I can help investigate your WordPress editor and work through the repair.