Extensibility Edit

Extensibility is key for WordPress and like the rest of WordPress components, Gutenberg is highly extensible.

Creating Blocks Creating Blocks

Gutenberg is about blocks and the main extensibility API of Gutenberg is the Block API. It allows you to create static blocks, dynamic blocks rendering on the server and also blocks saving data to Post Meta for more structured content.

Here is a small example of a static custom block type (you can try it in your browser’s console):

var el = wp.element.createElement;

wp.blocks.registerBlockType( 'mytheme/red-block', {
    title: 'Red Block',
    icon: 'universal-access-alt',
    category: 'layout',
    edit: function() {
        return el( 'div', { style: { backgroundColor: '#900', color: '#fff', padding: '20px' } }, 'I am a red block.' );
    save: function() {
        return el( 'div', { style: { backgroundColor: '#900', color: '#fff', padding: '20px' } }, 'I am a red block.' );
} );

If you want to learn more about block creation, The Blocks Tutorial is the best place to start.

Top ↑

Removing Blocks Removing Blocks

Using a blacklist Using a blacklist

Adding blocks is easy enough, removing them is as easy. Plugin or theme authors have the possibility to “unregister” blocks.

// myplugin.js

wp.blocks.unregisterBlockType( 'core/verse' );

and load this script in the Editor

// myplugin.php

function myplugin_blacklist_blocks() {
        plugins_url( 'myplugin.js', __FILE__ ),
        array( 'wp-blocks' )
add_action( 'enqueue_block_editor_assets', 'myplugin_blacklist_blocks' );

Top ↑

Using a whitelist Using a whitelist

If you want to disable all blocks except a whitelisted list, you can adapt the script above like so:

// myplugin.js
var allowedBlocks = [

wp.blocks.getBlockTypes().forEach( function( blockType ) {
    if ( allowedBlocks.indexOf( blockType.name ) === -1 ) {
        wp.blocks.unregisterBlockType( blockType.name );
} );

Top ↑

Hiding blocks from the inserter Hiding blocks from the inserter

On the server, you can filter the list of blocks shown in the inserter using the allowed_block_types filter. you can return either true (all block types supported), false (no block types supported), or an array of block type names to allow.

add_filter( 'allowed_block_types', function() {
    return [ 'core/paragraph' ];
} );

Top ↑

Modifying Blocks (Experimental) Modifying Blocks (Experimental)

To modify the behaviour of existing blocks, Gutenberg exposes a list of filters:

blocks.registerBlockType blocks.registerBlockType

Used to filter the block settings. It receives the block settings and the name of the block the registered block as arguments.

Top ↑

blocks.BlockEdit blocks.BlockEdit

Used to modify the block’s edit component. It receives the original block edit component and returns a new wrapped component.

Top ↑

blocks.getBlockDefaultClassName blocks.getBlockDefaultClassName

Generated HTML classes for blocks follow the wp-block-{name} nomenclature. This filter allows to provide an alternative class name.


// Our filter function
function setBlockCustomClassName( className, blockName ) {
    return blockName === 'core/code' ?
        'my-plugin-code' :

// Adding the filter

Top ↑

blocks.getSaveElement blocks.getSaveElement

A filter that applies to the result of a block’s save function. This filter is used to replace or extend the element, for example using wp.element.cloneElement to modify the element’s props or replace its children, or returning an entirely new element.

Top ↑

blocks.getSaveContent.extraProps blocks.getSaveContent.extraProps

A filter that applies to all blocks returning a WP Element in the save function. This filter is used to add extra props to the root element of the save function. For example: to add a className, an id, or any valid prop for this element. It receives the current props of the save element, the block type and the block attributes as arguments.


Adding a background by default to all blocks.

function addBackgroundColorStyle( props ) {
    return Object.assign( props, { style: { backgroundColor: 'red' } } );


Note: This filter must always be run on every page load, and not in your browser’s developer tools console. Otherwise, a block validation error will occur the next time the post is edited. This is due to the fact that block validation occurs by verifying that the saved output matches what is stored in the post’s content during editor initialization. So, if this filter does not exist when the editor loads, the block will be marked as invalid.

Top ↑

Extending the Editor UI Extending the Editor UI

Extending the editor UI can be accomplished with the registerPlugin API, allowing you to define all your plugin’s UI elements in one place.

Refer to the plugins module documentation for more information.