When registering custom blocks using register_block_type() function, providing a different 'name' as part of the $arg result the block not available in the block editor.

Description

I've created a custom block and successfully registered it using a block.json file. Now I'm experimenting to see if I can override the name defined in block.json by specifying it in the $args parameter when calling register_block_type() in PHP. Based on my review of the core code, this approach appears valid.

However, while the block registers correctly on the PHP side, it doesn't show up in JavaScript when I try to retrieve it using wp.blocks.getBlockTypes(). This has left me a bit confused — is this functionality partially supported, or am I missing something in my implementation?

Step-by-step reproduction instructions

Create a basic Gutenberg block using a block.json file.
Register the block with:
register_block_type( __DIR__ . '/path-to-block', array( 'name' => 'custom/renamed-block' ) );
In the browser console (within the Gutenberg editor), run:
wp.blocks.getBlockType('custom/renamed-block')
Notice that the block is not found, even though it's registered on the PHP side.

Screenshots, screen recording, code snippet

No response

Environment info

No response

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

Yes

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

Yes

Please confirm which theme type you used for testing.

Block
Classic
Hybrid (e.g. classic with theme.json)
Not sure

Behind the scenes, WordPress uses block.json both to register blocks in PHP and enqueue their assets for the editor. The JavaScript part expects block names to match exactly, and uses this to retrieve the block definitions via wp.blocks.

If the name doesn’t match:

The block is technically "there" on the server,
But JS won’t see or load it, because it's looking for a different key.

Hi Mayank,

Thanks for the information. In this case, the ability to override the name of the block as part of the $args doesn't make much sense anymore if JavaScript side of things can't pass validation.

Hi Mayank,

Thanks for the information. In this case, the ability to override the name of the block as part of the $args doesn't make much sense anymore if JavaScript side of things can't pass validation.

I agree, maybe others can shed some light on it.

@kelvin-xu

@kelvin-xu Have you tried blocks.registerBlockType "JS" filter?

https://developer.wordpress.org/block-editor/reference-guides/filters/block-filters/#blocks-registerblocktype

@t-hamano

Hi @t-hamano ,

Thanks — yes, that’s exactly how I got it working in the end. The block editor (blockStore) only seems to recognize namespaces defined within the block.json file. For blocks registered via PHP(even with the block.json file) where the namespace is overridden, the blockStore doesn’t appear to be aware of their existence.

What I ended up doing was hooking separately into blocks.registerBlockType. I added a conditional so that when the original block is registered, the new block gets registered at the same time. I also made sure the new block’s edit function and icon were inherited from the original block, as those settings seem to be missing otherwise. Example below:

const register_cloned_blocks = ( blockType, name ) => {
      if( name !== originalBlockName ) {
               return blockType;
      }

      wp.blocks.registerBlockType( newBlockName, {
                  icon: blockType.icon,
                  edit: blockType.edit,
      } );
}

wp.hooks.addFilter(
    'blocks.registerBlockType',
    'block_duplicator\register_block',
    register_cloned_blocks
);

It then works like a charm.

Best,
Kelvin

This is probably a ticket for https://core.trac.wordpress.org/newticket. This repository doesn't maintain copies of the register_block_type and register_block_type_from_metadata functions.

For blocks registered via PHP(even with the block.json file) where the namespace is overridden, the blockStore doesn’t appear to be aware of their existence.

This might be the expected behavior.

From my understanding, in addition to server-side registration, client-side block registration is required. On the client side, the block.json file is imported as metadata, so PHP hooks are not applicable.

Is there anything we can do about this issue?

Hi Aki,

My understanding is that if override the block namespace is allowed from the PHP side when registering a new block using block.json file. Then the new block should be available in the block editor.

What happens right now could be either that this feature is not fully implemented yet, or it was a mistake to make the namespace changeable.

But either way, I think there are values in this feature, as if you have multiple blocks that share a lot of the same code base, then the maintenance is going to be largely reduced.

Just add to this thread, looks like the save function is also not inherited. Updated code below.

const register_cloned_blocks = ( blockType, name ) => {
      if( name !== originalBlockName ) {
               return blockType;
      }

      wp.blocks.registerBlockType( newBlockName, {
                  icon: blockType.icon,
                  edit: blockType.edit,
                  save: blockType.save
      } );
}

wp.hooks.addFilter(
    'blocks.registerBlockType',
    'block_duplicator\register_block',
    register_cloned_blocks
);

@Mamaduka

As @Mamaduka mentioned, this behavior is in the Core repo and discussing changes there would be a better fit for a Core Trac ticket.

I'll proceed to close this one.

Navigation Menu

Repository navigation

When registering custom blocks using register_block_type() function, providing a different 'name' as part of the $arg result the block not available in the block editor. #70104

Description

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

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

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

Please confirm which theme type you used for testing.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

When registering custom blocks using register_block_type() function, providing a different 'name' as part of the $arg result the block not available in the block editor. #70104

Description

Description

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

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

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

Please confirm which theme type you used for testing.

Activity

Mayank-Tripathi32 commented on May 12, 2025

kelvin-xu commented on May 12, 2025

Mayank-Tripathi32 commented on May 12, 2025

t-hamano commented on May 13, 2025

kelvin-xu commented on May 13, 2025

Mamaduka commented on May 14, 2025

t-hamano commented on May 20, 2025

kelvin-xu commented on May 20, 2025

kelvin-xu commented on May 20, 2025

tyxla commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions