WordPress Visual Editor Not Showing: Causes and Fixes

This article is a localized edition of the Japanese original. Read the Japanese original

If the WordPress visual editor is not showing, first check the "Disable the visual editor when writing" setting in the user profile, then suspect JavaScript loading errors (plugin conflicts, caching, or security features blocking requests). This article explains how to tell the symptoms apart in the Classic Editor and the Block editor, and how to check and fix each cause, starting with the most likely.

Before touching configuration files or plugins, back up your site.

Find out which editor is affected

What "the visual editor" means depends on the editing screen you use.

• In the Classic Editor (you use the "Classic Editor" plugin, or the post type does not support the Block editor), the top right of the content box has "Visual" and "Text" tabs. Typical symptoms are a missing "Visual" tab, no toolbar, or a content box that is just a plain text area
• The Block editor normally lets you edit the page as it will look, but the symptoms here are switching to the "Code editor" so that only HTML is shown, a blank white screen, or being stuck on loading

If the Block editor shows only HTML, first open the Options menu (the vertical three-dot icon) at the top right and check whether the editing mode is set to Code editor. A keyboard shortcut can also switch it by accident. If that brings it back, it was a setting, not a bug.

Cause 1: The visual editor is disabled in the profile

If the "Visual" tab is missing in the Classic Editor, the most common cause is a per-user setting. Under "Users" → "Profile" there is a checkbox for turning the visual editor off. At the time of writing it is under the "Visual Editor" item (as of October 2026), but the wording varies by version. When it is checked, only the "Text" tab is available for that user.

If it happens for only one user, suspect this setting. With WP-CLI you can check and change it through the rich_editing user meta.

# Check the setting for user ID 2 (if "false", the visual editor is disabled)
wp user meta get 2 rich_editing

# Turn it back on
wp user meta update 2 rich_editing true

Cause 2: It is disabled by plugin or theme code

If it happens for all users, check whether code is disabling it. WordPress has a user_can_richedit filter that decides whether the visual editor can be used; if it returns false, the visual editor is not shown.

Search your theme and plugin files in one go.

grep -rn "user_can_richedit" wp-content/themes wp-content/plugins wp-content/mu-plugins
grep -rn "use_block_editor_for_post" wp-content/themes wp-content/plugins wp-content/mu-plugins

use_block_editor_for_post and use_block_editor_for_post_type are filters that switch between the Block editor and the Classic Editor. If you get the Classic Editor instead of the Block editor, check these filters and the settings of the "Classic Editor" plugin. For custom post types, the Block editor cannot be used unless the show_in_rest argument of register_post_type is true.

Cause 3: A JavaScript error stops loading

The editor runs on JavaScript, so an error anywhere can stop it from appearing. With the post editing screen open, open your browser's developer tools (F12 in most browsers) and look for red errors in the "Console" tab.

Use these rules of thumb to read the errors.

• If an error contains a path like wp-content/plugins/plugin-name/, that plugin is a suspect
• 404 or Failed to load resource means a script file could not be loaded. Suspect caching or optimization plugins, or a CDN
• 403 may mean that the server or a security feature is blocking the request (Cause 5)

To narrow it down, deactivate plugins one at a time and check after each. If you cannot stop all plugins on a live site, you can use the troubleshooting mode of the "Health Check & Troubleshooting" plugin, which disables plugins for your own login session only. If you cannot get into the admin screen, rename a folder inside wp-content/plugins using FTP or a file manager to deactivate that plugin.

While isolating the problem, temporarily adding the following to wp-config.php makes the admin scripts load without being concatenated or compressed, which makes the location of the error easier to see.

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

If the symptom disappears with these settings, the problem lies in the script concatenation or compression process. When you have finished checking, remove both lines.

Cause 4: Cache or optimization settings affect the admin screen

Some caching and page-speed plugins and CDNs combine, defer or compress JavaScript. These features are meant for public pages, but depending on the settings they can also affect admin scripts and stop the editor from working.

• In the optimization plugin's settings, exclude the admin screens and logged-in users
• If you use a CDN, exclude /wp-admin/ and /wp-includes/ from caching
• After changing settings, clear the plugin, server, CDN and browser caches in that order

If it started right after a WordPress update, old scripts may be left in the cache and conflict with the new core. Clear your browser cache and reload.

Cause 5: The REST API or requests are blocked

The Block editor uses the REST API (URLs starting with /wp-json/) for saving and loading. If a security plugin restricts the REST API, or the server's WAF (a mechanism that defends against unauthorized access) mistakes your content for an attack, the editor may fail to load or show an error when saving.

Here is how to check.

• In the "Network" tab of the developer tools, look at the response codes of requests containing wp-json. If you see 401 or 403, the requests are likely being blocked
• Under "Tools" → "Site Health", check whether there are any warnings about the REST API
• Temporarily turn off your rental server's WAF feature and see whether the symptom changes. If it does, add an exclusion in the server's control panel

Do not leave the WAF turned off; once you have isolated the cause, turn it back on.

Cause 6: Browser-side problems

Ad-blocking or script-control extensions can stop the editor's scripts. If the symptom disappears in a private window (where extensions are disabled) or in a different browser, disable your extensions one at a time to find the cause. The new editor may also fail to run in old browsers, so update your browser to the latest version.

Summary

• First tell whether the symptom is in the Classic Editor or the Block editor. In the Block editor, check that it is not in Code editor mode
• If only one user is affected, suspect the profile setting (rich_editing); if everyone is, suspect filters or plugins
• Use the developer tools Console and Network tabs to check for JavaScript errors and blocked requests
• Exclude the admin screens from optimization plugins and CDNs, and clear the caches
• Handle the WAF and security features with exclusion settings, and do not leave them turned off

• WordPress debugging techniques
• How to fix WordPress plugin conflicts

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)