register_block_type( string|WP_Block_Type $block_type, array $args = array() ): WP_Block_Type|false
Registers a block type. The recommended way is to register a block type using the metadata stored in the block.json file.
Parameters
-
$block_typestring|WP_Block_Type Required -
Block type name including namespace, or alternatively a path to the JSON file with metadata definition for the block, or a path to the folder where the
block.jsonfile is located, or a complete WP_Block_Type instance.
In case a WP_Block_Type is provided, the $args parameter will be ignored. -
$argsarray Optional -
Array of block type arguments. Accepts any public property of
WP_Block_Type. See WP_Block_Type::__construct() for information on accepted arguments.More Arguments from WP_Block_Type::__construct( ... $args )
Array or string of arguments for registering a block type. Any arguments may be defined, however the ones described below are supported by default.
api_versionstringBlock API version.titlestringHuman-readable block type label.categorystring|nullBlock type category classification, used in search interfaces to arrange block types by category.parentstring[]|nullSetting parent lets a block require that it is only available when nested within the specified blocks.ancestorstring[]|nullSetting ancestor makes a block available only inside the specified block types at any position of the ancestor's block subtree.iconstring|nullBlock type icon.descriptionstringA detailed block type description.keywordsstring[]Additional keywords to produce block type as result in search interfaces.textdomainstring|nullThe translation textdomain.stylesarray[]Alternative block styles.variationsarray[]Block variations.selectorsarrayCustom CSS selectors for theme.json style generation.supportsarray|nullSupported features.examplearray|nullStructured data for the block preview.render_callbackcallable|nullBlock type render callback.attributesarray|nullBlock type attributes property schemas.uses_contextstring[]Context values inherited by blocks of this type.provides_contextstring[]|nullContext provided by blocks of this type.block_hooksarray[]Block hooks.editor_script_handlesstring[]Block type editor only script handles.script_handlesstring[]Block type front end and editor script handles.view_script_handlesstring[]Block type front end only script handles.editor_style_handlesstring[]Block type editor only style handles.style_handlesstring[]Block type front end and editor style handles.
Default:
array()
Return
WP_Block_Type|false The registered block type on success, or false on failure.
Source
File: wp-includes/blocks.php.
View all references
function register_block_type( $block_type, $args = array() ) {
if ( is_string( $block_type ) && file_exists( $block_type ) ) {
return register_block_type_from_metadata( $block_type, $args );
}
return WP_Block_Type_Registry::get_instance()->register( $block_type, $args );
}
Changelog
| Version | Description |
|---|---|
| 5.8.0 | First parameter now accepts a path to the block.json file. |
| 5.0.0 | Introduced. |
User Contributed Notes
You must log in before being able to contribute a note or feedback.
You can load
block.jsondirectly:How to write a plugin with multiple blocks:
Setting up the
srcfoldersrcdirectory created by @wordpress/create-block and place it in a sub-directory, for exampleblock-a.block-b.Update the
block.jsonfiles in each sub-directory to match the blocks’ requirements.Registering the Blocks
After running
npm run buildcorresponding directories will be created in thebuilddirectory.The two blocks can be registered by pointing to the matching directory in the build folder.
You can pass custom
$attributeswhich can be used both on editor and front-end inrender_callback:Important (tested in 5.0.3) : in case of array attributes you MUST specify items type. Otherwise it would trigger a notice.
The name of the JSON file, if provided in the
$block_typeargument, must be “block.json”. If the file does not end with such file name, WordPress will assume it is a path to that file. It seems to be up to the developer choose the file name, but it’s not.Top ↑
Feedback
I hit this problem earlier. I made a block called accordion.json. I had to rename it to accordion-block.json for it to be registered. — By Rocky Kev —
Here is an example snippet that I use for one of my own projects
If you wish to set a dashicon in the args, you must omit the
dashicons-prefix:This is in contradiction to
add_menu_page()which requires the inclusion of the prefix. These should be brought into alignment for consistency in my opinion.The arguments to
register_block_type()function match the instance vars ofWP_Block_Typeclass, i.e.,attributes, render_callback, editor_script, editor_style, scriptandstyle.This is because the
register_block_type()function utilizes the name and arguments provided in the function call to create a new instance ofWP_Block_Typeclass and the instance thus created is registered with the globalWP_Block_Type_Registryinstance.If you don’t know why it’s recommended to register a block type using metadata, read this reference https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/
To follow on from Michael Levy’s post about registering multiple blocks from the same plugin, I wrote this to automatically register any blocks generated by the
npm run buildcommand.