Your posts screen shows a plain text box with a row of formatting buttons. Everyone else’s shows blocks.

Figuring out how to enable Gutenberg editor in WordPress takes about thirty seconds once you know which of the five things turned it off. Finding that thing is the actual work.

Four culprits cover almost every case:

  • The Classic Editor plugin, still sitting at 10 million+ active installations
  • A missing showinrest argument on a custom post type
  • A useblockeditorforpost filter buried in a theme
  • A page builder like Elementor claiming the edit screen

This guide walks each method, from the Settings toggle to the code fix, then covers what breaks afterward and how to roll back if you hate it.

What Is the Gutenberg Editor in WordPress?

Gutenberg is the block-based content editor merged into WordPress core on December 6, 2018 with version 5.0. Gutenberg replaced the single TinyMCE field with modular blocks and stores content as block markup inside postcontent, not in a separate table.

The name causes half the confusion around this topic. Three separate things answer to “Gutenberg,” and knowing which one someone means decides which method actually turns it on.

EntityWhat it isWhere it lives
Block EditorThe default editor for creating posts and pagesWordPress core (version 5.0+)
Gutenberg pluginBeta channel for upcoming editor featuresWordPress.org plugin directory
Site EditorInterface for editing templates and site-wide designWordPress core (version 5.9+)

Adoption settled the argument years ago. SQ Magazine data from 2025 puts the block editor on 87% of active WordPress installs.

Block Editor vs Gutenberg Plugin vs Site Editor

Block editor: ships with core, needs no installation, handles posts and pages.

Gutenberg plugin: optional, runs ahead of core, overrides the core editor files once active.

Site Editor: arrived in WordPress 5.9 (January 2022), edits headers, footers, and templates rather than post content.

Colorlib reports 75%+ of new themes now use Full Site Editing, which is why the Site Editor keeps showing up in tutorials written for the post editor.

How Block Markup Is Stored in the Database

Every block writes itself into postcontent as plain HTML wrapped in comment delimiters like <!-- wp:paragraph -->.

WordPress parses those comments on load and rebuilds the block interface from them. Nothing is stored in a hidden JSON column, which is why block content still renders if you deactivate everything.

The editing layer itself is a JavaScript application built on React, and that single fact explains most of the failures covered later.

Core blocks cover paragraph, heading, image, list, group, columns, and table. Reusable blocks and patterns sit on top as saved arrangements.

How to Check Which Editor Your WordPress Site Currently Uses

Open any post and look at the top-left corner. A blue plus icon (the block inserter) means the block editor is running. A row of formatting buttons above a single text area means TinyMCE and the Classic Editor.

Diagnosis first saves you from applying the wrong fix. Four different things disable Gutenberg, and each one needs a different switch.

What you seeLikely causeWhere to fix it
TinyMCE toolbarClassic Editor plugin is activeSettings → Writing
Blocks on posts, but not on a custom post type (CPT)REST API support is missingregister_post_type()
Edit with Elementor takes overElementor is set as the default editorElementor Settings panel
No editor choice anywhereA filter in the theme or an MU plugin disables itfunctions.php or the wp-content/mu-plugins/ directory

Check your WordPress version under Dashboard > Updates before anything else. Anything below 5.0 has no block editor to enable.

WordPress 7.0 “Armstrong” landed on May 20, 2026, following 6.9 “Gene” on December 2, 2025, so version is rarely the culprit in 2026.

How to Enable the Gutenberg Editor from WordPress Settings

Go to Settings > Writing and set “Default editor for all users” to Block editor. That radio button appears only while the Classic Editor plugin is active, and the change applies immediately to every new post.

This is the fastest method and the one most people need. No code, no deactivation, no risk to existing content.

Below the radio buttons sits a toggle labeled “Allow users to switch editors.” Turning it on adds an “Edit (Block editor)” link to each row on the Posts screen.

It also adds a per-user preference at Users > Profile, which matters on sites with a mixed editorial team. Writers who hate blocks keep TinyMCE. Everyone else moves on.

The setting writes to the classic-editor-replace option in wpoptions. Worth knowing if you ever need to flip it with WP-CLI across a batch of sites.

Existing Classic posts do not convert. They open inside a single Classic block, untouched, which is exactly the behavior you want on a live site.

How to Enable Gutenberg by Deactivating the Classic Editor Plugin

Deactivating the Classic Editor plugin restores the block editor across every post type on the site. Deletion also removes the classic-editor-replace option on uninstall, while deactivation alone keeps the setting stored for a fast rollback.

The Classic Editor plugin passed 10 million active installations, one of only four plugins in the WordPress.org directory to do so alongside Elementor, Contact Form 7, and Yoast SEO.

Support has been renewed annually since 2018 and currently runs through 2026. The plugin is not dying next Tuesday, whatever a scare-post told you.

Deactivating Classic Editor

Plugins > Installed Plugins > Deactivate. That is the entire process.

What breaks afterward, in rough order of frequency:

  • Metaboxes written for the TinyMCE screen render below the block canvas instead of beside it
  • Custom addeditorstyle rules stop applying
  • Shortcode UI buttons from older plugins vanish

Advanced Editor Tools (1M+ installs) softens the landing with its Classic Paragraph block if your team panics.

Turning Off Disable Gutenberg Rules

Jeff Starr’s Disable Gutenberg plugin sits at 700,000+ active installations, per ITMonks 2026 data, and it does not use the Settings > Writing screen at all.

Its options live under Settings > Disable Gutenberg. A “Complete Disable” checkbox is ticked by default.

Untick it, then use the per-post-type and per-user-role checkboxes to bring the block editor back selectively. More granular than the official plugin, which is the whole point of it.

Run wp plugin list --status=active if you manage the site over SSH. Faster than scrolling a 40-plugin list looking for the offender.

How to Enable Gutenberg with the useblockeditorforpost Filter

Return true from the useblockeditorforpost filter to force the block editor on when a theme or plugin has switched it off in code. Both this filter and useblockeditorforposttype were added in WordPress 5.0.

Add the snippet to a child theme’s functions.php file or, better, a small site-specific plugin so a theme update cannot wipe it.

addfilter( 'useblockeditorforpost', 'returntrue', 999 ); `

Priority matters here. The offending code often runs at the default priority of 10, so 999 puts your filter last and lets it win.

Old tutorials still reference gutenbergcaneditposttype. That filter belonged to the plugin before the core merge and does nothing on a modern install.

Cannot find what disabled it? Grep the plugins and themes folder:

` grep -rn "useblockeditorforpost" wp-content/ `

Nine times out of ten the hit sits inside a premium theme’s inc/ directory, added by a developer who preferred Classic three years ago and never revisited the decision.

How to Enable Gutenberg for Custom Post Types

A custom post type needs two arguments in registerposttype(): showinrest => true and editor inside the supports array. Missing either one keeps the Classic screen, because the block editor reads and writes content through the REST API.

This is the single most common reason blocks appear on Posts but not on your Portfolio, Recipe, or Property type.

ArgumentRequired valueEffect if missing
show_in_resttrueNo wp/v2 REST route is created, so the Classic Editor loads instead
supportsIncludes 'editor'No content editor is available for the post type
publictrue (typical)The post type is hidden from the front end and most admin screens

Enabling REST API Support on a CPT

Setting showinrest to true registers a route in the wp/v2 namespace, which the editor calls to save your blocks through that programming interface.

` registerposttype( 'portfolio', array( 'public' => true, 'showinrest' => true, 'supports' => array( 'title', 'editor', 'thumbnail' ), ) ); `

The WordPress developer reference states it plainly: set this to true for the post type to be available in the block editor.

Custom Post Type UI Settings

No code needed if you registered the type through Custom Post Type UI. Edit the post type, scroll to Settings, and flip “Show in REST API” to True.

Save, then reload the edit screen. Blocks appear straight away, no cache clearing required.

WooCommerce products: the legacy product data metabox still governs that screen, so blocks behave differently there than on a standard CPT.

ACF field groups: compatible with the block editor, though field groups placed “High (after title)” jump to the sidebar and confuse editors on first sight.

How to Install the Gutenberg Plugin for Early Feature Access

Install the Gutenberg plugin from Plugins > Add New by searching “Gutenberg” and picking the entry from the Gutenberg Team. The plugin ships features roughly six to eight versions ahead of core and overrides the core block editor once activated.

Release cadence runs every two weeks. Gutenberg 20.0 in January 2025 marked the 200th release of the plugin, and Gutenberg 22.2 shipped on December 3, 2025 with 161 merged pull requests from contributors including four first-timers.

Who actually needs this? Block developers, theme authors testing against upcoming APIs, and people who want the Site Editor changes before the next core release.

Who does not? Everyone running a client site. The plugin is explicitly a beta channel, and I have watched a Gutenberg release break a custom block on a production site the same afternoon it was activated.

Staging first. Always. Then roll back with WP Rollback or by uploading a prior version ZIP if something goes sideways.

If the install button fails outright, the cause is usually file permissions or a disabled plugin installer rather than the plugin itself. Sorting out why plugin installation gets blocked takes precedence over anything Gutenberg-specific.

Deactivating the plugin hands control back to the core block editor with no data loss. Blocks that only existed in the plugin leave behind an invalid-block warning, which is annoying but recoverable.

How to Enable the Site Editor and Full Site Editing

The Site Editor appears under Appearance > Editor only when a block theme is active. WordPress detects a block theme by looking for an index.html file inside the theme's templates/ folder, so activating one is the entire enabling step.

Full Site Editing shipped with WordPress 5.9 in January 2022, alongside Twenty Twenty-Two as the first default block theme. Twenty Twenty-Five arrived in January 2025 and Ollie and Frost cover the third-party side.

Adoption moved fast once the tooling matured. FSE usage grew 145% during 2025, per Vapvarun’s 2026 analysis, and most new themes released now ship as block themes.

Theme typeEditing surfaceTemplates stored as
Block themeSite Editor (full site editing)HTML files in templates/ and parts/
Hybrid themeTemplate Editor onlyPHP templates plus optional HTML template parts
Classic themeCustomizer and widgetsPHP template files

The difference between templates and themes matters here more than usual, because block themes collapse the two into one editable layer.

theme.json handles global styles: palette, typography, spacing, layout widths. Adding theme.json to a classic theme configures block settings but does not unlock the Site Editor, a distinction that trips up a lot of people.

Classic themes get the limited Template Editor instead, gated by addthemesupport( ‘block-template-parts’ ). Users edit existing parts. They cannot create new ones.

Migrating off a classic theme? Widget areas become template parts, and custom WPQuery loops become the Query Loop block for most use cases. Customizer settings do not carry across.

How to Enable Gutenberg on a WordPress Multisite Network

On multisite, a network-activated Classic Editor plugin sets the classic editor as default and blocks site administrators from changing editors. The switch lives in Network Admin > Settings, not in each site’s Settings > Writing screen.

Network settings overwrite per-site settings. A super admin network-activating the plugin overrides whatever an individual site admin chose, which is exactly the complaint filed in the plugin’s GitHub issue tracker back in 2019 and still the behavior today.

Three places to check, in order:

  • Network Admin > Plugins for anything marked “Network Active”
  • Network Admin > Settings for the network-wide default editor selection
  • wp-content/mu-plugins for must-use files that never appear in any plugin list

Must-use plugins deserve special attention. They cannot be deactivated from the dashboard at all, and any file dropped in that directory runs on every site in the network.

WP-CLI handles the bulk work faster than clicking through 40 dashboards:

` wp site list --field=url | xargs -I % wp plugin deactivate classic-editor --url=% `

A WordPress VIP user on the .org support forums reported exactly this confusion in 2023: Classic Editor loaded everywhere, no switch option anywhere, until they changed the network setting instead of the site setting.

Site admins on a network cannot install plugins unless the super admin ticks the Plugins box under Network Settings. Anyone running several WordPress sites at once hits this permission wall eventually.

Why the Gutenberg Editor Fails to Load After Being Enabled

The block editor saves through the REST API at /wp-json/, so any request that returns HTML instead of JSON breaks it. Security firewalls, broken permalinks, mismatched site URLs, and JavaScript conflicts cause almost every reported failure.

This is where most sessions actually end. The editor got enabled fine, then refused to save.

SymptomRoot causeFirst fix to try
“Not a valid JSON response”REST API request is blocked or redirectedRe-save Settings → Permalinks
Spinning loader that never loadsJavaScript error or combined/minified assets issueCheck the browser console, then disable caching or asset optimization
Blank white editorPHP memory exhaustionIncrease WP_MEMORY_LIMIT to 256M

MalCare’s 2026 breakdown puts it plainly: the editor expected JSON and got a redirect, a login page, a firewall block, or a PHP warning instead.

Fixing REST API Blocks

Open yoursite.com/wp-json/wp/v2/posts directly in a browser tab. Raw JSON means the API works. A 403, a challenge page, or an HTML error page means something is blocking it.

Usual suspects: Wordfence, Solid Security, ModSecurity at the server level, and Cloudflare firewall rules. Check Wordfence’s Security > Events log for hits against wp-json endpoints.

Tools > Site Health flags REST API warnings before you start pulling the site apart. Not exhaustive, but a fast first read.

Mismatched WordPress Address and Site Address under Settings > General also break the save request while leaving the front end looking perfectly fine.

Resolving JavaScript and Caching Conflicts

The block editor is a React application, and one broken script takes the whole canvas down with it.

Console first: right-click, Inspect, Console tab, reload the editor and read the first red error.

Then asset optimization: WP Rocket, Autoptimize, and LiteSpeed Cache all concatenate and defer JavaScript, which reliably breaks block editor scripts when applied to admin pages.

Then debugging: add define(‘SCRIPTDEBUG’, true); to wp-config.php to load unminified core scripts and get useful line numbers.

Memory exhaustion produces a completely blank editor screen with no error at all. Shared hosting often defaults to 32MB or 64MB while the block editor wants 256MB.

Turn on WPDEBUGLOG and read wp-content/debug.log for the fatal error line. Reading what WordPress writes to its log file beats guessing which plugin caused it.

How Existing Classic Content Behaves After Enabling Gutenberg

Old posts open inside a single Classic block and stay that way until you convert them. Nothing changes on the front end, because classic content was already plain HTML and renders identically regardless of which editor produced it.

Conversion is manual and per-post. Select the Classic block, open the toolbar, click “Convert to blocks.”

WP Tavern’s advice on this has not aged badly: convert posts as you edit them, not in one batch. Mass conversion across hundreds of posts invites broken layouts.

What the conversion produces from typical classic content:

  • Paragraphs become Paragraph blocks
  • Any subheadings in your posts become Heading blocks
  • Existing HTML tables become Table blocks
  • Custom HTML lands in a Custom HTML block, usually intact

Shortcodes are the weak point. WP Tavern documented Gutenberg’s core conversion routine stripping shortcodes during the transform, and the behavior sits in Gutenberg itself rather than in any bulk plugin.

up’s Convert to Blocks plugin takes a smarter approach: it parses content into blocks only when an editor opens the post, and writes the new structure only on save. Fewer database rows touched, less risk.

The official Bulk Classic to Block plugin states the obvious out loud in its own FAQ: the conversion is irreversible. Export the database with wp db export or run UpdraftPlus before touching anything.

How to Switch Back to the Classic Editor

Install the Classic Editor plugin from the WordPress.org directory and activate it. The classic TinyMCE screen returns immediately, and the plugin remains officially supported through 2026 with annual renewals.

No content is lost in either direction. Posts you edited during the Gutenberg period keep their block markup, which the Classic editor displays as raw comment delimiters mixed into the content.

That last bit surprises people. It looks like the post broke. It did not.

StepWhereEffect
Activate Classic EditorPlugins screenRestores the TinyMCE editor site-wide
Set default editorSettings → WritingControls the editor used for new posts
Remove custom filtersfunctions.php or site pluginStops code from forcing the Block Editor

Keep both editors live by leaving “Allow users to switch editors” enabled. Each row on the Posts screen then offers an “Edit (Classic)” link.

Delete any useblockeditorforpost filter you added earlier. A filter returning true at priority 999 beats the plugin, and you will spend twenty minutes wondering why the rollback did nothing.

Advanced Editor Tools, sitting at 1 million+ active installations, offers a middle path with its Classic Paragraph block. TinyMCE for the writing, blocks for everything else.

Honest read on going backward: the ecosystem stopped building for Classic years ago. New themes ship as block themes, premium plugins drop Classic compatibility, and WordPress 7.0 “Armstrong” (May 2026) kept extending block editor capability rather than the old screen. Rolling back buys time, not a permanent home.

FAQ on How To Enable Gutenberg Editor In WordPress

Do I need to install anything to use the Gutenberg editor?

No. The block editor ships inside WordPress core since version 5.0. The separate Gutenberg plugin is a beta channel for early features, not a requirement for normal use.

Why does my custom post type still show the classic editor?

The post type registration is missing showinrest => true, or editor is absent from the supports array. Both arguments are mandatory, because the block editor reads content through the REST API.

Will enabling Gutenberg break my old posts?

No. Classic content opens inside a single Classic block and renders identically on the front end. Nothing converts automatically, and postcontent stays untouched until you click “Convert to blocks” on a specific post.

Where is the setting to switch back to the block editor?

Settings > Writing, under “Default editor for all users.” That radio button only appears while the Classic Editor plugin is active. Deactivating the plugin removes the setting and restores blocks everywhere.

Why does the editor say “Updating failed. The response is not a valid JSON response”?

Something returned HTML instead of JSON from /wp-json/. Common causes: broken permalinks, mismatched site URLs, or a security firewall like Wordfence blocking REST requests. Re-save Settings > Permalinks first.

Can I enable Gutenberg without touching plugins?

Yes, with code. Add addfilter( ‘useblockeditorforpost’, ‘returntrue’, 999 ); to a child theme's functions.php or a site-specific plugin. Priority 999 overrides whatever disabled it.

Why is Appearance > Editor missing from my dashboard?

Your active theme is a classic theme. The Site Editor requires a block theme with an index.html file inside the templates folder. Twenty Twenty-Five, Ollie, and Frost all qualify.

How do I enable the block editor across a multisite network?

Network settings override individual sites. Check Network Admin > Plugins for a network-activated Classic Editor, then Network Admin > Settings for the default editor choice. Also inspect mu-plugins, which never appear in plugin lists.

Does the Gutenberg plugin replace the core block editor?

Yes, once activated it overrides core editor files and runs roughly six to eight versions ahead. Releases land every two weeks. Staging environments only, not client production sites.

Is the Classic Editor plugin going away?

Not imminently. Support renews annually and currently runs through 2026. The real pressure comes from the ecosystem: new themes ship as block themes and premium plugins drop classic compatibility steadily.

Conclusion

Knowing how to enable Gutenberg editor in WordPress comes down to one habit: diagnose before you change anything.

Start with Settings > Writing. If the radio buttons are not there, the block came from code or from a network-level rule, and the fix moves accordingly.

Save a database export before converting legacy content. Block markup writes directly into post_content`, and no undo button exists once a bulk conversion runs.

Test on staging when a page builder or a heavily customised theme is involved. Ten minutes there saves an afternoon of debugging a spinning editor.

Then spend an hour with block patterns and reusable blocks. The Settings toggle is the easy part; getting genuinely fast in the block editor takes actual practice.