A WordPress website for disability support has more than ordinary blog posts. It may hold service information, referral guidance, participant resources, staff updates and carefully approved pages that families rely on. When you disable Gutenberg by post type, you can keep the block editor where it helps while protecting the content areas that need a familiar, controlled editing experience.
That choice is not about declaring one editor better than another. It is about reducing accidental layout changes, making updates less stressful for administrators, and keeping established workflows intact. For a community-facing site, a broken service page is not just a technical nuisance. It can make it harder for someone to find the support they need.
Why disable Gutenberg by post type?
Gutenberg is WordPress’s block editor. It is useful for creating flexible page layouts, adding media and building content without writing code. But flexibility can become a liability when several people update a website, particularly if they have different levels of WordPress confidence.
A page built with a legacy page builder, custom fields or carefully formatted shortcodes can look very different after an editor switch. Staff may also be used to the Classic Editor for news items and notices, where the editing screen is simpler and less likely to invite unintended design changes.
Disabling Gutenberg selectively gives you a practical middle ground. You might retain blocks for Pages, where a web administrator creates modern landing pages, while using the Classic Editor for Posts, staff notices, testimonials, resources or a custom post type created for service listings.
The correct setup depends on how the site is built. If every post type uses modern block-based templates, turning Gutenberg off can create more work. If a post type depends on a legacy editor or custom metabox workflow, selective control is usually the safer option.
Check your post types before changing editors
In WordPress, a post type is simply a kind of content. Posts and Pages are the built-in examples. Your website may also have custom post types such as Services, Team Members, Locations, Events, Resources or FAQs.
Do not make this change blindly. Open a few existing entries from each post type and check what the edit screen contains. Look for page-builder panels, custom fields, shortcodes, document upload fields, referral forms or structured service details. These are signs that consistency matters more than a new editing interface.
Also check who actually edits each area. A developer may be comfortable with blocks, while an office administrator updating a holiday closure notice may prefer the familiar toolbar of the Classic Editor. The best configuration reflects both the technical structure of the site and the people responsible for it.
The quickest option: use a Classic Editor control plugin
For most administrators, a dedicated editor-control plugin is the sensible path. It avoids editing theme files and lets you change settings without putting your customisations at risk during a theme update.
Install a well-maintained plugin that supports both the Classic Editor and Gutenberg controls. After activation, its settings are commonly found under Settings > Writing. The exact wording differs by plugin, but look for options to choose the default editor and to allow switching between editors.
If the plugin provides a post-type selection screen, enable the Classic Editor only for the content types that need it. For example, you could leave Gutenberg active on Pages and switch it off for Posts and Resources. Save the settings, then open an existing item and a new item in each relevant post type to confirm the expected editor appears.
A good plugin approach also gives editors a recovery path. Some tools show a link such as “Edit (Classic)” or “Edit (Block Editor)” in the post list. That can be useful during a gradual transition, but only if staff understand when to use each option. Too much choice can create inconsistent formatting.
Keep the configuration screen available at first
Do not hide the settings screen immediately. Run the setup for a few weeks, collect feedback from the people entering content, and make sure routine updates are working properly. Once the workflow is stable, a site administrator can restrict access to the configuration area if needed.
This is particularly helpful where multiple coordinators, communications staff or external web contractors share responsibility for the website. The editor choice should be intentional, not changed accidentally during a quick update.
Developer option: control Gutenberg with a filter
If you manage a custom theme or a small site-specific plugin, WordPress provides a direct way to disable the block editor for a particular post type. Add the following code to a site-specific plugin or a child theme’s functions file:
“`php add_filter( ‘use_block_editor_for_post_type’, function( $use_block_editor, $post_type ) { if ( in_array( $post_type, array( ‘post’, ‘resource’ ), true ) ) { return false; }
return $use_block_editor; }, 10, 2 ); “`
In this example, Gutenberg is disabled for regular Posts and a custom post type called `resource`. Gutenberg remains active for every other post type, including Pages.
Replace `resource` with the actual post type key used on your website. The menu label is not always the key. A section labelled “Service Information” may have a technical key such as `services` or `support_service`. A developer can confirm this quickly, or you can inspect the post type registration in the relevant plugin.
Use a site-specific plugin rather than a parent theme whenever possible. Themes are designed to control presentation. Editor behaviour is a site function, so it should survive a future redesign. Just activate it and done – but test it first on a staging copy if the site has complex templates or integrations.
When a filter is not enough
Some plugins register their own edit screens, force block-editor support, or use custom fields that are designed for Gutenberg. Others may add blocks to a post type specifically because they need block data. In these cases, a filter may disable the editor but leave an awkward or incomplete publishing workflow.
Test publishing, updating, revisions, scheduled posts, media uploads and any front-end display templates. If you use an SEO plugin, check that its fields still appear in the editor you selected. The editor is only one part of the content system.
Common problems and practical fixes
The most common issue is caching. If a change appears not to work, clear any WordPress cache, server cache and browser cache, then log out and back in. Editor capabilities are sometimes loaded from cached settings.
Another issue is user roles. An administrator may see editor-switching options that an editor or author cannot see. Test with the same role used by the people who publish real content. This avoids a frustrating handover where the setup works perfectly for the person who installed it but not for the team using it daily.
Be careful with existing block content. Disabling Gutenberg does not delete it, but opening a complex block-built post in the Classic Editor can expose block markup rather than a clean visual layout. Keep Gutenberg enabled for content that was built heavily with blocks, or plan a proper conversion before changing the editor.
If one post type includes both simple and complex content, separate it. For instance, routine announcements could remain standard Posts using the Classic Editor, while campaign pages stay as Pages using blocks. Clear content structure is easier to maintain than trying to make one editor suit every job.
Use editor choice to protect essential information
For organisations supporting people with disability, website clarity is part of good service. Keep referral instructions, contact details, eligibility information and urgent update processes easy for authorised staff to maintain. The aim is not to make WordPress more technical. It is to remove unnecessary opportunities for content errors.
At Holy Care Support Services, a practical website workflow should let staff update useful information confidently while leaving core layouts stable. Document which post types use which editor, who can change those settings and what to do if an edit screen looks unfamiliar. A one-page internal note can prevent a lot of avoidable back-and-forth.
Choose the editor that makes the next update safer, not the one that looks newest. When the right person can publish a clear, accurate change without worrying about breaking the page, your WordPress setup is doing its job.
