Moving from the Classic Editor to Gutenberg on WordPress
WordPress 5.0, released on 6 December 2018, replaced the Classic Editor (TinyMCE) with the Gutenberg block editor as the default. The official Classic Editor plugin still lets you switch back, but its maintenance isn’t guaranteed indefinitely: better to plan the switch than to be caught out by it.
What actually changes on the edit screen
Gutenberg replaces the single text area of the Classic Editor with a set of independent blocks: paragraph, image, columns, custom HTML block, and so on. Each block is edited and moved separately, which changes how a page is composed but doesn’t alter what’s already published: existing content still displays correctly at the moment of the switch.
The Classic Editor plugin, officially maintained by the WordPress team, lets you keep using the old edit screen in parallel during the transition. It isn’t a permanent solution: no firm end-of-support date has been announced so far, but nothing guarantees unlimited maintenance as the WordPress core evolves.
Why some pages display oddly after moving to Gutenberg
- Content written in raw HTML or with a third-party builder’s shortcodes (pre-Gutenberg) is imported as-is into a single ‘Custom HTML’ or ‘Classic’ block: it still works, but none of the native block benefits (column layouts, visual settings, reuse) are available without a manual rework.
- Extensions that added custom metaboxes to the old edit screen (extra fields below or beside the content) need to be compatible with the block API to keep displaying properly: a poorly registered metabox can silently disappear from the edit screen.
- A theme that heavily styled the Classic Editor’s preview can show a mismatch between the editor and the final result until the Gutenberg editor styles (add_theme_support('editor-styles')) are declared.
- Shortcodes generated by an older page builder (Visual Composer, earlier versions of other tools) still work on the front end but become unreadable and not visually editable inside Gutenberg.
How I run the switch to Gutenberg
-
Auditing existing content
I identify pages written in raw HTML, with shortcodes from an old builder, or dependent on custom metaboxes, to estimate how much rework is needed.
-
Installing Classic Editor as a bridge
On a site with a lot of content to convert, I install the Classic Editor plugin so publishing can continue normally while I convert existing pages, rather than switching everything at once.
-
Checking metabox extensions
I check that every extension adding custom fields to the edit screen is still compatible with the block API, and update or replace the ones that aren’t.
-
Converting page by page
I convert content into native blocks one page at a time, starting with the highest-traffic pages, and test the front-end display after each conversion rather than at the end of the job.
-
Full switch-over
Once all content is converted and checked, I deactivate Classic Editor. This is the point where going back gets costly: past it, reverting to the classic edit screen doesn’t restore the block structure already built.
Going further
-
Migrating from one page builder to another
Elementor, Divi and WPBakery store their layout differently inside post_content: the conversion follows a similar logic.
-
Building a custom extension
If a metabox extension has no block-compatible version, I can build the native block equivalent.
-
Backing up your shop before an intervention
A backup comes before any content conversion, as with any technical intervention on the site.
-
WordPress and WooCommerce migration hub
Every migration and version upgrade I handle on WordPress and WooCommerce.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.