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 #41236
Comments
This can be a good first step, but acknowledging that we need more than that in the near future: probably Apart from that, I think we should explore a mechanism to export different code depending on the context (Edit, Save, or Frontend): WordPress/block-interactivity-experiments#11 |
Thank you @luisherranz for your feedback. I included your suggestions together with references. I also added two more items that I missed initially but have been following closely for a long time:
|
@gziolo I have reviewed the items that are already tracked here and I myself have created 3 issues recently that I think could all be added: |
Follow-up #54337, [52069]. Part of WordPress/gutenberg#41236. More details in WordPress/gutenberg#33542. Allow passing more than one script per block for `editorScript`, `script`, and `viewScript` fields in the `block.json` metadata file. This aligns with the previously added changes for `style` and `editorStyle` fields. This change impacts the `WP_Block_Type` class and the REST API endpoint for block types. To ensure backward compatibiliy old names were soft deprecated in favor of new fields that work with array values and have `_handles` suffix. Props zieladam, dlh, timothyblynjacobs, aristath, bernhard-reiter. Fixes #56408. git-svn-id: https://develop.svn.wordpress.org/trunk@54155 602fd350-edb4-49c9-b593-d223f7449a82
Follow-up #54337, [52069]. Part of WordPress/gutenberg#41236. More details in WordPress/gutenberg#33542. Allow passing more than one script per block for `editorScript`, `script`, and `viewScript` fields in the `block.json` metadata file. This aligns with the previously added changes for `style` and `editorStyle` fields. This change impacts the `WP_Block_Type` class and the REST API endpoint for block types. To ensure backward compatibiliy old names were soft deprecated in favor of new fields that work with array values and have `_handles` suffix. Props zieladam, dlh, timothyblynjacobs, aristath, bernhard-reiter. Fixes #56408. Built from https://develop.svn.wordpress.org/trunk@54155 git-svn-id: http://core.svn.wordpress.org/trunk@53714 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Follow-up #54337, [52069]. Part of WordPress/gutenberg#41236. More details in WordPress/gutenberg#33542. Allow passing more than one script per block for `editorScript`, `script`, and `viewScript` fields in the `block.json` metadata file. This aligns with the previously added changes for `style` and `editorStyle` fields. This change impacts the `WP_Block_Type` class and the REST API endpoint for block types. To ensure backward compatibiliy old names were soft deprecated in favor of new fields that work with array values and have `_handles` suffix. Props zieladam, dlh, timothyblynjacobs, aristath, bernhard-reiter. Fixes #56408. Built from https://develop.svn.wordpress.org/trunk@54155 git-svn-id: https://core.svn.wordpress.org/trunk@53714 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Follow-up #54337, [52069]. Part of WordPress/gutenberg#41236. More details in WordPress/gutenberg#33542. Allow passing more than one script per block for `editorScript`, `script`, and `viewScript` fields in the `block.json` metadata file. This aligns with the previously added changes for `style` and `editorStyle` fields. This change impacts the `WP_Block_Type` class and the REST API endpoint for block types. To ensure backward compatibiliy old names were soft deprecated in favor of new fields that work with array values and have `_handles` suffix. Props zieladam, dlh, timothyblynjacobs, aristath, bernhard-reiter. Fixes #56408. Built from https://develop.svn.wordpress.org/trunk@54155
Follow-up #54337, [52069]. Part of WordPress/gutenberg#41236. More details in WordPress/gutenberg#33542. Allow passing more than one script per block for `editorScript`, `script`, and `viewScript` fields in the `block.json` metadata file. This aligns with the previously added changes for `style` and `editorStyle` fields. This change impacts the `WP_Block_Type` class and the REST API endpoint for block types. To ensure backward compatibiliy old names were soft deprecated in favor of new fields that work with array values and have `_handles` suffix. Props zieladam, dlh, timothyblynjacobs, aristath, bernhard-reiter. Fixes #56408. git-svn-id: https://develop.svn.wordpress.org/trunk@54155 602fd350-edb4-49c9-b593-d223f7449a82
โ๏ธ Completed in WordPress 6.1 cycleBlock Registration
Block AssetsSome of the details were tracked in #33542.
Documentation
|
Regarding
Since we already have |
@gaambo, thank you for feedback.
Can you share the link to the issue? I would like to learn why it was closed and potentially reopen. There is still an item listed in the Backlog that signals that we have this API on the roadmap but it doesn't link to the issue you referred to: "Introduce |
@gziolo |
It was me who closed the issue with the note I moved the item to this issue - the one I quoted in #41236 (comment) ๐ If you could open a new issue that would be great, thank you! I'm happy to see this feature implemented if it's going to be useful for custom blocks. |
UpdateCompleted during WP 6.4Added
Needs review
|
This issue tracks mini-projects around improvements to the Block API.
๐ ๏ธ = in development
๐ค = needs to be unblocked
โTop Things
๐ Backlog
Block Registration
useBlockProps
,InnerBlocks
) that run different code depending on the context: edit, save, or frontend (Blocks: Add block environment and directives support (edit
vssave
)ย #48590).<a />
.block.json
files. At the moment developers have to register every block separately. It could help to updateregister_block_type
or add newregister_block_types
on the server to support auto-discovery of multiple blocks throughblock.json
in a given target folder.block.json
for translations used with JavaScript (Trac #54797).ancestor
andparent
to support allow/deny lists based on the editor, post-type, and template type context (Block registration: offer option to register a block only in a specific editorย #46900, Allow/deny block use based on post-type or template contextย #41062, related discussion starts also in Post Comments Loop: Unable to put comment blocks inside rows or columnsย #37181 (comment)).WP_Block_Type
properties (Validate each arg before setting WP_Block_Type propertiesย #48039).reusable
tofalse
when a block has aparent
definedย #35223Block Assets
Block assets are JavaScript (
editorScript
,script
,viewScript
) and CSS (editorStyle
,style
) defined inblock.json
file.viewStyle
for styles used only on the front end to align with scripts andviewScript
(block.json: Add viewStyle for frontend-only block stylesย #54491, https://core.trac.wordpress.org/ticket/59673).block.json
as explained in Trac #54018 and to fix Blocks without asset.php file cannot be registeredย #40447. Tracked in Blocks: Allow customizations for assets inblock.json
ย #46954.script
/viewScript
to an already registered blockย #48382).__experimentalStyle
inblock.json
) as part of the global styles mechanism (Iterate on absorbing block styles as part of the global styles mechanismย #45198).Block Attributes
content
added in Suggest block pattern transformations that are contextual to the currently selected 'simple' blocks (no InnerBlocks)ย #30469.Block Variations
woocommerce/product-list
that can get resolved to theproduct-list
variation added to thecore/query
block.ancestor
andparent
settings for the block variation (Blocks: Add support for theancestor
andparent
settings for the block variationย #48424).wp.blocks.registerBlockVariation
(Block Variations: Add PHP version ofwp.blocks.registerBlockVariation
ย #47170).Block Interactions
parent
,ancestor
, andsupports.multiple
when using drag & drop, or copy & paste (Restrict copy/paste of a block in the editor whensupports.multiple = false
andsupports.removal = false
ย #53471).Block Modification
get_posts
$filter parameter to allow a blocks as a return shape (Trac#53602)Documentation
parent
when empty during block registration (Documentation: Clarify the behavior of parent when empty during block registrationย #15731).spacing.blockGap
explanation is inadequate for custom blocks (Documentation:spacing.blockGap
explanation is inadequate for custom blocksย #43921).register_block_type_args
as a way to filter registration of a block in the documentationย #54112The text was updated successfully, but these errors were encountered: