-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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: 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 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
|
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 overview issue collects an actionable list of impactful tasks that capture possible enhancements to the various Block APIs that exist to power the WordPress block editor.
Block API is intentionally a vague term reflected in the list of action items grouped into categories like block registration, block attributes, block interactions, block modification, etc. What’s in common is that the tasks included aim to resolve the most common friction points or increase the potential of the APIs offered for WordPress block, plugin, and theme authors. In effect, it makes it possible to fulfill the needs of developers wanting to adopt the block editor in their projects.
🛠️ = in development
🤚 = needs to be unblocked
❗Top Things
High-impact projects in active development:
📖 Backlog
Planned tasks that are being actively researched, waiting for developers to pick them up or on hold until they get unblocked.
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.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: