How to Bring Back the Classic WordPress Editor

If you want to bring back the Classic WordPress Editor, you do not need to downgrade WordPress or install an old WordPress release.

Modern WordPress still provides the underlying classic editing screen, and there are several ways to make WordPress use it instead of the Block Editor.

You can:

• install the official Classic Editor plugin;
• disable the Block Editor programmatically;
• disable it only for selected post types;
• use a plugin such as TheOneWP to control the editor without maintaining custom code.

The important part is understanding exactly what you are changing.

Restoring the Classic Editor changes the editing interface. It does not automatically convert existing block content, remove Gutenberg-related frontend CSS, convert a block theme into a classic theme or disable every block-based feature in WordPress.

If you are still deciding which editing experience is appropriate for your project, start with Block Editor vs. Classic Editor: Which Fits Your Site?.

If you already know that your project needs the traditional editing interface, this guide explains the safest ways to restore it.

What happened to the Classic WordPress Editor?

WordPress did not simply remove the old editor when Gutenberg arrived.

WordPress 5.0, released in December 2018, made the Block Editor the default editing experience for posts and pages.

The official WordPress Block Editor documentation confirms that the Block Editor replaced the Classic Editor as the default editor beginning with WordPress 5.0.

The default workflow changed from:

Post
↓
Classic Editor
↓
TinyMCE content area

to:

Post
↓
Block Editor
↓
Individual content blocks

But WordPress still supports classic editing workflows.

What does “bring back the Classic Editor” actually mean?

Usually it means that instead of opening a post or page inside the Block Editor, WordPress should open the traditional editing screen.

The Block Editor typically presents content as:

Heading block
Paragraph block
Image block
Buttons block
Group block

The Classic Editor instead presents the main content as one traditional rich-text editing area.

The official WordPress Classic Editor documentation describes this traditional post-editing workflow.

Method 1: install the official Classic Editor plugin

The simplest official method is the Classic Editor plugin maintained on WordPress.org.

The plugin restores the previous WordPress editor and traditional Edit Post screen.

Install Classic Editor from WordPress

From the WordPress administration area:

1. Go to Plugins → Add New Plugin.
2. Search for Classic Editor.
3. Locate the official Classic Editor plugin.
4. Click Install Now.
5. Activate the plugin.

Once activated, WordPress can use the traditional editing interface instead of the Block Editor.

What the official Classic Editor plugin changes

The plugin is designed specifically to restore the previous WordPress editing experience.

This is useful when a site depends on:

• the traditional TinyMCE editor;
• legacy editor plugins;
• classic metaboxes;
• older editorial workflows;
• shortcode-based content;
• custom integrations built around the classic Edit Post screen.

The Classic Editor plugin can support mixed workflows

You do not necessarily have to choose one editor permanently for every user and every piece of content.

The Classic Editor plugin includes settings that can allow users to switch between editing experiences where appropriate.

This can be useful during a gradual migration.

For example:

Historical content
→ Classic Editor

New content
→ Block Editor

or while evaluating whether existing content behaves correctly in both environments.

Method 2: disable the Block Editor with PHP

Developers can also control whether WordPress uses the Block Editor through native WordPress filters.

WordPress provides the:

use_block_editor_for_post_type

filter.

The official use_block_editor_for_post_type documentation explains that the filter controls whether a post type can be edited with the Block Editor.

To disable the Block Editor for compatible post types, you can use:

add_filter(
    'use_block_editor_for_post_type',
    '__return_false'
);

WordPress will then fall back to the traditional editing screen for those post types.

Where should this code go?

A persistent administration policy normally belongs in a plugin rather than a theme.

Possible locations include:

• a small custom plugin;
• a site-specific functionality plugin;
• a must-use plugin;
• a trusted code-management system.

Adding this behavior to functions.php can work technically, but it couples an editorial workflow decision to the active theme.

If the theme changes, the behavior may disappear.

For long-lived configuration across client sites, see Standardizing WordPress Configuration Across Client Sites.

Method 3: disable the Block Editor only for specific post types

Disabling Gutenberg globally is not always necessary.

A WordPress site might legitimately use:

Posts
→ Block Editor

Pages
→ Block Editor

Legacy content
→ Classic Editor

Products
→ existing product workflow

The use_block_editor_for_post_type filter receives the post type being evaluated, which means you can make the decision selectively.

For example, to disable the Block Editor only for pages:

add_filter(
    'use_block_editor_for_post_type',
    function ( $use_block_editor, $post_type ) {
        if ( 'page' === $post_type ) {
            return false;
        }

        return $use_block_editor;
    },
    10,
    2
);

Posts can continue using the Block Editor while pages use the traditional editor.

Disable the Block Editor for multiple post types

You can also define several post types:

add_filter(
    'use_block_editor_for_post_type',
    function ( $use_block_editor, $post_type ) {
        $classic_post_types = array(
            'page',
            'project',
            'documentation',
        );

        if ( in_array( $post_type, $classic_post_types, true ) ) {
            return false;
        }

        return $use_block_editor;
    },
    10,
    2
);

This provides much more control than globally disabling Gutenberg.

WordPress checks whether a post type can use the Block Editor

WordPress core provides the use_block_editor_for_post_type() function to determine whether a post type is compatible with the Block Editor.

Current WordPress core checks several conditions.

The post type must:

• exist;
• support the editor feature;
• be exposed through the REST API with show_in_rest.

If those requirements are satisfied, WordPress then applies the use_block_editor_for_post_type filter.

Why the REST API matters

The Block Editor depends on WordPress REST API infrastructure.

This is why use_block_editor_for_post_type() checks:

$post_type_object->show_in_rest

A custom post type that is not exposed through the REST API cannot normally use the Block Editor.

This relationship is important when building or debugging custom post types.

If you are modifying REST API behavior elsewhere on the site, see What Depends on the WordPress REST API before applying broad restrictions.

You can also control the editor for individual posts

WordPress provides another filter:

use_block_editor_for_post

The official use_block_editor_for_post() documentation shows that WordPress first evaluates the post type and then applies the per-post filter.

This makes more specific rules possible.

For example, a plugin could theoretically decide that certain individual posts should use the classic editing experience while others use the Block Editor.

For most sites, however, post-type-level rules are easier to understand and maintain.

Method 4: use TheOneWP Disable Gutenberg

If you do not want to install a separate Classic Editor plugin or maintain custom PHP filters, TheOneWP Disable Gutenberg provides editor controls directly within TheOneWP.

The module can disable the Block Editor:

• globally;
• for selected post types.

This makes it possible to build configurations such as:

Posts
Block Editor ✓

Pages
Block Editor ✕

Projects
Block Editor ✕

Products
existing WooCommerce workflow

without adding custom PHP for each project.

When disabling Gutenberg globally makes sense

A global Classic Editor configuration may be appropriate when the entire site was deliberately built around a traditional editing architecture.

Examples include sites that rely heavily on:

• legacy TinyMCE extensions;
• classic metaboxes;
• custom fields;
• shortcodes;
• fixed theme templates;
• older page builders;
• client workflows built around the classic interface.

When disabling Gutenberg globally is unnecessary

Many sites only need the Classic Editor in one area.

Imagine a site containing:

Blog posts
→ modern Block Editor

Landing pages
→ Block Editor

Properties
→ custom fields + Classic Editor

Legacy documentation
→ Classic Editor

Disabling Gutenberg everywhere would remove useful functionality from content types that actually benefit from blocks.

Custom post types are a strong reason to use selective control

Different custom post types can have completely different editing requirements.

A portfolio project may need:

• rich text;
• images;
• columns;
• custom blocks;
• patterns.

The Block Editor may be ideal.

An internal record type may instead contain:

Title
Client
Status
Reference number
Date
Notes

Most of its interface may be custom fields, making a full block canvas unnecessary.

WordPress lets developers control which editor features each post type supports through functions such as add_post_type_support().

What happens to existing block content?

This is one of the most important questions before restoring the Classic Editor.

Changing the editor does not automatically mean WordPress rewrites every post in the database.

Block Editor content is normally stored inside post_content using HTML and block delimiters.

For example:

<!-- wp:paragraph -->
<p>Example paragraph.</p>
<!-- /wp:paragraph -->

Changing which editor opens the post does not inherently erase that stored content.

However, editing block-generated markup through a different editor can affect structure, comments, custom block markup or formatting depending on the content involved.

For the full migration implications, see Does Switching WordPress Editors Affect Your Content?.

Do not test editor switching on important production content first

If an existing site already contains substantial Block Editor content, test the change on staging.

A representative test should include:

• simple posts;
• long-form posts;
• nested blocks;
• columns;
• groups;
• galleries;
• custom blocks;
• shortcodes;
• Custom HTML blocks;
• plugin-specific blocks;
• reusable or synced content.

See WordPress Staging Site Best Practices for a safer testing workflow.

What is the Classic block?

If your main problem is that you prefer the traditional writing interface, you may not need to disable the Block Editor at all.

WordPress includes a Classic block.

The official Classic block documentation describes it as a block that provides an editing experience similar to the Classic Editor.

It includes the traditional editing toolbar inside the Block Editor.

The Classic block is not the same as restoring the Classic Editor

These are two different configurations.

Classic block
→ Block Editor is still active
→ one block uses classic-style editing

Classic Editor
→ Block Editor is not used for that editing screen
→ traditional Edit Post interface is used

If you only need traditional rich-text controls for one area of a post, the Classic block may be sufficient.

The Classic block can convert content into blocks

WordPress provides a:

Convert to blocks

option for Classic blocks.

This can be useful when gradually migrating older content into native blocks.

Instead of converting thousands of historical posts at once, you can migrate selected content when it is actually edited.

Classic Editor and old metaboxes

One common reason for restoring the Classic Editor is compatibility with older metabox implementations.

Before Gutenberg, plugins frequently extended the post editing screen through PHP metaboxes.

The Block Editor supports many traditional metaboxes for backward compatibility.

The official WordPress Block Editor Meta Boxes documentation explains that most existing metaboxes can continue to work, although WordPress recommends modernizing older implementations where appropriate.

Some metaboxes can explicitly declare Block Editor incompatibility

WordPress provides compatibility mechanisms for legacy metaboxes.

A metabox that cannot work correctly with the Block Editor can declare:

__block_editor_compatible_meta_box

as false in its arguments.

For example:

add_meta_box(
    'legacy-settings',
    'Legacy Settings',
    'legacy_settings_callback',
    null,
    'normal',
    'high',
    array(
        '__block_editor_compatible_meta_box' => false,
    )
);

WordPress can then identify the compatibility problem rather than silently presenting a broken editing experience.

Do not restore Classic Editor just because a metabox exists

The presence of traditional metaboxes does not automatically mean Gutenberg is incompatible.

Many existing metaboxes work inside modern WordPress.

Test the actual plugin before making a site-wide editor decision.

Classic Editor and page builders

Page builders are another common reason for disabling Gutenberg on selected content types.

A site may use:

Pages
→ page builder

Posts
→ Block Editor

or:

Pages
→ page builder

Posts
→ Classic Editor

If a page builder completely controls page layout, displaying the Block Editor for pages may add an unnecessary second editing system.

Do not confuse Gutenberg with your page builder

Disabling the Block Editor does not automatically disable Elementor, Bricks, Divi, Beaver Builder or another independent page-building system.

These tools have their own editing architecture.

The relevant question is whether the native WordPress editor is part of the workflow for that post type.

Classic Editor and block themes require extra caution

A block theme uses blocks for much more than ordinary post content.

Block themes can use blocks for:

• templates;
• headers;
• footers;
• navigation;
• template parts;
• site-wide design.

The official WordPress block theme documentation explains this broader architecture.

If the site uses a block theme, globally trying to remove every block-based WordPress system is fundamentally different from choosing the Classic Editor for post content.

For the architecture behind these systems, see WordPress Full Site Editing and Block Widgets, Explained.

Classic Editor does not convert a block theme into a classic theme

This distinction is essential.

These are separate layers:

Content editor
→ Block Editor or Classic Editor

Theme architecture
→ classic theme or block theme

Changing one does not automatically change the other.

Does bringing back Classic Editor improve performance?

Not necessarily.

The Classic Editor may make the administration interface simpler for your workflow, but changing the editor does not automatically optimize the public website.

Your frontend can still load:

• block CSS;
• theme CSS;
• plugin CSS;
• JavaScript;
• fonts;
• page-builder assets;
• third-party scripts.

Disabling Gutenberg and removing block assets are different things

This distinction prevents a common optimization mistake.

Disable Gutenberg
≠
Remove block frontend assets

The first changes the editing experience.

The second changes what resources may be delivered to visitors.

TheOneWP Remove Block Assets provides separate controls for selected block-related frontend assets.

Why block CSS may still be required after restoring Classic Editor

Suppose your site previously created 500 posts using the Block Editor.

You then switch to Classic Editor for future editing.

The database may still contain those existing block-based posts.

The frontend may therefore still render:

• Group blocks;
• Columns blocks;
• Button blocks;
• Gallery blocks;
• Cover blocks;
• plugin blocks.

Removing their styles simply because the administration interface now uses Classic Editor could break their presentation.

Audit frontend assets separately

If performance is the reason for considering Gutenberg removal, inspect what the frontend actually loads.

Do not infer frontend dependencies from the editor screen.

For the broader asset-loading model, see wp_enqueue_scripts Explained.

Should you remove Gutenberg completely?

Usually, it is more useful to think in terms of disabling the Block Editor where it is unnecessary rather than trying to remove every trace of Gutenberg from WordPress.

The block system now participates in many parts of modern WordPress.

Depending on the site, blocks can be involved in:

• post content;
• widgets;
• patterns;
• navigation;
• templates;
• block themes;
• plugin interfaces.

A precise configuration is safer than a blanket attempt to remove unrelated functionality.

Should you use Classic Editor on a new site?

For most new WordPress projects, the Block Editor is the more natural default because it is the editing architecture around which modern WordPress continues to evolve.

But Classic Editor can still be a deliberate choice when:

• content is intentionally simple;
• the project is heavily custom-field-driven;
• developers control all layout through templates;
• a page builder controls visual pages;
• the editorial team specifically requires the traditional interface;
• critical integrations depend on classic editing behavior.

The broader tradeoffs are covered in Block Editor vs. Classic Editor: Which Fits Your Site?.

Should you restore Classic Editor on an existing site?

Before changing the editor on an existing installation, audit:

• which editor created current posts;
• which post types actually need editing;
• whether custom blocks are used;
• whether legacy metaboxes exist;
• whether shortcodes are important;
• whether a page builder controls pages;
• whether the theme is classic or block-based;
• whether frontend content depends on block styles;
• whether editors need patterns or reusable block layouts.

A safe staging workflow

For an established site, use a staging environment before changing editor architecture.

A practical workflow is:

1. Create or refresh the staging site.
2. Take a backup before changing the editor.
3. Enable the Classic Editor configuration.
4. Open representative existing posts.
5. Check their content without immediately saving them.
6. Test editing and saving selected copies.
7. Compare frontend output before and after.
8. Test custom fields and metaboxes.
9. Test page-builder content.
10. Test custom post types.
11. Check frontend block styling.
12. Only then reproduce the configuration in production.

For a broader controlled-change process, see Building a Staging-First WordPress Update Workflow.

Take a backup before large editor migrations

Changing the editor itself is usually reversible.

Content modifications made after changing editors may not be as easy to reverse if posts are converted, markup is modified or plugin-specific structures are changed.

A backup provides a recovery point before performing bulk work.

See Settings Export vs. Full Backup: What’s the Difference? to understand why exporting plugin settings is not equivalent to backing up the entire site.

Do not bulk-convert old content unless you need to

There is rarely a requirement to immediately rewrite every historical post merely because the preferred editor changes.

A safer strategy can be:

Old content
→ leave unchanged

Content requiring edits
→ test individually

New content
→ use chosen editor

This reduces the number of posts exposed to unnecessary transformations.

What if you want to return to the Block Editor later?

If the Classic Editor was enabled through a plugin or filter, the editor policy itself can usually be reversed.

For example, if you added:

add_filter(
    'use_block_editor_for_post_type',
    '__return_false'
);

removing that filter allows WordPress to perform its normal Block Editor compatibility checks again.

However, content edited while using the Classic Editor should still be tested before assuming it will convert perfectly into native blocks.

Classic content can remain inside a Classic block

When WordPress encounters traditional content in the Block Editor, the Classic block can provide a compatibility bridge.

This means a future migration does not necessarily require immediate native-block conversion.

You can preserve content and convert selectively where appropriate.

Common mistake: downgrading WordPress to get the old editor

Do not install an outdated WordPress version simply to restore the Classic Editor.

The editing interface can be changed independently of the WordPress core version.

Running obsolete WordPress core creates unnecessary maintenance and security problems without providing a meaningful editor advantage.

Common mistake: disabling the REST API to disable Gutenberg

The Block Editor depends on the REST API, but intentionally breaking REST API availability is not a good editor-selection mechanism.

Other WordPress features and plugins can depend on the REST API.

If your goal is:

Use Classic Editor

use an editor-specific control.

Do not turn it into:

Break REST API
↓
Block Editor stops working

If you need to control REST access for security reasons, treat that as a separate project. See How to Restrict the WordPress REST API.

Common mistake: removing block assets at the same time

Changing several architectural systems simultaneously makes troubleshooting harder.

If you:

disable Gutenberg
+
remove block CSS
+
change theme
+
convert old content

and something breaks, identifying the cause becomes unnecessarily difficult.

Make changes independently and test after each one.

Common mistake: assuming all post types should behave identically

A WordPress site can legitimately use different editing experiences for different content.

For example:

Posts
→ Block Editor

Pages
→ page builder

Projects
→ Classic Editor

Products
→ WooCommerce

Consistency is valuable, but forcing fundamentally different content types into the same interface can create a worse workflow.

Common mistake: confusing editor restrictions with permissions

Choosing Classic Editor instead of Block Editor does not change what a user is authorized to do.

WordPress permissions are controlled through roles and capabilities.

If the real requirement is to stop clients from performing particular administrative actions, changing editors is not a substitute for permission management.

See WordPress User Roles and Capabilities Explained for that distinction.

Common mistake: using Classic Editor only because clients find Gutenberg confusing

Restoring Classic Editor can be appropriate, but first identify the actual usability problem.

Sometimes the problem is not blocks themselves but an overloaded WordPress administration interface.

The user may be dealing with:

• too many menu items;
• plugin notices;
• unnecessary metaboxes;
• too many block options;
• irrelevant dashboard widgets;
• excessive permissions.

In those cases, simplifying the administration interface may be more useful than replacing the entire content editor.

See Reducing WordPress Admin Confusion for Clients.

Which method should you use?

Use the official Classic Editor plugin when

• you want the official WordPress-supported plugin approach;
• you need the traditional editing interface quickly;
• you want editor-switching functionality;
• you need compatibility with legacy editing workflows.

Use a PHP filter when

• you are a developer;
• the editor policy is part of a custom site architecture;
• you want precise programmatic control;
• you are comfortable maintaining the implementation.

Use TheOneWP Disable Gutenberg when

• TheOneWP is already part of the site;
• you do not want another single-purpose plugin;
• you want to disable Gutenberg globally or by post type;
• you want the configuration managed through an interface instead of custom PHP.

Classic Editor restoration checklist

• WordPress 5.0 made the Block Editor the default editor.
• You do not need to downgrade WordPress to restore Classic Editor.
• The official Classic Editor plugin can restore the traditional editing interface.
• WordPress provides native filters for controlling Block Editor availability.
• use_block_editor_for_post_type controls Block Editor availability by post type.
• use_block_editor_for_post provides per-post control.
• Post types must support the editor to use the Block Editor.
• Block Editor-compatible post types must be exposed through the REST API.
• Do not disable the REST API simply to disable Gutenberg.
• You can disable the Block Editor globally.
• You can disable it only for selected post types.
• Different post types can use different editing workflows.
• TheOneWP Disable Gutenberg can manage global or post-type-specific editor rules.
• The Classic block is not the same as the Classic Editor.
• The Classic block provides classic-style editing inside the Block Editor.
• The Classic block can convert compatible content into native blocks.
• Many traditional metaboxes remain compatible with the Block Editor.
• Legacy metaboxes can explicitly declare Block Editor incompatibility.
• Do not restore Classic Editor merely because a site contains metaboxes.
• Page builders are separate from the native WordPress editor.
• Disabling Gutenberg does not disable a separate page builder.
• Classic Editor and classic themes are separate concepts.
• Restoring Classic Editor does not convert a block theme into a classic theme.
• Changing editors does not automatically convert existing content.
• Existing block content may remain in the database.
• Existing block content may still require frontend block CSS.
• Disabling Gutenberg and removing block assets are separate operations.
• Classic Editor does not automatically improve frontend performance.
• Do not remove block assets without checking whether existing content uses them.
• Test existing content before changing editor architecture.
• Use staging for established sites.
• Test custom blocks.
• Test shortcodes.
• Test custom HTML.
• Test legacy metaboxes.
• Test page-builder content.
• Test custom post types.
• Compare frontend output before and after editing.
• Take a full backup before large content migrations.
• A settings export is not the same as a full site backup.
• Avoid unnecessary bulk conversion of historical content.
• Editor choice is not a substitute for WordPress roles and capabilities.
• For most new sites, Block Editor remains the natural default.
• Classic Editor remains valid for deliberate legacy, structured or simplified workflows.

Related guides

• Block Editor vs. Classic Editor: Which Fits Your Site?
• Does Switching WordPress Editors Affect Your Content?
• WordPress Full Site Editing and Block Widgets, Explained
• WordPress Block Editor CSS Explained
• WordPress Staging Site Best Practices
• Reducing WordPress Admin Confusion for Clients

Final recommendation

Bringing back the Classic WordPress Editor is still straightforward, but it should be treated as an editorial architecture decision rather than a generic WordPress optimization.

If you simply want the traditional editing experience across the site, the official Classic Editor plugin provides the most direct WordPress.org solution.

If you are developing a custom site and need precise control, WordPress’s native use_block_editor_for_post_type and use_block_editor_for_post filters allow the decision to be made programmatically.

If TheOneWP is already installed, Disable Gutenberg provides a centralized way to disable the Block Editor globally or only for the post types that do not need it.

For an existing site, avoid treating the switch as an isolated interface preference.

First determine:

Which post types use blocks?
Which plugins provide blocks?
Which content uses legacy metaboxes?
Does a page builder control pages?
Does the theme depend on block architecture?
Does existing frontend content require block CSS?

Then choose the smallest change that solves the actual problem.

If only one legacy custom post type needs Classic Editor, disable Gutenberg for that post type rather than globally.

If the entire project was intentionally built around classic editing, a global Classic Editor workflow may be entirely reasonable.

Most importantly, keep editor selection, content conversion, frontend asset optimization and theme architecture as separate decisions.

They interact with one another, but they are not the same thing.