A carefully built WordPress page template can be damaged surprisingly quickly when someone opens it in the wrong editor, changes a block, and saves without realising what sits behind the layout. If you need to disable Gutenberg on page templates, the aim is not to make WordPress harder to use. It is to give your team clearer boundaries: flexible editing where it is safe, and protected templates where structure matters.
For a disability support website, this can be especially helpful. Service information, referral pathways, contact forms and accessibility-focused page layouts need to stay clear and consistent for participants, families, coordinators and hospital teams. A stable editing process supports that outcome.
Why disable Gutenberg on selected templates?
Gutenberg, also called the WordPress Block Editor, is useful for many everyday pages and posts. It allows staff to add headings, images, buttons and text without needing to work in code. For news updates, event notices or straightforward service information, that flexibility is often a good fit.
Page templates are different. A template may contain custom fields, fixed sections, reusable design elements or code that expects content in a particular format. Opening that template in Gutenberg can create confusion, particularly if the page was originally built with the Classic Editor, a page builder or custom meta boxes.
Disabling Gutenberg for a template can help you preserve the intended layout, reduce accidental changes and make staff training simpler. It is also useful when a developer has created a custom page type with a specific purpose, such as a referral landing page or a participant enquiry form.
There is a trade-off. Restricting the editor means an administrator may need a little more WordPress knowledge to update those pages. For that reason, it is usually best to disable Gutenberg only where there is a genuine technical reason, rather than turning it off across the entire site by default.
Choose the right approach first
There are three common ways to manage Gutenberg on page templates. The best option depends on how your website was built and who is responsible for maintaining it.
If you simply want the Classic Editor back across the whole website, a dedicated Classic Editor plugin is the quickest option. Just install, activate, select the preferred editor in Settings, and done! This suits sites where all existing pages were created in the older editor and no one needs block editing.
If Gutenberg should remain available for most pages but not for a few custom templates, use a small code snippet in a child theme or a safe code-snippet plugin. This is usually the cleanest approach because it targets the problem rather than changing everyone’s editing experience.
If your website uses a page builder, check its own settings before adding code. Some builders provide an editor switch, template restrictions or a dedicated editing screen. Adding a second control on top can cause conflicts, so keep the configuration as simple as possible.
Disable Gutenberg on page templates with code
WordPress provides a filter called `use_block_editor_for_post`. It lets a developer decide whether the Block Editor should load for a particular page. The example below disables Gutenberg only when a selected page template is in use:
“`php add_filter( ‘use_block_editor_for_post’, function( $use_block_editor, $post ) { if ( $post && ‘page’ === $post->post_type ) { $template = get_page_template_slug( $post->ID );
if ( ‘templates/referral-page.php’ === $template ) { return false; } }
return $use_block_editor; }, 10, 2 ); “`
Place this code in the `functions.php` file of a child theme, or add it through a reputable code-snippet tool. Avoid placing custom changes directly in a parent theme. Theme updates can overwrite the file and remove the setting without warning.
Replace `templates/referral-page.php` with the exact template filename used on your site. You can usually confirm the active template by opening the page in the WordPress dashboard and checking the Template panel under Page settings. If the template is called `service-area.php`, for example, that is the value your code needs to check.
After saving the snippet, open a page using that template. WordPress should load the Classic Editor or the editor provided by your existing setup instead of Gutenberg. Open an ordinary page as well to confirm that the Block Editor is still available where you expect it.
Restrict more than one template
Where several templates need protection, place their filenames in an array. This is easier to maintain than repeating the same condition several times.
“`php add_filter( ‘use_block_editor_for_post’, function( $use_block_editor, $post ) { $restricted_templates = array( ‘templates/referral-page.php’, ‘templates/contact-page.php’, ‘templates/service-page.php’, );
if ( $post && ‘page’ === $post->post_type ) { $template = get_page_template_slug( $post->ID );
if ( in_array( $template, $restricted_templates, true ) ) { return false; } }
return $use_block_editor; }, 10, 2 ); “`
Keep a short internal note beside the code explaining why each template is restricted. Six months later, another administrator should not have to guess why one page opens differently from the rest of the website.
Check custom post types separately
A page template is not the same as a custom post type. Your website may have custom content areas for staff profiles, testimonials, service listings or resources. Those areas can also use Gutenberg, but they need their own rules.
For example, if a custom post type has an editing screen built around custom fields, use the same filter and check for the relevant post type instead of `page`. Do not assume that disabling Gutenberg for a page template will affect these screens.
This distinction matters because a tailored editing interface can protect essential fields. A support service listing might require a title, short description, service category and enquiry action in specific places. Allowing free-form blocks on that screen may make the page harder to keep consistent and accessible.
Test before staff use the new setting
Do not make this change on a live site without first checking it in a staging environment, if one is available. A small code error can prevent the editor from loading or affect all pages rather than one template.
Test the exact template, a standard page and any pages using a builder. Confirm that existing text, images, forms and custom fields remain visible after editing and saving. Check the public page on a mobile as well as a desktop browser. If the website has caching, clear the cache after publishing the change.
It is also wise to take a backup before changing theme files or adding code. A backup is not just an emergency measure. It gives you permission to test carefully and restore quickly if an editor setting behaves differently from expected.
Give editors clear instructions
Technical controls work best with plain instructions. Let staff know which pages are safe to edit in Gutenberg, which pages use a protected template, and who to contact when a layout needs changing. A short note in your internal website guide can prevent a well-meaning update from becoming a time-consuming repair.
For sites supporting people with disability, consistency is part of good communication. Clear headings, predictable buttons and stable contact information make it easier for visitors to find support without unnecessary effort. Protect the templates that carry that responsibility, while keeping everyday content simple for your team to update.
If a template feels too restrictive, review the editing workflow rather than immediately reopening it to every block. The best setup is the one that gives authorised staff enough control to keep information current, while protecting the structure visitors rely on.
