Open carstingaxion opened 1 month ago
Your understanding of this is correct— that list uses block.json (or register_block_type
) to parse out blocks. There's some history here: https://meta.trac.wordpress.org/ticket/5207. I would recommend opening a new meta ticket to start a discussion about adding block variation detection.
Thank you for taking the time @ryelle .
Yes, the meta trac ticket brought some clarification to me, that it'll be not easily possible to trick the current parser with a faked block.json
placed in the .wordpress-org
folder (for example). One of the earliest ideas I had.
Opening a new meta ticket is probably the best way to go.
Opened a meta.trac ticket for that – my first ever : https://meta.trac.wordpress.org/ticket/7782
Describe your question
Currently the plugins repository on wordpress.org shows a list of all blocks a plugin contains.
But this, unfortunately only happens for real, custom blocks, that ship with a
block.json
file. A block-variation in general, and like so also GatherPress’ 10+ new block variations, don’t have a block.json and will not have that nice visual overview as Mika and Jeremy pointed out on this fediverse thread.Not only, that this seems to be an unforeseen obstacle in GatherPress block transformation; this is not nice for every plugin author who is looking for best compatibility across different stacks.
In my opinion, block-variations (#626) do have so many advantages over custom blocks, that I believe they should get more attention!
Who is able to help? Who do we need to ask for at the WordPress meta team? Who knows the roadmap for the plugin pages on .org?
Code of Conduct