Bring back the classic editor, where it makes sense
Disable Gutenberg replaces the block editor with the classic editor, for specific post types or for every one of them, without touching a single word of the content already stored.
- Choose exactly which post types keep the classic editor.
- Leave every box unchecked to disable Gutenberg everywhere at once.
- Also disables the widget block editor when Gutenberg is off globally.
- Optionally remove block editor CSS from the front end too.
Select which post types should use the classic editor. Leave all unchecked to disable Gutenberg for all post types.
What does Disable Gutenberg do?
When the disable_gutenberg module is active, TOWP_Disable_Gutenberg filters use_block_editor_for_post_type to return false for any post type selected in settings, restoring the classic editor for exactly those types. If no post type is selected, the filter returns false unconditionally, disabling the block editor across every post type at once, and the widget block editor on Appearance > Widgets gets disabled along with it. The module also stops WordPress from fetching remote block patterns from api.wordpress.org, a request that's pointless once the block editor is off, and can optionally dequeue the block library stylesheets from the front end.
Not every site actually needs the block editor
A workflow built around a different editor doesn't automatically benefit from switching to blocks.
Older sites and page builders don't benefit from it
A site built before blocks existed, or one organized around a page builder or a set of custom fields, often gains nothing from the block interface and loses the editing habits its authors already had.
Switching back usually means editing every post type separately
WordPress's own way to restore the classic editor typically means a code snippet or a separate plugin, without an easy way to apply it only to some post types and not others.
The classic editor, exactly where it's needed
The module puts the classic editor back for the post types that actually benefit from it, without touching anything already written.
Chosen per post type
Select exactly which post types should use the classic editor, leaving every other type on the block editor untouched.
Or disabled everywhere at once
Leave every post type unchecked to switch the block editor off globally in a single step.
Content stays exactly as stored
Switching between editors changes which interface an author is given; it never touches or converts the content already saved in a post.
Editor control, scoped precisely
Every capability below is present in the supplied PHP class and its settings registration.
A checkbox list, one per registered type
Every registered post type except attachments gets its own checkbox, letting the classic editor apply to some types and not others.
Leave everything unchecked
With no post type selected, the filter returns false unconditionally, disabling the block editor across the entire site.
Disabled only when Gutenberg is off globally
The widget block editor on Appearance > Widgets only gets disabled when no specific post type is selected, since it isn't tied to any single post type.
No more calls to api.wordpress.org
should_load_remote_block_patterns is forced false, since that remote request serves no purpose once the block editor is disabled.
An optional, separate cleanup
A dedicated toggle dequeues and deregisters wp-block-library, wp-block-library-theme, global-styles and classic-theme-styles from the front end.
Nothing about stored content changes
The module only changes which editor an author sees; it never touches, converts, or migrates the underlying post content.
Where the classic editor still helps most
The module supports every site whose workflow genuinely fits a different editor.
Sites built before blocks existed
Restore the familiar classic editor on a site whose content and workflow were never designed around blocks.
Sites organized around a page builder
Keep the classic editor for post types managed by a page builder or a dedicated set of custom fields, where the block editor adds friction rather than value.
Mixed editing needs across post types
Give some post types the classic editor while leaving others, like Posts, on the block editor if that's genuinely where it helps.
The right editor, without any risk to content
The module combines per-type precision with a guarantee that content itself never changes.
A light filter, an optional deeper cleanup
The verified implementation is minimal by default, with a clearly-scoped extra step available.
A single filter callback
The core logic is one filter on use_block_editor_for_post_type, adding negligible overhead to determining which editor loads.
One fewer external request
Disabling the remote block pattern fetch avoids a network call to WordPress.org that has no purpose once blocks are off.
An optional front-end weight reduction
When enabled, the CSS removal drops four stylesheet handles from every front-end page load.
An interface decision, not a content operation
The code only chooses which editor loads and never touches saving, publishing or stored content.
Administrator-only configuration
Only an administrator with access to TheOneWP settings can choose which post types use the classic editor.
A read-only editor selection
The module only decides which editor interface loads; it doesn't process or store any content itself.
No effect on saving or publishing
Switching editors changes the writing interface only; the underlying save, revision and publishing behaviour of WordPress is untouched.
The frontend CSS removal is explicitly opt-in
The stylesheet dequeue only happens if its own separate toggle is turned on, with a clear warning about theme dependency.
Built around native WordPress editor filters
The supplied code integrates through APIs present in WordPress core. No compatibility claim beyond the verified implementation is assumed.
use_block_editor_for_post_type
The standard WordPress filter for choosing which editor a post type gets, the same one WordPress core itself checks.
use_widgets_block_editor and its Gutenberg-plugin counterpart
Both the core filter and the equivalent used by the standalone Gutenberg plugin are covered, when Gutenberg is disabled globally.
should_load_remote_block_patterns
The documented filter for controlling whether WordPress fetches block pattern suggestions from WordPress.org.
TheOneWP versus common alternatives
Compare the verified Disable Gutenberg implementation with a typical dedicated classic-editor plugin.
| Capability | TheOneWP Disable Gutenberg | Other common solutions |
|---|---|---|
| Restoring the classic editor | A checkbox per post type, applied instantly | Usually a separate plugin or a functions.php snippet |
| Per-post-type control | Choose exactly which types keep the classic editor | Frequently all-or-nothing across the whole site |
| The Widgets screen | Handled automatically, scoped correctly | Often left inconsistent with the post editor setting |
| Front-end CSS cleanup | A separate, explicit opt-in toggle | Rarely offered alongside a simple classic-editor switch |
| Administration | One settings panel inside TheOneWP | Requires installing and configuring a dedicated plugin |
Restore the classic editor in four steps
Test the optional CSS cleanup carefully before relying on it.
Enable Disable Gutenberg
Activate the module from the TheOneWP settings.
Choose which post types keep the classic editor
Check the specific post types that should use it, or leave every box unchecked to disable the block editor entirely.
Decide on the front-end CSS
Enable the separate stylesheet-removal toggle only after confirming the active theme doesn't rely on block styles.
Check both editors are behaving as expected
Open a post from each affected type to confirm the intended editor loads.
Choose deliberately, test before relying on it
A little care around the CSS toggle and post type selection avoids most surprises.
Select post types deliberately
Base the checkbox selection on which post types actually benefit from the classic editor, rather than disabling blocks everywhere by default.
Test the front-end CSS toggle carefully
Confirm the site's layout still looks correct after enabling the stylesheet removal, since some themes do rely on those styles.
Remember content isn't converted
Switching editors is safe to experiment with, since it only changes the interface, not what's stored in the post.
Revisit the selection after adding new post types
A newly registered post type, from a new plugin or a custom one, needs its own checkbox decision.
Avoid assumptions that produce the wrong editor
The checkbox semantics and CSS toggle are both easy to misread on a first glance.
Assuming an empty selection means "no change"
Leaving every post type unchecked doesn't mean nothing happens; it disables the block editor for every post type at once.
Enabling the CSS removal without checking the theme
The front-end stylesheet toggle is explicitly marked for use only when the theme doesn't rely on block styles; skipping that check can break layout.
Expecting the Widgets screen to follow a per-post-type setting
The widget block editor only gets disabled when Gutenberg is off globally, not when only specific post types are selected.
Disable Gutenberg FAQ
These answers come directly from the verified class and its settings registration.
What does Disable Gutenberg do?
It restores the classic editor for selected post types, or for every post type at once if none are selected, without converting any stored content.
What happens if I leave every post type unchecked?
The block editor gets disabled across the entire site, not left unchanged; an empty selection means a global disable.
Does this convert my content when I switch editors?
No. Switching editors only changes which interface an author sees; the content stored in the post stays exactly as it was.
Does this affect the Widgets screen too?
Only when the block editor is disabled globally, with no specific post types selected; targeting specific post types leaves the Widgets screen unaffected.
Will this stop WordPress from fetching remote block patterns?
Yes. The module disables that remote request from api.wordpress.org, since it serves no purpose once the block editor is off.
Should I remove block editor styles from the front end?
Only if the active theme doesn't rely on them; the setting exists as a separate, optional toggle for exactly that situation.
Can I use the block editor for Posts but the classic editor for a custom post type?
Yes. Each registered post type, except attachments, gets its own independent checkbox.
Does this module affect the Media Library editor?
No. Attachments are explicitly excluded from the post type list this module controls.
Is it safe to switch back and forth between editors?
Yes. Since content isn't converted either way, changing the setting is low-risk to experiment with.
Who can change which post types use the classic editor?
Only an administrator with access to the TheOneWP settings screen.
Stop fighting an editor your workflow was never built around.Bring back the classic editor where it belongs.
Use Disable Gutenberg to restore the classic editor for exactly the post types that need it, with your content completely untouched.