WordPress.org

Making WordPress.org

Opened 7 weeks ago

Last modified 13 days ago

#5971 new defect

Plugin Directory: Custom Block Names not being listed right

Reported by: Ipstenu Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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:

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?

Change History (12)

#1 follow-up: @ryelle
7 weeks ago

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"?

#2 in reply to: ↑ 1 @dd32
7 weeks ago

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=()

#3 @GDragoN
7 weeks ago

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?

#4 @Dudo
7 weeks ago

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.

#5 @ryelle
7 weeks ago

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.

#6 follow-up: @Dudo
7 weeks ago

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

#7 in reply to: ↑ 6 @dd32
7 weeks ago

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.

#8 @Dudo
7 weeks ago

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.

This ticket was mentioned in Slack in #meta by dd32. View the logs.


5 weeks ago

#10 @hztyfoon
4 weeks ago

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?

#11 @ryelle
13 days ago

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.

#12 @ryelle
13 days ago

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.

Note: See TracTickets for help on using tickets.