The editor can remain blank, show ‘Updating failed,’ or spin forever. The visual symptom may come from a JavaScript exception, failed REST request, invalid JSON caused by PHP output, or blocked asset.
The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you use the browser console, network panel, REST responses, SCRIPT_DEBUG, and plugin isolation to locate the first editor failure.
Read the failure at the right layer
- A plugin or theme JavaScript exception stops editor initialization.
- The REST request is rejected, redirected, cached, or contaminated by warnings before JSON.
- Optimization combines or delays scripts in an order the editor does not support.
The branches are ordered to protect the strongest evidence around this possibility: a plugin or theme JavaScript exception stops editor initialization. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
The editor is a JavaScript application backed by WordPress REST endpoints; a blank panel may begin in PHP, HTTP, JSON, JavaScript, or a browser extension, so the first failed network request and first console exception matter more than the final spinner; in this guide, the practical goal is to use the browser console, network panel, REST responses, SCRIPT_DEBUG, and plugin isolation to locate the first editor failure.
Build a clean diagnostic record
- Reproduce in a clean browser profile and record the first console error, not the cascade after it.
- Inspect failed fetch/XHR requests and open their response body and status.
- On staging, enable SCRIPT_DEBUG and compare behavior with optimization disabled.
- Check PHP logs for warnings emitted during REST requests.
The sequence moves from observation toward intervention. Preserve the result of the final check—check PHP logs for warnings emitted during REST requests—because it provides a useful comparison after the repair.
From first observation to a reversible decision
Treat “A plugin or theme JavaScript exception stops editor initialization” as a working hypothesis, not a conclusion. Establish a baseline first: reproduce in a clean browser profile and record the first console error, not the cascade after it. Record both the result you expected and the result you actually saw.
A supporting result justifies a staging test of the narrowest repair: update, isolate, or patch the component named by the first stack frame or failed asset. A result that contradicts “A plugin or theme JavaScript exception stops editor initialization” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.
Load readable WordPress scripts on staging
Add this temporary constant above the stop-editing line in wp-config.php, then reproduce with DevTools Console and Network panels open.
define( 'SCRIPT_DEBUG', true );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Interpretation and safety: Record the first exception and first failed REST request, not the cascade. Remove the temporary settings after diagnosis.
Repair the cause—not the message
- Update, isolate, or patch the component named by the first stack frame or failed asset.
- Restore valid REST authentication and pure JSON responses.
- Exclude WordPress editor assets from unsafe combine/defer transformations.
Before applying “Update, isolate, or patch the component named by the first stack frame or failed asset,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can create, save, preview, revise, and autosave a test post; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Verification checklist
- Create, save, preview, revise, and autosave a test post.
- Test the roles and custom blocks used by the site.
- Confirm console and network panels stay clear of new failures.
One successful refresh is not closure. Keep the incident open until you can also test the roles and custom blocks used by the site, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
A support report should name the browser, clean-profile result, user role, editor action, post type, REST status/body, console stack, and exact plugin/theme versions; replace private post content with a minimal test record when possible; include the result of this first observation: reproduce in a clean browser profile and record the first console error, not the cascade after it.
State what was tested, including the result of “Reproduce in a clean browser profile and record the first console error, not the cascade after it,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Tempting moves to avoid
- Do not paste a minified stack trace without its source file and triggering action.
- Do not leave SCRIPT_DEBUG enabled as a performance workaround.
Operator record
Primary references
- WordPress JavaScript debugging — official reference consulted for this guide.
- WordPress REST FAQ — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Update, isolate, or patch the component named by the first stack frame or failed asset”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.