Quick answer: The Classic Editor plugin is an official WordPress plugin that restores the pre-Gutenberg editing experience. It is a valid choice in 2019 if your team is mid-project, depends on classic-only meta boxes, or needs time to retrain. It is not a forever strategy. Gutenberg is the default direction of WordPress. Plan a transition: inventory plugins, train editors, and move templates when you can do it without wrecking deadlines.
WordPress 5.0 arrived in December 2018 with the block editor. Many business sites installed Classic Editor the same week. That was rational. This article helps you decide whether to stay, for how long, and how to leave cleanly. For a fuller picture of blocks, see Gutenberg block editor.
What Classic Editor actually does
With the plugin active you can use the old TinyMCE writing screen, optionally make classic the default for all users, or let users pick per profile. It does not freeze WordPress itself at 4.9. You still get core updates, security fixes and most of the modern admin. You mainly change how post content is edited.
Good reasons to keep it for now
Publishing workflow still in flight. If you are in the middle of a large content migration or a compliance review, swapping editors mid-stream adds noise.
Plugins that only expose classic meta boxes. Some page builders and legacy plugins assume the old editor screen. Test before you remove Classic Editor.
Team capacity. Non-technical editors may need scheduled training, not a Monday surprise.
Custom fields heavy editorial UIs. ACF and similar setups often work with both editors, but your exact field groups deserve a staging check.
Weak reasons to keep it forever
“I just dislike change.” Fair feeling, poor long-term plan. Themes, patterns and core features increasingly assume blocks.
“Blocks are slower for me.” Speed often improves after a week of use and a trimmed plugin list. Measure after training, not after ten minutes.
“Our agency said never upgrade.” Get a second opinion. Staying on an unsupported editing path while the ecosystem moves on creates debt.
How long will Classic Editor be supported?
The WordPress project has committed to maintaining the Classic Editor plugin until at least the end of 2021 (announced alongside the Gutenberg rollout). That is a runway, not an infinite promise. Use the time to plan, not to ignore the question.
A practical decision tree
- Activate Classic Editor on staging, not only production.
- List must-work plugins: SEO, ACF, page builder, membership, multilingual.
- Have two editors write a real post in Gutenberg with your actual field groups.
- If blockers are temporary, keep Classic Editor and schedule a revisit date on the calendar.
- If blockers are permanent (abandoned plugin), budget a replacement, not a forever classic lock-in.
Moving to Gutenberg without drama
Train on headings, images, reusable blocks and the classic block (you can embed classic content inside a block session while transitioning). Convert high-traffic templates first. Keep a style guide for which blocks are approved for your brand. Watch for layout shifts in content that relied on custom HTML in TinyMCE. Update internal SOPs and screenshots.
You do not have to rebuild the entire archive on day one. New content can start in blocks while old posts remain until edited.
Page builders and Classic Editor
Many sites use Elementor, Divi or similar. Those interfaces often replace both classic and block editing for landing pages. Your editor question may really be a builder question. Be clear which surfaces use which tool so the team is not toggling blindly. Comparisons like Divi vs Elementor help for builder choice; they do not remove the need to test Gutenberg for blog posts if that is where you publish articles.
Performance and admin UX
Gutenberg adds scripts in the editor screen. That can feel heavy on low-powered machines or with dozens of plugins. Trimming unused plugins and keeping WordPress, PHP and MySQL current helps more than blaming blocks alone. Readers on the front end do not load the editor.
Content types and templates
Some teams keep classic for long documents with heavy shortcodes while moving marketing pages to blocks. That hybrid can work for a year. Document it. Undocumented hybrids become “why does this post type look different?” support tickets.
What editors notice first in Gutenberg
The block inserter, the document sidebar, and the way images become their own blocks surprise people who memorized TinyMCE buttons. Budget a one-hour guided session: create a heading, a list, an image with alt text, a quote, and a reusable block. That single hour removes most fear.
Shortcodes from older plugins usually still work inside a classic block or as shortcode blocks. Test the ones you rely on for forms, pricing tables and embeds before you announce a company-wide switch.
Plugin compatibility matrix (build one)
Make a spreadsheet with columns for plugin name, critical (yes/no), tested in Gutenberg (yes/no), blocker notes, and owner. Update it when you change plugins. Agencies that skip the matrix rediscover the same broken metabox every quarter.
Training plan for a small team
Week 1: optional Gutenberg on staging for volunteers. Week 2: mandatory short training, Classic Editor still default. Week 3: Gutenberg default for new posts, classic available on request. Week 4: review feedback, fix template issues, set a date to remove Classic Editor if clear.
Communicate the plan in writing so nobody feels ambushed.
Theme support for editor styles
Add editor styles so blocks in the admin roughly match the front end. When the editor looks nothing like the site, authors over-format. Aligning typography and widths reduces “fix it in HTML” habits that create debt.
Multisite and classic
On multisite, network policies may force Classic Editor network-wide. That can be right during a staged rollout. Document which sites are allowed to experiment with blocks so support is not guessing.
Support timeline reminders
Put a calendar reminder for early 2021 to reassess Classic Editor. Project commitments can change; waiting until the last supported month creates an emergency. Revisiting twice a year is enough for most small teams.
Client communication template
Tell stakeholders: we are keeping Classic Editor through date X while we finish plugin Y testing; new blog posts move to blocks on date Z; training is scheduled for date W. Put those dates in the project tracker. Ambiguity is what creates emergency classic lock-in.
Developer notes
Avoid new features that only work in TinyMCE. Prefer block-friendly embeds and shortcodes that also render in Gutenberg. When you must ship a classic-only metabox, log a debt ticket with an owner.
FAQ
Can we use Classic Editor on some post types only?
Yes, with configuration and sometimes small custom code. Many teams keep classic for one CPT while using blocks for posts.
Will classic content break in Gutenberg?
Usually it opens inside a classic block or converts with a prompt. Test your real posts, especially those with shortcodes and custom HTML.
Is Classic Editor less secure?
The plugin itself is official and maintained. Security risk rises if you use it as an excuse to avoid broader WordPress updates.
Should brand-new sites bother with classic?
Generally no. Start with blocks unless a specific plugin forces otherwise.
Use the runway on purpose
Classic Editor is a bridge. Cross it when your plugins and people are ready, with a date on the calendar. If you want help planning a calm WordPress editor transition as part of wider site care, see Turn visitors into customers.
