-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block API: Extend the block registration API technical proposal #16209
Comments
Should this issue be closed, Greg @gziolo ? |
No, there are open tasks. |
@ryelle, I was thinking about this proposal again and it might be a great fit for extending what Block Directory can support. If we would ensure that the file you reference outputs the HTML for the block on the frontend and it can only use the same attributes that |
I consider all items from to-do list as done. Let's close this issue and continue working on individual enhancements separately:
|
Nice work driving these @gziolo |
Continues the work toward server-side awareness of block types: #2751 and follow-up for #13693.
Development Roadmap
This highly related to core blocks and the way they integrate with WordPress.
icon
andedit
fields (Block library: Standardize file structure of core blocks #14743)name
,category
andattributes
inblock.json
(Block library: Introduce block.json metadata for all client side blocks #14770, Refactor File block to use block.json metadata #14862, Refactor Tabel block to use block.json metadata #14863)transforms
andsave
fields to their own files (Refactor File block to use block.json metadata #14862, Refactor Tabel block to use block.json metadata #14863, Refactor core blocks to have save and transforms in their own files (part 1) #14882, Refactor core blocks to have save and transforms in their own files (part 2) #14899, Refactor core blocks to have save and transforms in their own files (part 3) #14902, Refactor core blocks to have save and transforms in their own files (part 4) #14903)merge
ordeprecated
to their own files (Refactor core blocks to have deprecated extracted to their own files (p.1) #14979, Block library: Extractdeprecated
field to their own files #15057, Block library: Extractdeprecated
field to their own files (p.2) #15071)block.json
(reuse code from Introduce block metadata files for dynamic blocks #14238)block.json
to make them work with both PHP and JavaScript (Block API: Extendregister_block_type_from_metadata
to handle assets #22519)registerBlockType
andregister_block_type_from_metadata
to autowrap translatable fields fromblock.json
with_x
(Block API: Add i18n support toblock.json
metadata file #23636, Blocks: Introduce registerBlockTypeFromMetadata API #30293)title
,description
,keywords
,styles.label
) toblock.json
(Block Library: Move translatable fields toblock.json
files for core blocks #23792)block.json
and block variations (Block Library: Refactor Embed block to useblock.json
and block variations #22660)block.json
files and annotate translatable fields (https://core.trac.wordpress.org/ticket/50615, Blocks: Introduce registerBlockTypeFromMetadata API #30293)Proposals
There are some items that weren't included in the initial proposal which should be processed and included based on the further discussion. Many of the items discussed are very WordPress specific and therefore we need to find a good way to make it explicit what is truly platform agnostic and what is meant to be work only when using it with WordPress.
New screenshot property
From @perandre in #13693 (comment)
This seems like a good addition in the context of the block discovery when it isn't installed.
Auto-discover of
block.json
metadata fileThe original discussion sparked by a comment from @moorscode in #13693 (comment).
This is WordPress specific and that's why it wasn't included in the first version. We definitely want to have it implemented but this might be added after some code exploration which will make it easier to solidify.
Client-side properties referenced as files
This was removed from the initial proposal (see this commit: 5ec9cd9) as noted in #13693 (comment):
I think we should continue exploring this idea as this could give us some ways to optimize the size of assets loaded by deferring the moment when those files are loaded on the page. In particular
deprecated
andedit
fields loaded only when they are actually used could bring some performance optimizations in case of blocks heavy loaded with JavaScript logic.Extend flexibility of
parent
propertyAlso filed in #30679 by @priethor.
See comment from @aduth in #13693 (comment):
Consider adding
renderTemplate
propertySee comment from @spacedmonkey in #13693 (comment):
There is also another thread started by @spacedmonkey in #13693 (comment) which expands on this topic.
The text was updated successfully, but these errors were encountered: