How to Use the Classic Editor in WordPress: Installation, Configuration, and When It Actually Makes Sense

The WordPress Classic Editor is a TinyMCE-based WYSIWYG content editor that predates the Gutenberg block system introduced in WordPress 5.0. It presents a single, linear editing canvas — visually similar to Microsoft Word — where text, media, and HTML coexist in one continuous field rather than discrete, stackable blocks. For users who need to install it today, the short answer is: install the official Classic Editor plugin from the WordPress plugin repository, activate it, and configure the default editor under Settings > Writing.

That two-sentence answer covers the core query. The rest of this guide covers the architectural differences between the two editors, the legitimate technical reasons to choose one over the other, configuration edge cases, and the scenarios where forcing Classic Editor actually creates more problems than it solves.

Classic Editor vs. Gutenberg Block Editor: A Technical Comparison

Before touching any settings, it is worth understanding what you are actually switching between. The decision is not purely cosmetic.

The most operationally significant difference is content storage. Classic Editor saves clean HTML. Gutenberg wraps every content unit in HTML comment annotations that act as block delimiters. If you ever migrate content between systems — to a headless CMS, a static site generator, or a non-WordPress platform — Classic Editor output is far easier to parse and port. Gutenberg's block grammar is proprietary to WordPress's parser.

Why Developers and Site Owners Still Choose Classic Editor

Legacy Plugin and Theme Compatibility

Many commercial plugins — particularly older form builders, e-commerce extensions, and custom post type plugins — register meta boxes that inject fields directly into the post editing screen. In Gutenberg, these meta boxes are relegated to a collapsible sidebar panel rendered inside an iframe compatibility shim. This shim does not always behave correctly: JavaScript conflicts arise, conditional logic breaks, and some meta box UI frameworks (jQuery UI dialogs, for example) fail to initialize properly inside the nested document context.

If your site relies on plugins that use add_meta_box() with complex JavaScript-dependent UIs, Classic Editor eliminates this entire class of problem.

REST API Restrictions

Gutenberg's editor makes continuous background requests to the WordPress REST API — to fetch block patterns, autosave drafts, retrieve post lock status, and validate user capabilities. In hardened server environments where the REST API is intentionally restricted (via add_filter('rest_authentication_errors', ...) or server-level rules blocking /wp-json/), Gutenberg will partially or completely fail to load. Classic Editor has no such dependency and will function normally under these constraints.

Multisite and Role-Based Editor Control

On WordPress Multisite installations, network administrators sometimes need to enforce a consistent editing experience across all subsites — particularly when non-technical editors are involved. The Classic Editor plugin supports a Settings > Writing option to disallow per-user editor switching, locking all users into Classic Editor regardless of their individual preferences. Gutenberg offers no equivalent network-level enforcement mechanism without custom code.

Workflow Speed for Text-Heavy Content

For publishers producing high volumes of text content — news articles, documentation, legal filings — the Classic Editor's single-canvas model is genuinely faster. There is no need to insert a new block, select a block type, or navigate between block settings panels. You press Enter and keep writing. For editors who live in the keyboard and use HTML tab shortcuts, this matters.

How to Install the Classic Editor Plugin

The Classic Editor is not bundled with WordPress core. It is maintained as an official plugin by the WordPress Contributors team and is available from the WordPress.org plugin repository.

Method 1: Install via the WordPress Dashboard

1. Log in to your WordPress admin panel (/wp-admin).
2. Navigate to Plugins > Add New Plugin.
3. In the search field, type Classic Editor.
4. Locate the plugin authored by WordPress Contributors — verify the author, as there are imitator plugins with similar names.
5. Click Install Now, then Activate.

Method 2: Install via WP-CLI

If you manage WordPress from the command line — which is standard practice on any VPS Hosting environment — WP-CLI is significantly faster than the dashboard UI:

wp plugin install classic-editor --activate

To install it network-wide on a Multisite installation:

wp plugin install classic-editor --activate-network

Method 3: Manual Upload

Download the plugin ZIP from wordpress.org/plugins/classic-editor, then upload it via Plugins > Add New Plugin > Upload Plugin, or extract it directly to your server:

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

After extraction, activate via WP-CLI or the dashboard.

Configuring Classic Editor Settings

Once activated, the plugin exposes two configuration options under Settings > Writing.

Default Editor for All Users

The first option sets the site-wide default. You can choose between Classic Editor and Block Editor. Setting this to Classic Editor means every new post and page opens in TinyMCE by default.

Allow Users to Switch Editors

The second option controls whether individual users can override the site default on a per-post basis. When enabled, hovering over a post in the Posts > All Posts list reveals two action links: Edit (opens in the site default) and Edit (Classic Editor) or Edit (Block Editor) depending on the current default.

Recommended configuration for most legacy sites:

• Default editor: Classic Editor
• Allow users to switch: No

This prevents editors from accidentally opening content in Gutenberg and inadvertently injecting block grammar comments into posts that were authored in Classic Editor — a mix that can cause rendering anomalies in some themes.

Using the Classic Editor Interface

The Visual Tab (WYSIWYG Mode)

The Visual tab renders your content through TinyMCE's iframe-based preview. The toolbar provides:

• Text formatting: Bold (Ctrl+B), Italic (Ctrl+I), Strikethrough, Underline
• Paragraph styles: Heading 1 through Heading 6, Preformatted, Blockquote
• Lists: Ordered and unordered, with indent/outdent controls
• Links: Insert/edit hyperlinks with target and title attributes
• Media insertion: Opens the WordPress Media Library for images, video, audio, and documents
• Paste from Word: Strips Microsoft Word's proprietary HTML markup on paste
• Distraction-free writing mode: Fullscreen toggle that hides all admin UI

The toolbar has two rows. If you only see one row, click the Toolbar Toggle button (the last icon in the first row) to reveal the second row, which includes the paragraph style selector, text color, character map, and undo/redo.

The Text Tab (Raw HTML Mode)

The Text tab exposes the raw HTML stored in post_content. This is not a full code editor — it lacks syntax highlighting and line numbering — but it gives you direct access to the markup. Useful scenarios:

• Inserting raw <iframe> embeds that TinyMCE would strip or escape
• Adding custom HTML attributes that the Visual tab's UI does not expose
• Debugging rendering issues caused by TinyMCE's automatic tag cleanup

Critical behavior to understand: TinyMCE performs HTML sanitization when you switch from the Text tab back to the Visual tab. It will close unclosed tags, strip certain elements (like <script> in some configurations), and normalize whitespace. If you write raw HTML in the Text tab, always verify it survives a round-trip back to Visual before publishing.

The Excerpt, Custom Fields, and Discussion Meta Boxes

Below the main editor canvas, Classic Editor surfaces the full set of native WordPress meta boxes in their original layout:

• Excerpt: Plain-text summary used by themes and SEO plugins for meta descriptions
• Custom Fields: Key-value pairs stored in wp_postmeta — accessible directly without switching to a sidebar panel
• Discussion: Per-post comment and trackback settings
• Slug: Editable URL slug field (also in the Publish box)
• Author: Reassign post authorship without navigating away

These meta boxes are always visible and full-width in Classic Editor. In Gutenberg, they are either hidden in the sidebar or rendered in the compatibility iframe — a meaningful UX difference for workflows that rely on custom fields heavily.

Switching Between Editors Per Post

If you enabled the "Allow users to switch" option, the per-post editor toggle works as follows:

From the post list:

1. Go to Posts > All Posts.
2. Hover over the post title.
3. Click Edit (Classic Editor) or Edit (Block Editor) as needed.

From inside the editor:

In Gutenberg, a link reading Switch to Classic Editor appears in the three-dot options menu (top-right). In Classic Editor, a link reading Switch to Block Editor appears near the top of the screen.

Warning: Switching a post that was authored in Gutenberg to Classic Editor — and then saving it — will preserve the block grammar comment annotations in the raw HTML. These comments are harmless to front-end rendering but will appear as literal text in the Classic Editor's Text tab, which can be confusing. Switching back to Gutenberg will correctly re-parse them. The reverse scenario (Classic Editor content opened in Gutenberg) is clean, since Gutenberg wraps unrecognized HTML in a Classic block automatically.

Disabling Classic Editor Without the Plugin

If you want to force Gutenberg and prevent Classic Editor from being used — or if you want to disable Gutenberg without installing a plugin — WordPress provides a filter hook:

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

This achieves the same effect as the Classic Editor plugin for post editing but does not affect the Site Editor (Full Site Editing). For a complete Gutenberg disable including FSE:

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

This approach is preferable in environments where installing additional plugins is restricted by policy, or where you want the disable logic version-controlled in your theme or plugin rather than dependent on a third-party plugin's activation state.

Classic Editor and WordPress Hosting Environments

The Classic Editor plugin itself is lightweight and imposes no meaningful server-side requirements. However, the broader context of your hosting environment affects the editing experience in ways worth noting.

On shared hosting plans, the WordPress admin panel can feel sluggish because PHP execution and database queries compete with other tenants on the same server. Classic Editor is measurably lighter than Gutenberg in this context — fewer REST API calls, no React rendering overhead, and a smaller JavaScript payload mean faster page loads in the admin. If you are on a Shared Web Hosting plan and find the block editor slow, Classic Editor is a practical optimization.

On a VPS with cPanel, you have full control over PHP memory limits, OPcache configuration, and MySQL query caching. In this environment, both editors perform well, and the choice becomes purely a workflow preference rather than a performance necessity.

For high-traffic WordPress installations on Dedicated Servers, the editor choice has essentially zero impact on front-end performance — the editing interface is only loaded by authenticated admin users, and the published HTML output is what matters for page speed.

Common Pitfalls and Edge Cases

TinyMCE stripping valid HTML: TinyMCE's valid_elements and extended_valid_elements configuration controls which HTML tags and attributes are permitted in the Visual editor. By default, it strips tags like <article>, <section>, <figure> (in older configurations), and any custom data attributes. If your content requires these, you must extend TinyMCE's allowed elements via the tiny_mce_before_init filter:

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

Autosave conflicts: Classic Editor uses the older wp_autosave() JavaScript function, which sends POST requests to wp-admin/post.php with action=autosave. If your server has aggressive rate limiting or a WAF rule blocking repeated POST requests to wp-admin, autosaves will silently fail. Monitor your server error logs if content loss occurs.

Classic Editor and Full Site Editing (FSE) themes: If your active theme is an FSE theme (one that declares "blockTemplates": true in theme.json), Classic Editor will still work for post and page content, but the Site Editor (/wp-admin/site-editor.php) is entirely Gutenberg-based and unaffected by the Classic Editor plugin. You cannot use Classic Editor to edit FSE theme templates.

Plugin deactivation behavior: Deactivating the Classic Editor plugin does not convert your content. Posts authored in Classic Editor remain as clean HTML. Posts authored in Gutenberg retain their block grammar. Gutenberg will correctly parse both. There is no data loss risk from deactivating the plugin.

Decision Matrix: Which Editor Should You Use?

Use Classic Editor if:

• Your site uses plugins with complex meta box UIs that break in Gutenberg's compatibility layer
• Your server restricts the WordPress REST API
• You are migrating content to a non-WordPress platform and need clean, portable HTML
• Your editorial team is large, non-technical, and trained on the Classic Editor workflow
• You are running WordPress on a resource-constrained shared hosting environment

Use Gutenberg if:

• You are building new sites without legacy plugin dependencies
• Your theme is block-based or FSE-compatible
• You need reusable blocks, block patterns, or complex multi-column layouts without a page builder
• You are building custom blocks with register_block_type() for client projects
• You want to leverage the Site Editor for full theme customization

Use both (with per-user switching enabled) if:

• You have a mixed team where some editors prefer Classic and others prefer Gutenberg
• You are in a transition period migrating a legacy site to a block-based architecture
• Different post types on your site have different complexity requirements

Practical Technical Checklist

Before switching your production site to Classic Editor, verify the following:

• ] Confirm the Classic Editor plugin version is current (check [wordpress.org/plugins/classic-editor for the latest release)
• [ ] Test all active plugins' meta box UIs in Classic Editor on a staging environment before deploying to production
• [ ] Review your tiny_mce_before_init filters if you have custom TinyMCE configurations that may conflict with the plugin's defaults
• [ ] Decide on the "allow switching" policy and document it for your editorial team
• [ ] If using WP-CLI, confirm the plugin is activated with wp plugin list --status=active
• [ ] Check that your theme does not rely on Gutenberg-specific block styles (wp-block-* CSS classes) for front-end rendering
• [ ] Back up your database before making any editor-switching changes on a site with existing Gutenberg content
• [ ] If on a Multisite network, decide whether to activate network-wide or per-site and enforce via Settings > Writing at the network level

Pair your WordPress setup with a properly secured domain by ensuring your SSL Certificates are valid and auto-renewing — the WordPress admin panel transmits authentication cookies that must be protected by HTTPS regardless of which editor you use.

For teams managing editorial workflows that include email notifications, author communications, or newsletter integrations, a dedicated Email Hosting setup ensures transactional WordPress emails (password resets, comment notifications, post status changes) are delivered reliably rather than routed through a shared server's default sendmail.

FAQ

Does the Classic Editor plugin affect front-end rendering or site performance?

No. The Classic Editor plugin only modifies the admin-side editing interface. It has zero impact on how WordPress renders pages to visitors. Front-end performance is determined by your theme, caching layer, and server configuration — not by which editor was used to write the content.

Will switching from Gutenberg to Classic Editor corrupt my existing block-based content?

No. Gutenberg stores block annotations as HTML comments inside post_content. Classic Editor will display this raw HTML in its Text tab and attempt to render it in the Visual tab. The content is not deleted or corrupted. If you save a Gutenberg post in Classic Editor without editing it, the block annotations are preserved. If you edit and save, TinyMCE may normalize some whitespace but will not strip the comment annotations.

Can I use Classic Editor for some post types and Gutenberg for others?

Yes, but not through the Classic Editor plugin's settings UI. You need to use the use_block_editor_for_post_type filter in code:

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

Is the Classic Editor plugin going to be permanently maintained?

WordPress.org has committed to maintaining the Classic Editor plugin with security and compatibility updates until at least 2024, and it continues to receive updates beyond that commitment. However, it receives no new features — it is in maintenance mode. For long-term new projects, Gutenberg is the strategic direction of WordPress core.

Does Classic Editor work with WooCommerce?

Yes. WooCommerce's product editor has historically been built on Classic Editor meta boxes. Recent WooCommerce versions (8.x+) introduced a new product editor built on blocks, but the legacy Classic Editor-based product form remains available and is the default for most installations. The Classic Editor plugin does not interfere with WooCommerce's product editing screens.