How to remove core WordPress blocks

While I try to support all the core blocks in the themes I build, sometimes it makes sense to remove a few.

Typically it’s because I built a custom block that’s similar to a core block while addressing the design and functional requirements of the theme. Most of my themes include a “Content and Image” block that’s similar to the “Media & Text” block but it uses the theme’s grid layout.

Sometimes I’ll unregister the “Search” block and create my own that uses the searchform.php file in the theme, ensuring the Search block matches the design and functionality of the search form used everywhere else in the theme.

Enqueue block editor assets

You can use the enqueue_block_editor_assets hook to load scripts and styles into the block editor. My themes typically have an editor.js file that I use for block styles and unregistering block types.

I also enqueue any custom fonts used on the frontend so I can also use them in the editor styles.

/**
 * Gutenberg scripts and styles
 *
 */
function be_gutenberg_scripts() {
	wp_enqueue_style( 'theme-fonts', be_theme_fonts_url() );
	wp_enqueue_script( 'theme-editor', get_template_directory_uri() . '/assets/js/editor.js', array( 'wp-blocks', 'wp-dom' ), filemtime( get_template_directory() . '/assets/js/editor.js' ), true );
}
add_action( 'enqueue_block_editor_assets', 'be_gutenberg_scripts' );

/**
 * Theme Fonts URL
 *
 */
function be_theme_fonts_url() {
	return 'https://fonts.googleapis.com/css2?family=Roboto+Slab&display=swap';
}

Unregister block type

Now that you’ve created an editor.js file and enqueued it into the block editor, you can use wp.blocks.unregisterBlockType to unregister block types.

wp.domReady( () => {
	wp.blocks.unregisterBlockType( 'core/media-text' );
	wp.blocks.unregisterBlockType( 'core/search' );
} );

Here’s a list of all the core block types.

Unregister blocks everywhere

The above code only unregisters the block from the “Edit Post” screen. If you’re trying to remove blocks from the Widgets screen, Full Site Editor, or Template Parts, you’ll need to adjust the dependencies.

Please refer to Jason Lemahieu’s article for more information: How to Unregister WordPress Blocks (from everywhere!)

Bill Erickson

Bill Erickson is the co-founder and lead developer at CultivateWP, a WordPress agency focusing on high performance sites for web publishers.

About Me
Ready to upgrade your website?

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

Let's Talk

Reader Interactions

Comments are closed. Continue the conversation with me on Twitter: @billerickson

Comments

  1. Hung says

    Thanks for sharing. I however always wonder if this kind of removing creates more processes for system? Because the system is initiated aready, all default code has been processed. Then another script for removing a part of the system.

    It seems to be better in GUI but more requests need to be done? Please correct me if I am wrong.

    • Bill Erickson says

      I’m not familiar enough with the underlying Gutenberg codebase to know whether this approach has a performance impact. I agree, loading a separate JavaScript file to remove items added by another JavaScript file doesn’t seem ideal, but that seems to be the way things are done with React.

    • Tania says

      Yes, Sören, we can use the filter allowed_block_types, but it has a known misbehaviour in conjunction with WP_Block_Type_Registry::get_instance()->get_all_registered() which does not return all blocks. So when using the filter you may miss some other blocks, see https://github.com/WordPress/gutenberg/issues/12931 .

      So Bill’s approach was really helpful for me to disable just one specific block without loosing further ones.

  2. Jason LeMahieu says

  3. Elvis Krstulovic says

    Hello,
    thanks for sharing the method to hide individual blocks. I have so far ony used a “allowed_block_types” php method.

    Would it be possible to use this method conditionaly per user group, or per user?

    For context:
    I am trying to have a scenario where user group has some custom patterns available for them, and just some basic content blocks. Hoever, If I remove layout blocks (columns for example) then patterns which use this block are dissabled too.

    So I am thinking this mught be the way to deal with this scenatio. Tho it is deregistering these blocks too. 🙁

    • Bill Erickson says

      I’m not very familiar with the WordPress JS API. I’m sure there’s a way to access the current user’s ID / capabilities using the wp object, but I don’t know it offhand. A messy but simple solution would be to enqueue different JavaScript files based on the user’s capabilities, so you can use the PHP current_user_can().