Blank WordPress editor: restore editing when the public site still works

Distinguish a blank editor from missing content

Your public pages display, but opening a post to edit it produces a large white area, an incomplete interface or a loading process that never finishes. The goal is a usable interface that can retrieve and save the right document. A visible public page does not guarantee that every administration function responds.

Start from Posts or Pages in the dashboard of the correct site. Open a known document and record its title and editing address. An old bookmark may point to another site, a test environment or an action that is no longer available. Do not directly change address parameters to try random documents.

Identify what is missing: the whole page, only the writing area, the toolbar or the sidebar. An interface without a panel may reflect a display preference; an empty post in a working editor is a content issue. If you see a critical error or JSON response message, keep it: it calls for a more specific diagnosis than the screen color alone.

Preserve your text before reloading

Keep any tab containing useful writing open. Copy the title, accessible text and links into a local document without overwriting an older copy. If the editor menu still works, its Copy all content command may help; check that the copy includes both the start and the end of the document.

A screenshot records the layout and message but does not back up blocks or media. Do not immediately clear browser data: it may contain work that has not been transmitted. Preserve what exists before trying to reset a session.

Before changing a component or configuration, request a suitable recoverable backup including the database and files. Also record the active theme and plugins. An old backup is no reason to replace the whole site over an editing problem: newer public content, comments or orders could be lost.

If you only have writing permissions, limit yourself to observations and your copies. Hosting or appearance access requires a separately authorized intervention.

Compare the document, account and environment

Without changing the content, try a second saved post, then open a simple draft. Record whether the failure affects every document or only one. An editor that works for simple text but fails on a particular post provides a clue about its content or the tools involved.

Next compare with another up-to-date browser or a separate profile, using your own authorized account. A private window may help, but its cookie and embedded-service rules sometimes differ. Its result therefore does not prove that the first browser is faulty.

If an authorized colleague can check with their own account, record only the result and the role involved. Do not share credentials. A difference between accounts may come from permissions, preferences or a component loaded for a particular role; it does not justify making every writer an administrator.

Finally, record whether this is self-hosted WordPress or WordPress.com, the version, the editor actually used and the last known change. Observe the public page and the administration area separately, at the same time.

On WordPress.com, browser checks remain possible; copy, plugin and file tools depend on your plan’s access. If you cannot access wp-config.php, skip the file route and use platform support. In multisite, the network administrator controls plugins and some themes: have that person prepare the test instead of changing every site.

Choose the route that produces evidence

The first approach concerns a browser or interface that fails to load. It compares a clean profile, visible preferences and received resources without changing the site. Start here when you are the only person affected.

The second examines requests sent to the server. It becomes relevant when several browsers fail, a resource does not arrive or the console reports an unexpected response. The goal is to identify the exact request that needs explaining, not to remove every server restriction.

The third isolates a theme, plugin or optimization on a test copy. Use it when the failure follows a change or observations point to a component. A staging copy must be separate from the live site and configured correctly; otherwise it may introduce a different failure.

For each test, keep one sentence recording the action, result and return to the previous state. If no observation supports a change, move to a documented support request instead of accumulating configuration changes.

Approach 1: restore a usable interface and browser

This approach requires your normal editor and browser access. It suits failures specific to a profile or hidden panels. The expected result is loading the same document and then verifying a saved draft. Keep your preserved text and restore browser preferences or exceptions after comparison.

1. When text or controls remain visible, first check the editor menu. View modes and the settings button can hide tools. In interfaces that offer it, the three-dot menu followed by Preferences provides these options. Restore only the one that explains the missing panel.
2. If the entire area remains blank, open the same document in the comparison browser. A successful result provides temporary access to your work after you verify the document and its saved state. It does not yet resolve the cause in the first browser.
3. In the original browser, examine extensions that filter scripts for this domain. If a temporary exception is authorized and justified, limit it to the site and restore it after the test. Avoid disabling protection globally for every site.
4. After preserving your work, test the cache without clearing data: in Chrome, open developer tools, then Network, select Disable cache and reload the same editor once. Clear that option afterward. If the interface returns, a cached resource is a lead to investigate. Do not delete passwords or all browser data; if the problem persists, record errors before another test.

Read the console without executing code

View the console in your own authorized session without file access. Look for the first useful message during the same load, including its file and line. Closing the tools ends the observation; no command needs to run in this console.

1. Open the browser’s developer tools, then Console. In many desktop browsers, F12 opens these tools; use the browser menu if this shortcut is unavailable. After preserving your text, reload the affected screen once and record the first errors related to opening it.
2. Copy the message, filename, line and test time. Several errors may follow an initial failure. A WordPress library name in the list does not prove that library caused the original problem: a missing dependency or replaced response can trigger the rest.
3. Do not paste any command into the console to make the editor appear. Reading messages is enough at this stage. Code presented as a quick fix could act with your session’s permissions.
4. Before sharing a screenshot, remove private content, login parameters and identifying information. Providing the full message useful for diagnosis does not mean exporting the whole session without review. If the console remains empty, record that and inspect the network; no red message does not prove all requests succeeded.

Approach 2: identify the request that fails

This route is for readers who can open browser tools with their usual account. The expected result is a precisely identified request and its response; no replay or header changes are needed.

1. In developer tools, open Network. Keep the panel open while the editor loads: it records requests made at that moment. Look for failed resources and unexpected responses, starting with opening the document.
2. Select a request and record its address without sensitive parameters, its type, response code and returned content. A JavaScript resource lets the browser run part of the interface; a data request loads the document or settings. They cannot be diagnosed solely by the same error number.
3. A response reported as successful may contain a login or protection page instead of the expected resource. Examine its content, not just the row color. Conversely, a warning about an image unrelated to the editor does not prove the cause of the white area.
4. Do not replay requests or change their headers. Observing one identifiable load already produces useful evidence. If you cannot interpret the response, send the recorded details to the technical administrator instead of attempting a global fix.

Distinguish session problems, data and a missing file

Loading a public REST route does not prove that an authenticated editor request succeeds. The REST API is the interface through which WordPress exchanges data; private operations require an appropriate session and permissions, among other things. An old tab may display an interface even though its authentication context is no longer usable.

After copying your work, start again from the dashboard and establish a normal session if necessary. Retry the same document without reusing an old temporary link. If the failure disappears, also check saving a draft. Do not manufacture a token or replace cookies to force the request.

A missing resource after an update requires checking its address, deployment and relevant caches. A denied response requires distinguishing WordPress, a protection service and hosting. A server failure calls for the corresponding logs. The code alone cannot distinguish these causes.

If the exact message reports an invalid JSON response while saving, continue with that specific troubleshooting process. Here, the goal remains restoring editor loading without treating every white screen as a permalink problem.

Fix an identified optimization: the Rocket Loader example

Use this example only if the site already uses Cloudflare and the observed load shows Rocket Loader involved on the affected screen. This service defers script execution; that does not prove every site optimization changes administration pages. If Cloudflare is not used or the option is already inactive for this address, keep that finding and examine another lead.

The procedure requires authorized access to the domain’s rules. Test on a copy that actually uses the same service. Preserve the initial state and existing rules; the goal is to disable only Rocket Loader for the identified context without changing the firewall, authentication or TLS level. The hostname must already use the Cloudflare proxy for the rule to act. Do not change its DNS solely for this diagnosis. Also check that a later rule does not turn Rocket Loader back On for the same screen.

The expected result is loading and saving the same draft, with the observed request now correct. If the test changes nothing, disable only the added rule. Rocket Loader does not provide a generated-file directory to delete in WordPress here: do not empty server folders. If another identified optimization has a generated cache, use its documented command and check its scope.

Replace preprod.exemple.fr with the copy’s hostname, without a protocol or path. Adapt /wp-admin/ if WordPress is in a subdirectory, for example /blog/wp-admin/. Do not deploy the example unchanged.

1. In the domain’s Cloudflare dashboard, open Speed, Settings, Content Optimization to record the Rocket Loader state.
2. Open Rules, Overview, then Create rule, Configuration Rule.
3. Give it an identifiable name, choose a custom filter and enter the adapted expression below.
4. Under Then the settings are, add only Rocket Loader and set it to Off, then deploy the rule after checking the domain and path.
5. Reload the same screen on the copy once and repeat the console, network and draft checks.
6. If the test fails, disable this rule; if it succeeds, have this targeted correction validated before applying it to the live site.

(http.host eq "preprod.exemple.fr" and starts_with(http.request.uri.path, "/wp-admin/"))

Approach 3: isolate a component on a copy

This approach requires a separate copy and permissions to manage components. The expected result is a reproducible comparison of the same document with only one element changed. Roll back by restoring the original component or theme without replacing production with the copy.

1. Prepare staging with help from the host or site administrator. Confirm that it uses its own database, is protected and will not trigger email, integrations or other external effects for real recipients. Keep a production backup before considering applying a fix there.
2. First reproduce the problem on this copy using the same document type and role. If the problem is absent there, compare versions, domain, intermediary services and active components. A working copy does not prove production should be replaced with its content.
3. Start with the component associated with the last change or first relevant error. Deactivate it normally under Plugins, test opening the document, then reactivate it before the next test. Do not delete it: its data or settings may be needed. If a block depends on it, do not inadvertently save a post whose structure changed while it was absent.
4. If the theme needs comparing, run a separate test on the copy. Record the active theme and its settings before changing it. A different result locates an interaction; you still need to identify an appropriate fix, restore the original state and validate only that fix.

Optional: Troubleshooting in a dedicated session

Troubleshooting, by Marius L. J., known as Clorith, provides the troubleshooting mode separated from Health Check. The official listing consulted on November 13, 2026 reports free version 1.0.2, requiring at least WordPress 6.4 and PHP 7.2, and declared testing through WordPress 7.1.4. Check these requirements before installation; declared compatibility does not guarantee every component combination, and an old PHP minimum is not a security recommendation.

This option requires installation and configuration permissions. It aims to change components for your session but does not create an independent database, disable outgoing messages or deactivate mandatory plugins known as mu-plugins. Caches can also interfere with its isolation. Prefer a copy; if you use this mode on the live site, limit yourself to a simple draft and also check a separate visit.

The expected result is first restoring the interface, then identifying the combination that makes it disappear. The mode does not fix the component itself. To return to the normal context, use Disable Troubleshooting Mode in its panel or the administration bar; logging out also ends the troubleshooting session.

1. Under Plugins, Add New Plugin, search for Troubleshooting; check the author and directory link with slug troubleshooting, then install and activate it if the environment is compatible.
2. Open Tools, Site Health, the Troubleshooting tab, and click Enable Troubleshooting Mode after reading the instructions.
3. Open a simple draft: check that the editing area loads, then save a short sentence and reopen the draft. If the screen remains blank even with this baseline, do not keep activating components; return to console and network evidence.
4. In the administration bar’s Troubleshooting Mode menu, reactivate the theme and then plugins for your session, one element at a time. Check opening the document after each. If the original document contains blocks from a plugin still inactive, observe it without saving it in this incomplete state.
5. Record when the failure returns, then exit with Disable Troubleshooting Mode.
6. Check the normal context, component list and a separate visit; if an old display persists, check the existing cache through its documented procedure.

Diagnose core scripts with SCRIPT_DEBUG on a copy

If the first error points to a core script and its compressed version makes diagnosis difficult, SCRIPT_DEBUG loads development versions of core CSS and JavaScript files. This diagnosis requires authorized access to the copy’s files through SFTP or the hosting file manager.

It does not disable every plugin optimization and does not fix JavaScript by itself. A changed result is information to retain. For a PHP error, consult private hosting logs or prepare a separate PHP diagnosis; this script setting does not replace collecting them.

Open the copy’s wp-config.php file, usually at the root of that installation. Look for an existing definition before adding one. Place the code below before WordPress loads, above the That's all, stop editing! comment when present, and before the inclusion of wp-settings.php. Boolean values do not take quotation marks.

The expected result is a more precisely located error or a confirmed difference during the same load, followed by a verified draft save. After collecting evidence, restore the original value or absence of the definition. If a syntax error makes the copy inaccessible, restore only the preserved file through your file access.

1. Download a private copy of the original wp-config.php; do not leave a backup containing its secrets in the public directory.
2. Search for SCRIPT_DEBUG. Modify its single definition if present; otherwise add the line below at the indicated location.
3. Save, then open Console and Network in the test browser; reload the document once.
4. Record the first relevant message, file and line, then check a draft if the interface returns.
5. Restore the original configuration and check loading again; retain only useful excerpts privately.

define( 'SCRIPT_DEBUG', true );

Confirm that editing fully works before resuming

After the fix, reopen the affected document and a simple draft. Check controls, block selection, typing and the media library. In the draft, add a short identifiable change, save and reopen the document. The text must be present in the version actually retained.

Check the original browser with its normal protections, then the comparison browser. A repair must not depend on a forgotten temporary security exception. If a request kept failing during the incident, also verify its result after the fix.

The old classic editor, when already present, may offer a different way in. Do not install it to declare the failure resolved or convert all content during diagnosis. Specific blocks and document features need checking before any lasting change of editing method.

Finally examine a representative public page and important functions related to the corrected component. Restore necessary tools, remove temporary diagnostics and retain local copies until validation. If the editor loads but does not retain changes, record this new symptom: the display is back, but your work is not yet secure.

Provide a support record that allows further investigation

If the failure persists, assemble the observed scope, versions, role, compared browsers and last known change. Add the first relevant error and details of the failing request, with a precise time. Also list tests that were returned to their original state.

Ask support for a targeted check: a missing file, replaced response, session rejection or component interaction, depending on the evidence available. Do not send cookies, tokens or an unredacted full network export. For a confidential post, first provide an authorized minimal case or protected copy.

Prevention means checking opening and saving after changes affecting the editor, then keeping an external copy of important writing. A working public page does not replace this administration check. Record the cause actually demonstrated and the corrected setting; if the cause remains unknown, retain that qualification instead of attributing the repair to the last click.

Connect the first JavaScript error to its network response

An error such as Unexpected token < in a script calls for examining the received response before modifying JavaScript. The character may come from the start of an HTML page returned instead of the expected file: a login, protection, server-error or not-found page. This message alone does not establish which case occurred.

In Network, select the file named by the first error, then view Headers and Response. Record its URL without private data, status, declared content type and a few words identifying the nature of the response. A 200 status accompanied by an HTML page is still incorrect for an expected script. The Initiator column helps identify the component that requested this file; it does not automatically establish responsibility.

Next compare that same file in a context where the editor works, if available. You can then request a targeted routing, deployment or cache-exception fix. Do not grant general access to administration routes to bypass a protection response.

This observation uses free browser tools and does not change the site. After the fix, reload once, check that the expected script is received, then open and save a simple draft. Do not conclude solely from the disappearance of the first message: a later error may still prevent editing.