Making WordPress.org

Opened 10 months ago

Last modified 5 months ago

#5971 new defect (bug)

Plugin Directory: Custom Block Names not being listed right

Reported by: ipstenu's profile 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 (18)

#1 follow-up: @ryelle
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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.


10 months ago

#10 @hztyfoon
9 months 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
9 months 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
9 months 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.

#13 @hztyfoon
7 months ago

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

#14 @Dudo
5 months ago

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.

Last edited 5 months ago by Dudo (previous) (diff)

#15 @ryelle
5 months ago

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.

#16 @Dudo
5 months ago

Thank you for the answer @ryelle .

And just to 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
Last edited 5 months ago by Dudo (previous) (diff)

#17 @ryelle
5 months ago

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

#18 @Dudo
5 months ago

Thanks!

Note: See TracTickets for help on using tickets.