Making WordPress.org

Opened 5 months ago

Last modified 5 months ago

#7782 new enhancement

Add block-variation detection

Reported by: carstenbach's profile carstenbach Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

Hello Meta-Team,

Currently the plugins repository on wordpress.org shows a list of all blocks a plugin contains, which is cool & nice, but could be improved.

Unfortunately, but validated by ticket:5207 and a comment by @ryelle, this only happens for real, custom blocks, that ship with a block.json file. A block-variation in general don’t have a block.json and will not get that nice visual overview.

For the last 6 months I've contributed a lot of time to help the GatherPress project to stay up-to-date with core and esp. block development. We have and already are creating around 10+ new block-variations to better align with WordPress core, than the current and existing custom blocks.

https://github.com/user-attachments/assets/f5e154a4-a8c1-4138-a78c-dae208672447

When we will have finished our attempts to getting closer to core, this list will be shrinked down to one or two pieces, what feels to be not nice.

Not only for the GatherPress plugin, but for all plugin authors, who try to align with the fast core development and all its new (block) editor features, it would be fantastic to support such ontributions by highlighting block-variations as equaly important as custom blocks.

My personal opinion goes even beyond that, because I believe block-variations are much more powerful, than custom blocks could ever be, but that's another story.

Please, explore if and how the detection for blocks could be expanded to block-variations as well!

Carsten

Change History (6)

#1 follow-up: @dd32
5 months ago

Please, explore if and how the detection for blocks could be expanded to block-variations as well!

Can you provide any suggestions on how this should be done?

#2 follow-up: @dufresnesteven
5 months ago

I don't know if there's a logical server side way of doing this for variations on core blocks.

Variations for your custom block, we could easily parse them:
https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#variations otherwise ...

I think if we can get users into the plugin more easily to preview using something like playground we can expose these blocks/variations directly in the editor. The readme can list the blocks in simple terms, and the interactive experience could highlight the blocks and their functionality...?

#3 in reply to: ↑ 1 @carstenbach
5 months ago

Replying to dd32:

Please, explore if and how the detection for blocks could be expanded to block-variations as well!

Can you provide any suggestions on how this should be done?

Not realy, but let me try.

I thought, that when the current detection is based on either a block.json exists or register_block_type() is called, shouldn't it be possible to look for calls to registerBlockVariation() from inside the plugins /build folder.

I guess @dufresnesteven meant something similar with

I don't know if there's a logical server side way of doing this for variations on core blocks.

Variations for your custom block, we could easily parse them:

I have no clue how the current detection works in detail, but I hope, we could find a way to better reflect all (kinds of) blocks.

#4 in reply to: ↑ 2 ; follow-up: @carstenbach
5 months ago

Replying to dufresnesteven:

I don't know if there's a logical server side way of doing this for variations on core blocks.

Variations for your custom block, we could easily parse them:
https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#variations otherwise ...

I think and hope we're on the same track here as mentioned in my previous comment.

Please help me understand, why you differentiate between variations of core blocks and variations of custom blocks? Does this make any difference to the user, to the parsing or to the preview? Sorry, I don't understand that.

I think if we can get users into the plugin more easily to preview using something like playground we can expose these blocks/variations directly in the editor. The readme can list the blocks in simple terms, and the interactive experience could highlight the blocks and their functionality...?

I like Playground and do & experiment a lot using it, so yes this might be a path to go.

Given that this would need a lot more clicks and loading bars to get to the "final" block-variations; this idea should – from my opinion – considered last, if nothing else worked.

#5 in reply to: ↑ 4 @carstenbach
5 months ago

Replying to dufresnesteven & myself:

Please help me understand, why you differentiate between variations of core blocks and variations of custom blocks? Does this make any difference to the user, to the parsing or to the preview? Sorry, I don't understand that.

I think if we can get users into the plugin more easily to preview using something like playground we can expose these blocks/variations directly in the editor. The readme can list the blocks in simple terms, and the interactive experience could highlight the blocks and their functionality...?

I like Playground and do & experiment a lot using it, so yes this might be a path to go.

Given that this would need a lot more clicks and loading bars to get to the "final" block-variations; this idea should – from my opinion – considered last, if nothing else worked.

I think I may have got it, this relates to JS & PHP.

While we can get title and description of a block reliably, when parsing from register_block_type(), or even in JS from "variations": [...], but we would need to run the code, to get the same data from registerBlockVariation() because the arguments are not directly nested anymore, due to the build process.

Am I right or at least in the right direction?

If that is the case, I understand now too, why running a Playground to get that data might be a very good idea!

#6 @dufresnesteven
5 months ago

Please help me understand, why you differentiate between variations of core blocks and variations of custom blocks? Does this make any difference to the user, to the parsing or to the preview? Sorry, I don't understand that.

With custom blocks, you typically provide a block.json file. You can include variations in your block.json file. So if you have a "Sports" block, with a "Hockey" and a "Basketball" variation we could easily parse those out. However, for core blocks, you don't provide the block.json file, Gutenberg does, so you are forced to register variations in code. Now, looking up our code, I thought we abandoned static .php and .js/jsx file parsing and relied solely on block.json files, but it appears like I am wrong although we do prefer it.

Note: See TracTickets for help on using tickets.