The Problem: Cluttered Gutenberg Inserter
When you hand over a custom WordPress site to a client, the last thing you want is for them to break their carefully crafted layout by inserting default WordPress block patterns. By default, Core registers dozens of patterns (like multi-column call-to-actions, headers, and query loops) that rarely match your custom theme’s design system.
To deliver a clean, bulletproof editing experience, you need to strip out these default patterns. We can achieve this cleanly using your theme’s functions.php file without relying on bloated plugins.
Step-by-Step Implementation
1. Disable All Core Block Patterns
WordPress registers default patterns during the theme setup phase. You can disable all bundled local patterns by removing the core-block-patterns theme support feature. Add this code snippet to your theme’s functions.php:
/**
* Disable core Gutenberg block patterns
*/
function learncodewp_remove_core_block_patterns() {
remove_theme_support('core-block-patterns');
}
add_action('after_setup_theme', 'learncodewp_remove_core_block_patterns');2. Disable Remote Patterns from the WordPress.org Directory
Even after removing local core patterns, Gutenberg will still pull in remote patterns from the official WordPress.org Pattern Directory. This can slow down the editor and introduce unexpected layout choices. Disable this remote API request with this simple filter:
/**
* Prevent loading remote patterns from the WordPress.org directory
*/
add_filter('should_load_remote_block_patterns', '__return_false');3. Unregister Specific Core Patterns (Selective Removal)
If you want to keep some core patterns but remove specific annoying ones (such as the Query Loop patterns), you cannot use remove_theme_support. Instead, you must unregister them individually using unregister_block_pattern().
Because patterns are registered on the init hook, you must hook your removal function to init with a higher priority (e.g., 100) to ensure it runs after registration occurs:
/**
* Unregister specific core block patterns
*/
function learncodewp_unregister_specific_patterns() {
// Check if the pattern exists before trying to unregister it
if (WP_Block_Patterns_Registry::get_instance()->is_registered('core/query-standard-posts')) {
unregister_block_pattern('core/query-standard-posts');
}
if (WP_Block_Patterns_Registry::get_instance()->is_registered('core/query-grid-posts')) {
unregister_block_pattern('core/query-grid-posts');
}
}
add_action('init', 'learncodewp_unregister_specific_patterns', 100);Pro Tips & Gotchas
- The Priority Hook Gotcha: When selectively unregistering patterns, always use a high priority number (like
100or999) on theinitaction. If you run it at the default priority (10), the pattern might not be registered yet, resulting in a PHP warning. - Child Themes: If you are working on a child theme, make sure your code runs after the parent theme setup by using a higher priority on
after_setup_themeif the parent theme registers its own custom patterns. - Keep Your Patterns Organized: If you want to register your own clean patterns, do so using
register_block_pattern()on theinithook after stripping out the core clutter.
Troubleshooting & FAQ
Why are core patterns still showing up in my editor?
This is usually caused by remote patterns. If you only used remove_theme_support('core-block-patterns'), WordPress will still load patterns dynamically from the WordPress.org directory. Ensure you have added the should_load_remote_block_patterns filter to your functions.php.
Can I disable patterns for specific user roles?
Yes. You can wrap your removal functions in a capability check. For example, to only show patterns to administrators while hiding them for editors, wrap the hook in current_user_can('manage_options') checks.
Will this break my custom block patterns?
No. remove_theme_support('core-block-patterns') only targets default patterns registered by the WordPress core. Any custom patterns you register via register_block_pattern() or place in your theme’s /patterns/ directory will remain completely functional.
