Disabling Gutenberg on certain templates

It can be relatively straightforward to make your simple content pages ready for Gutenberg, but complex pages are different.

Consider a modular homepage with complex full-width sections. While you could build many custom blocks to implement this (as I’ve done on my homepage), it might be easier and faster to use the metabox plugin you already know.

Using a plugin

The Classic Editor plugin is great for disabling Gutenberg site-wide, but is not a good choice for selectively using it on certain pages.

Gutenberg Ramp lets you disable Gutenberg on a per-post-type basis. You could use Gutenberg for posts, but keep the classic editor for pages.

Using a filter

We can use the use_block_editor_for_post_type filter for more fine-grained control. It passes two parameters:

  • $can_edit, boolean, whether Gutenberg should be used to edit
  • $post_type, string

I use $_GET['post'] to get the current Page ID from the URL. If that page is using certain templates, I’ll disable the Gutenberg editor. I also use a similar function to remove the classic editor for current WordPress installs.

I create a disable-editor.php file in my theme and update the $excluded_templates and $excluded_ids arrays specify where I want the editor turned off.

This disables both the Gutenberg Block Editor and Classic Editor, allowing me to use a metabox for constructing the editing experience.

<?php
/**
 * Disable Editor
 *
 * @package      ClientName
 * @author       Bill Erickson
 * @since        1.0.0
 * @license      GPL-2.0+
**/

/**
 * Templates and Page IDs without editor
 *
 */
function ea_disable_editor( $id = false ) {

	$excluded_templates = array(
		'templates/modules.php',
		'templates/contact.php'
	);

	$excluded_ids = array(
		// get_option( 'page_on_front' )
	);

	if( empty( $id ) )
		return false;

	$id = intval( $id );
	$template = get_page_template_slug( $id );

	return in_array( $id, $excluded_ids ) || in_array( $template, $excluded_templates );
}

/**
 * Disable Gutenberg by template
 *
 */
function ea_disable_gutenberg( $can_edit, $post_type ) {

	if( ! ( is_admin() && !empty( $_GET['post'] ) ) )
		return $can_edit;

	if( ea_disable_editor( $_GET['post'] ) )
		$can_edit = false;

	return $can_edit;

}
add_filter( 'gutenberg_can_edit_post_type', 'ea_disable_gutenberg', 10, 2 );
add_filter( 'use_block_editor_for_post_type', 'ea_disable_gutenberg', 10, 2 );

/**
 * Disable Classic Editor by template
 *
 */
function ea_disable_classic_editor() {

	$screen = get_current_screen();
	if( 'page' !== $screen->id || ! isset( $_GET['post']) )
		return;

	if( ea_disable_editor( $_GET['post'] ) ) {
		remove_post_type_support( 'page', 'editor' );
	}

}
add_action( 'admin_head', 'ea_disable_classic_editor' );

Bill Erickson

Bill Erickson is a freelance WordPress developer and a contributing developer to the Genesis framework. For the past 14 years he has worked with attorneys, publishers, corporations, and non-profits, building custom websites tailored to their needs and goals.

Ready to upgrade your website?

I build custom WordPress websites that look great and are easy to manage.

Let's Talk

Reader Interactions

Comments

  1. Hermann LAHAMI says

    Do you think that Gutemberg can one day make popular page builders such as VC, elementor and other obsolete? I’m really curious about it

    • Bill Erickson says

      I believe Gutenberg will definitely have an effect on page builders. Many people turned to page builders because they were disappointed with the flexibility of TinyMCE, which Gutenberg is trying to fix.

      But I think there will always be a role to play for page builders on top of (or instead of) Gutenberg. WordPress core won’t go as far with Gutenberg as the page builders have.

    • Paul Herrick says

      It will affect the page builders.
      As i am using Cosmic Blocks(WordPress 5.0 Gutenberg Blocks Collection) & it helped me a lot to add stunning animations to your blocks to make your website looks great.
      https://cosmicwp.com/

  2. Claire Coupland says

    Hi. If i install your ‘Disable Gutenberg’ plugin BEFORE WordPress 5.0 rolls out, will it disable Gutenberg when v5.0 is installed?

    • Bill Erickson says

      Yes it will. You can install it now, and once WP 5.0 is out it will automatically disable Gutenberg.

      You can also install the Classic Editor plugin now. They’ve fixed the issues I described above.

  3. Valentin Genev says

    Thank you very much for this post, it works like a charm!

    I’m using ACF (custom fields) for some of my templates and they mix better with the old editor’s page. Plus, I’ll be avoiding questions like “Why don’t we just use the block ‘Gallery’ from the plus in the top left corner of the window?”. 😀

    I would love to buy you a coffee when I get my honorarium paid.

    • Bill Erickson says

      No, I haven’t used that plugin before. I recommend sticking with the Classic Editor plugin since it’s the recommendation from WP core and will stay up-to-date with new Gutenberg changes.

  4. Steven says

    Is it possible to add some comments as to what the code is doing in each section? I’m not really sure how to add my templates to ignore, or specific post id or pages.

    • Bill Erickson says

      The only code you need to modify is lines 17-24. That lets you specify a list of page templates and/or a list of post IDs to exclude.

      The ea_disable_editor() function determines if the current post should have the editor disabled, based on the IDs / templates you’ve set to exclude.

      That value (true/false) is then used by the two following two functions to disable the Gutenberg editor and the Classic editor for that post.

      I built it this way so you have a single list to maintain rather than duplicating the list for Gutenberg and Classic.

  5. Jon Schroeder says

    Bill, I have a plugin which registers different ACF fields on different templates, some of which can use Gutenberg, and some of which can’t. I’ve been able to implement your (fantastic) example above to disable Gutenberg for one of those templates, that we’ll call “custom.”

    Here’s the weird behavior that happens in the page editor:

    I’m on a “custom” template page, with Gutenberg disabled. I change the page template from “custom” to “default”, then update. Gutenberg appears, everything’s great, looks perfect.

    If I try to go the other direction though, changing my template from “default” to “custom,” then save, then Gutenberg stays present until I do a page refresh, and the ACF fields don’t automatically refresh either.

    I figure this might be a situation you’ve come across before. Any tips?

    • Bill Erickson says

      Yes, this is because Gutenberg updates without refreshing the page, while the classic editor did refresh it.

      This approach only works when the page initially loads (it removes the editor on the admin_head hook). If the state of the document changes without reloading, our code never gets a chance to run again.

      To fix this, you’d need to add JavaScript to the Gutenberg editor that monitors for a change in page template and reloads the page if the non-Gutenberg template is saved. You couldn’t just watch for the dropdown to change – you’d need to wait until the post is actually saved / updated to trigger your change.

      I haven’t tried to build something like this, but if you do, please share the code here!

  6. Allyson Souza says

    Thanks for the post Bill! It’s exactly what we’re searching for here. We’re developing a custom theme for a company and there’s not too much reasons to make frontpage “block editable”, we just want to present some meta fields to make content editable, and that’s all.

Leave A Reply