Plugin Directory: Custom Block Names not being listed right

[Ipstenu]

This was reported by a plugin owner.

In some cases, the plugin front-end page fails to show proper names of included blocks and instead just duplicates the plugin name.

Examples:

• ​https://wordpress.org/plugins/social-polls-by-opinionstage/
• ​https://wordpress.org/plugins/archivespress/
• ​https://wordpress.org/plugins/oer-curriculum/

In these cases, developers are not using blocks.json (for a number of valid reasons).

Should there be a better fallback check here? Or should we just not list the blocks by name if we cannot find the name?

[ryelle]

The block.json is the easiest way to get this info (since it's already in a format we can parse and get the value from directly). The next best way to get block titles is from the JS registerBlockType call (which is working for OER Curriculum's "Curriculum Thumbnail Block" block), but this is done with a regex, so it expects very specific formatting - the title must be the first value in the config object, with no comments/etc before it.

The script also checks PHP files for register_block_type, but it doesn't even try to find a title.

(code source for finding blocks.)

Aside from improving that JS regex, what would be a better fallback? Maybe human-ify the block name, so it would go from ryelle/recipe to "Ryelle Recipe", opinion-stage/block-os-poll to "Opinion Stage Block Os Poll"?

[dd32]

Replying to ryelle:

The script also checks PHP files for register_block_type, but it doesn't even try to find a title.

At the time of it being written, I'm almost certain that it didn't support the title arg, I recall that being a fairly annoying part of listing blocks as it was a situation of "Well, we know the block slug, but can't tell you what you'll see it as inside the editor".

It's an even worse situation now though, as it accepts a WP_Block_Type object too, which we also can't parse out of it easily without running the plugin.. Unless we can do something like a regex similar to WP_Block_Type\(.+slug=().+title=()

[GDragoN]

My plugin ArchivesPress doesn't use block.json file because I need ServerSideRender and that can't be setup via block.json. What would happen if I just include block.json file for each block my plugin has, just include it, without loading it and using it anywhere in the code? Will the WordPress.org parse it, and will it throw some red flags because it is not used or something?

[Dudo]

Same ​here I'm not using (yet) block.json, and also I've two deprecated blocks that instead are using registerBlockType in JS and those two are working fine.

[ryelle]

What would happen if I just include block.json file for each block my plugin has, just include it, without loading it and using it anywhere in the code?

That would work - if you don't ​load it in your plugin, it won't be read by WordPress. The Plugin Directory will read it to parse out the blocks, providing the title. In fact, if you wanted to just use block.json for the plugin directory, you only need to add the name and title fields.

I'm not using (yet) block.json, and also I've two deprecated blocks that instead are using registerBlockType in JS and those two are working fine.

Yeah, the two deprecated blocks are registered with their titles in registerBlockType, but the rest of your blocks only define edit and save in the JS. If you added the title here too, it should pick it up– or use block.json.

[Dudo]

Yeah, the two deprecated blocks are registered with their titles in registerBlockType, but the rest of your blocks only define edit and save in the JS. If you added the title here too, it should pick it up– or use block.json.

Thanks for answer, I did already tried this, but it didn't work.
You can see the commit ​here

[dd32]

Replying to Dudo:

Yeah, the two deprecated blocks are registered with their titles in registerBlockType, but the rest of your blocks only define edit and save in the JS. If you added the title here too, it should pick it up– or use block.json.

Thanks for answer, I did already tried this, but it didn't work.
You can see the commit ​here

It doesn't look like that's in your released version of the plugin, so it won't be being parsed at present.

[Dudo]

It doesn't look like that's in your released version of the plugin, so it won't be being parsed at present.

Since it didn't work, I've ​removed it 2 weeks later.

I can insert it again, if you wish.

[hztyfoon]

I've got this issue too. Plugin link : ​https://wordpress.org/plugins/essential-blocks
It used to show like ​https://prnt.sc/22rwmxp
But after I've included block.json for all the blocks in the last release and now the lists totally disappeared.

Can anyone tell me what I'm doing wrong here or how can I make it so that all the blocks will show in that list correctly?

[ryelle]

In 11410:

Plugin Directory: Update block.json validation and discovery in block plugins.

Start using https://schemas.wp.org/trunk/block.json to validate the block.json. This fixes a few mismatched field types between our validator and the official expected format. This also updates the block discovery code to merge found blocks (if a block is registered in both PHP and JS, for example).

Props gziolo, welcher, jeffpaul.
See #5303, #5971.

[ryelle]

I updated some of the validation and parsing in [11410], and I can answer some questions better now :)

The block.json file needs to be valid to import block data. If you have block.json files, the code only looks at those, and they need to pass validation/have the required fields - including either script or editorScript.

For example, using @hztyfoon's Essential Blocks, ​there are some validation errors, but they're all "At least one of the following properties must be present: script, editorScript". So if you add "editorScript": "accordion-block-editor" to blocks/accordion/block.json (and so on) it should start parsing correctly.

[hztyfoon]

Thanks a lot @ryelle 💚💚.
All the Blocks showing nicely in the plugin page: ​http://wordpress.org/plugins/essential-blocks/ after adding the "$schema & editorScript" in all the blocks' block.json file on version 3.2.4

[Dudo]

I'm not sure to understand.

I'm loading blocks with .block.json now, with ​register_block_type_from_metadata.

This is ​an example of *.block.json file that I use, with title attribute on top.

Now, these new blocks doesn't ​appear at all .

Should I use register_block_type instead of register_block_type_from_metadata ?
Or maybe the custom name od the block.json file is the problem?

Thank you

UPDATED: I've also added register_block type ( ​https://plugins.trac.wordpress.org/changeset/2719338 ) but still no luck.

[ryelle]

This is an example of *.block.json file that I use, with title attribute on top

The expectation is that the file is just called block.json, so it looks for all files with that exact name in your plugin. It wouldn't find something called my-block.json.

[Dudo]

Thank you for the answer @ryelle .

And just sto be sure, can I place the dir containig where I want?

E.g, I guess this will work

/blocks/block-name/block.json

but will this also work?

/includes/blocks/block-name/block.json

[ryelle]

@Dudo Yeah, you can put the file in any directory, the Block Directory code will scan the whole plugin for anything named block.json.

[Dudo]

Thanks!

[dd32]

It's an even worse situation now though, as it accepts a WP_Block_Type object too

See [13713]: Plugin Directory: Blocks: Import blocks registered with new WP_Block_Type().

[dd32]

​https://wordpress.org/plugins/social-polls-by-opinionstage/

This plugins blocks seem to be importing correctly now. The title is clearly extractable from code.

​https://wordpress.org/plugins/archivespress/
​https://wordpress.org/plugins/oer-curriculum/

These plugins switched to using block.json, which takes precedence over code extraction.

Aside from improving that JS regex, what would be a better fallback? Maybe human-ify the block name, so it would go from ryelle/recipe to "Ryelle Recipe", opinion-stage/block-os-poll to "Opinion Stage Block Os Poll"?

I think this is worthwhile doing.

[dd32]

In 13718:

Plugin Directory: Blocks: When we can't extract a block name, instead of using the plugin name, use the block name in "human readable form".

For example 'plugin-slug/my-block' becomes 'My Block', and 'example/example-block-name' becomes 'Block Name'.

Fixes #5971.

[dd32]

In 13722:

Plugin Directory: Blocks: Tweak the fallback name slightly, to skip the plugin slug if it's the namespace..

See [13718].
See #5971.