What Is the WordPress Classic Editor?
The WordPress classic editor is the original content editor WordPress used before version 5.0, built on the TinyMCE library. It presents a single formatted text area, similar to a word processor, with a visual tab and an HTML tab, plus a toolbar for bold, links, headings, and media. It was replaced as the default by the block editor in 2018, but remains available through the official Classic Editor plugin for sites and users that prefer the simpler, familiar writing experience.
- Default until
- WordPress 5.0, released December 2018 (WordPress.org)
- Built on
- The TinyMCE rich-text editing library
- How to restore it
- Official Classic Editor plugin, millions of active installs (WordPress.org)
- Support status
- Automattic commits to maintaining it as long as needed (WordPress.org)
- Structure
- One HTML content field plus meta boxes, versus block-based content
What the classic editor is #
The classic editor is WordPress's original writing interface, the standard for creating posts and pages until the block editor took over as default in late 2018. It centers on a single rich-text area powered by TinyMCE, the same kind of editor found in many web applications. Above the text box sits a toolbar for common formatting, bold, italic, lists, links, headings, and an Add Media button for inserting images. Two tabs let you switch between a Visual mode that shows formatting and a Text mode that exposes raw HTML. Around the editor, meta boxes handle categories, tags, featured images, and settings from plugins. For anyone who has used a word processor, it feels immediately familiar, which is exactly why many long-running sites and writers still favor it. It is no longer bundled as the default, but it lives on through an official plugin. If you maintain an older WordPress site, our /services/wordpress-development team can tell you which editor it currently runs and why.
How it works under the hood #
The classic editor's engine is TinyMCE, a mature JavaScript library that turns a plain text field into a formatted one. When you type and click Bold or insert a link, TinyMCE writes the corresponding HTML behind the scenes, which you can inspect and edit directly in the Text tab. Everything you write lives in one content field, stored in the database as a single block of HTML, unlike the block editor's delimited structure. Surrounding the editor are meta boxes, modular panels for publishing controls, categories, tags, the featured image, excerpts, and anything plugins add, such as SEO settings from Yoast or Rank Math. This layout means most of your post's data is visible on one screen. Formatting beyond the toolbar, like columns or buttons, requires shortcodes, custom HTML, or a page builder, since the classic editor itself only handles flowing text and media. Understanding that it is essentially one HTML field with helper panels explains both its simplicity and its limits.
Why some sites still use it #
Plenty of sites deliberately stick with the classic editor, and the reasons are practical. Writers who produce mostly text, like news sites, blogs, and documentation, often find a single distraction-free field faster than clicking through blocks. Sites built years ago may rely on shortcodes, custom meta boxes, or plugins designed for the classic interface that do not translate cleanly to blocks, so switching risks breaking established workflows. Teams trained on the classic editor may simply prefer not to relearn a new system when the old one still works. Some custom themes and membership or LMS plugins were also engineered around the classic editor and behave more reliably with it. For these sites, the Classic Editor plugin is a stability choice, not stubbornness. That said, staying on it long-term carries a support risk worth planning around. If your business depends on an older classic-editor site, a /services/care-plans arrangement keeps it updated and secure while you decide whether and when to modernize.
Restoring the classic editor #
The simplest way to bring back the classic editor is the official Classic Editor plugin. Developers can also disable the block editor selectively with a filter in a theme or plugin, as shown below.
// Disable the block editor for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );
// Or disable it for a specific post type only
add_filter( 'use_block_editor_for_post_type', function( $enabled, $post_type ) {
return ( 'page' === $post_type ) ? false : $enabled;
}, 10, 2 );Classic editor versus block editor #
The classic and block editors solve the same task differently. The classic editor offers one continuous text field and treats a post as a single stream of HTML, which is fast for straightforward articles and gentle on non-technical writers. The block editor breaks content into configurable blocks, enabling rich layouts, columns, buttons, and, in block themes, full-site editing, at the cost of a steeper learning curve for simple posts. Storage differs too: classic content is one HTML blob, while block content is wrapped in comment delimiters that record each block's type and settings. Neither is objectively better; the right choice depends on your content. Text-heavy publishers often prefer classic; sites that need visual, structured pages lean block. You can even run the classic experience inside the block editor using the Classic block. When advising clients, we weigh team skills, existing plugins, and content type rather than defaulting to the newest option. A quick /free-website-audit can reveal which editor best fits how your team actually publishes.
Limitations of the classic editor #
The classic editor's simplicity is also its ceiling. Because it is a single text field, anything beyond flowing text and inline media requires workarounds. Multi-column layouts, buttons, accordions, and callouts depend on shortcodes, hand-written HTML, or a page builder, none of which the editor previews natively. Shortcode-heavy content is fragile: if the plugin that defines a shortcode is disabled, the raw code appears on the page. The classic editor also does not support full-site editing, so header, footer, and template changes still need theme code or the Customizer. As WordPress and its ecosystem shift toward blocks, some newer plugins and patterns simply will not appear in the classic interface, gradually narrowing what is available to you. And relying on the Classic Editor plugin means one more dependency whose long-term future, while currently supported, is not guaranteed forever. These limits do not make the classic editor unusable, but they do cap how far a site can grow visually without adopting blocks or a builder.
Is the classic editor going away? #
A common worry is whether the classic editor will suddenly disappear. The short answer is not imminently. WordPress made the block editor the default in version 5.0, but the classic experience remains available through the official Classic Editor plugin, which Automattic has publicly committed to maintaining for as long as it is necessary, with support currently extended year by year. The plugin has millions of active installs, giving it strong momentum to continue. That said, the direction of the platform is clearly toward blocks and full-site editing, which receive the bulk of development. Practically, this means classic-editor sites are safe for the foreseeable future but should treat the setup as a bridge rather than a permanent destination. New features increasingly assume blocks, so a site frozen on classic will slowly fall behind on capabilities. Keeping the plugin and WordPress core updated, ideally under a /services/care-plans, protects you now while you plan an eventual, unhurried move to the block editor.
Migrating from classic to blocks #
Migrating from the classic to the block editor is usually smoother than owners fear, but it rewards care. When you activate the block editor, existing classic posts load inside a single Classic block and keep displaying exactly as before, so nothing breaks on day one. You can convert individual posts to blocks when you next edit them, using the block editor's built-in convert option, and check the result. The real work is auditing shortcodes and custom HTML, since these need block equivalents or a plan to keep them working. Test high-traffic and template-defining pages first, and recreate any classic-only patterns as reusable blocks so staff keep their shortcuts. Training matters as much as technical steps; give your team time on blocks before flipping the default. For sites with heavy customization, a staged migration on a staging copy avoids surprises. This is a common part of a /services/website-redesign, where modernizing the editor happens alongside refreshing design, so the disruption is absorbed into one planned project.
What we recommend #
Our recommendation depends on your situation. If you run a text-focused site, your team loves the classic editor, and everything works, there is no crisis, keep the Classic Editor plugin, stay updated, and revisit the decision periodically. If you are building a new site in 2026, we generally start with the block editor, since it is the platform's future and avoids adding a compatibility plugin from day one. If you are on classic but want richer layouts or full-site editing, plan a deliberate migration rather than a rushed switch, ideally bundled into a redesign. Whatever you choose, do not let a classic-editor site drift without updates; the plugin and core still need patching for security. The worst outcome is an unmaintained old site that eventually needs a costly /services/website-rescue. Treat the classic editor as a valid, well-supported choice today, but one with a planning horizon, and keep the site current so the eventual transition happens on your terms rather than being forced by a compatibility break you did not see coming.
FAQ
How do I get the classic editor back in WordPress?
Install and activate the official Classic Editor plugin from the WordPress plugin directory. It restores the old TinyMCE interface site-wide and lets you set whether users can switch editors per post. No code is required, and the change is reversible by deactivating the plugin whenever you decide to move to blocks.
Is the classic editor still supported in 2026?
Yes. The Classic Editor plugin remains officially supported and has millions of active installs. Automattic has committed to maintaining it as long as needed, extending support year by year. It works with current WordPress versions, though the platform's new development focuses on the block editor rather than the classic one.
Will using the classic editor hurt my SEO?
No. Search engines rank the HTML your site outputs, not which editor produced it. SEO plugins like Yoast and Rank Math work in both editors. Ranking depends on content quality, speed, structure, and links, so a classic-editor site competes fine. See /services/seo-services if rankings are the real concern here.
Can I use both editors on the same site?
Yes. The Classic Editor plugin can allow users to choose per post, or set a site-wide default with an override. You might write articles in classic and build landing pages in blocks. Mixing is fine, though a consistent approach is easier to train staff on and maintain over time as the site grows.
What is the difference between the Text tab and the Code editor?
The classic editor's Text tab shows the raw HTML of your single content field. The block editor's Code Editor shows blocks as HTML wrapped in comment delimiters. Both let you edit markup directly, but the block version preserves block structure, while the classic Text tab is one continuous stream of HTML.
Does the classic editor work with page builders?
Yes, and historically many builders were designed around it. Elementor, Divi, and similar tools replace or supplement the editor on pages you build with them, so they function whether your site defaults to classic or blocks. If you rely on a builder, the underlying editor matters less for those specific pages you build.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?