Disable Patterns tab

[christofervas]

Description

I use the following code to disable the Pattern directory but after upgrading to WordPress 6.6.1 the Patterns tab is showing even without contain any patterns. Is this a bug?

https://developer.wordpress.org/block-editor/how-to-guides/curating-the-editor-experience/disable-editor-functionality/#disable-the-pattern-directory

I also use the following: add_filter( 'should_load_remote_block_patterns', '__return_false' );

Step-by-step reproduction instructions

Add the following code. The Patterns tab is still showing up.

function example_theme_support() {
    remove_theme_support( 'core-block-patterns' );
}
add_action( 'after_setup_theme', 'example_theme_support' );

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• [X] Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• [X] Yes

[carolinan]

Hi These code snippets only disable the patterns added by WordPress core, and the patterns from https://wordpress.org/patterns/. Not the ability to manage patterns added by users, themes or plugins.

[christofervas]

Hey @carolinan thanks for clarifying this. Is there any way to disable the Patterns tab? Even on a clean installation with no patterns installed from theme, core, user etc. the Patterns tab is still shown with a notice "No results found."

[carolinan]

I don't have the answer off the top of my head but it would probably be about changing the permissions for different user roles.

[fgbarrios]

The code provided didn't worked for me. This one did worked:

function remove_menus_appearance_patterns(){  
    // Appearance > Patterns  
    remove_submenu_page('themes.php', 'site-editor.php?path=/patterns');  
}  
add_action('admin_menu', 'remove_menus_appearance_patterns');

[carolinan]

The code above only removes the menu item from the WordPress admin menu. Not the patterns tab.

[Codeyak]

I have run into this as well. Up until WP v6.6 (Gutenberg v18.5, I think), removing theme support for 'core-block-patterns' did the trick. Now I need to use a CSS hack, which is never reliable. As new versions role out, it's not uncommon for classnames to change.

(On a side note, not related to this ticket, would also like to remove the Media tab, too)

[meksone]

I have run into this as well. Up until WP v6.6 (Gutenberg v18.5, I think), removing theme support for 'core-block-patterns' did the trick. Now I need to use a CSS hack, which is never reliable. As new versions role out, it's not uncommon for classnames to change.

(On a side note, not related to this ticket, would also like to remove the Media tab, too)

I'm confirming this behaviour: it's important to clean Gutenberg interface for customer's site; actually doing through CSS

[carolinan]

Can you all add more detailed information about what part of the UI you are looking to hide? It is unclear if the same parts of the UI are being discussed here.

[meksone]

Can you all add more detailed information about what part of the UI you are looking to hide? It is unclear if the same parts of the UI are being discussed here.

Hi, thanks for asking :) I think we are discussing this section of the interface (at least, I want to hide this part):

[snibe]

I am running into the same thing, did anyone ever get a solution to this?

[rico347]

Any updates to this?

[rico347]

Right now I am using the following css for this problem:

.block-editor-tabbed-sidebar__tab[aria-controls*="patterns"], .block-editor-tabbed-sidebar__tab[aria-controls*="media"] { display: none !important; }

[marziodev]

@fgbarrios - previous solution doesn't work any longer (5th june, 2025): replace "path" with "p" and "patterns" with "pattern".

// Remove Gutenberg patterns from the menu
function remove_menus_appearance_patterns(){  
    // Appearance > Patterns  
    remove_submenu_page('themes.php', 'site-editor.php?p=/pattern');  
}  
add_action('admin_menu', 'remove_menus_appearance_patterns');

[Web-Assembler]

Right now I am using the following css for this problem:

.block-editor-tabbed-sidebar__tab[aria-controls*="patterns"], .block-editor-tabbed-sidebar__tab[aria-controls*="media"] { display: none !important; }

That worked for me - but I also needed to add some extra CSS to remove the gradient mask on the tabs:

.block-editor-tabbed-sidebar__tablist { mask-image: none !important; }

[tellthemachines]

It does feel a bit unexpected to have a completely empty patterns tab when there are no patterns available:

Would be good to double-check this one with design folks. Should we hide the tab if there are no patterns? Cc @WordPress/gutenberg-design

[jasmussen]

Should we hide the tab if there are no patterns?

Thanks for the ping, and I'd love to open that question even more broadly. Certainly it's not a good experience to see something permanently empty, but other options are to link to the core pattern directory, or link to the site editor pattern manager. For me it boils down to: what is the spirit of the API? If as Carolina notes it is to disable the core patterns, then the tab should not go away, it should just have a better empty-state. Presumably if you create a pattern yourself, synced or otherwise, then it would show up here.

If we did want an API to disable the patterns tab, IMO that same API should also disable the editor > Manage patterns link, the site editor Patterns section, the ability to create a pattern (both synced and unsynced), because all of those entrypoints would each be similarly confusing, as an empty inserter tab is. And this feels like a fairly wide-reaching API that I'm not sure is actually what we want.

[tellthemachines]

Thanks for the prompt reply @jasmussen!

I wasn't thinking of an API to disable the patterns tab because as you say that would require disabling patterns everywhere in order to work well. But we could perhaps only show the patterns tab if there are any patterns to show, instead of showing it empty. Then, as soon as the user created a pattern, or switched to a theme with patterns, the tab would reappear. I haven't looked into how straightforward that would be to implement yet, just wondering whether it's something we might want to do.

[jasmussen]

Yep, that's valid, I'm just not sure what problem it solves. The patterns menu item will still be there even if your theme doesn't have any patterns, and it boils down to the fact that patterns are enabled as a feature: you can create your own, synced and unsynced. The theoretical benefit of disabling the tab is that a small interface of the editor is cleaner for people who do not use the feature at all. But it's at the cost of a little bespoke conditional code for just that, and the potential opportuntity cost that people don't learn about what patterns can do, which especially if the contentOnly changes graduate from experimental, really elevate the experience. From that perspective, the missing opportunity here is to show something better—even clearer help text that explains the what and why of patterns—in the empty patterns tab.

[tellthemachines]

Ok that makes sense! Let's give the patterns feature some more time to mature before hiding any UI. I'll go ahead and close this one for now. Thanks everyone!