Registration: Add server script, style block type property#4039
Registration: Add server script, style block type property#4039
Conversation
docs/blocks-stylesheet.md
Outdated
| 'gutenberg-boilerplate-es5-step02', | ||
| function gutenberg_boilerplate_block() { | ||
| wp_register_script( | ||
| 'gutenberg-boilerplate-es5-step02-editor-script', |
There was a problem hiding this comment.
A seemingly basic question I wasn't sure of: Are handles required to be unique only between script and style registrations, or for both? i.e. Is it valid to:
wp_register_script( 'foo', /* ... */ );
wp_register_style( 'foo', /* ... */ );If above is valid, can probably drop the suffix here to remove redundancy.
There was a problem hiding this comment.
They are free to be the same. I do it all the time, and core does it as well. For example, customize-controls:
There was a problem hiding this comment.
They are free to be the same.
Thanks! Updated in 5972c9b.
|
We will have to update WP-CLI to promote those changes. Please ping me when it is ready to merge so I could open a follow-up PR. |
|
@gziolo I expect this is ready to merge as-is. Do you have any work you'd like to have prepared before I do so? |
|
It looks like non-breaking change so you can merge anytime. I will update WP-CLI next week to use this simplified API 👍 |
|
@aduth I created wp-cli/scaffold-command#111 for |
Closes #2756
Related: #2751
This pull request seeks to implement and document an alternative approach to enqueueing block assets, integrating new settings into the
register_block_typeserver-side API to help manage context-specific script and style enqueues.The
register_block_typeAPI now supports the following properties:editor_scripteditor_stylescriptstyleAssigning one or more of these to registered script or style handles will cause them to be enqueued in the corresponding render contexts (editor-specific or always).
This is intended as part of an effort to coalesce initial block implementations toward the server-side block registration API, as proposed in #2751 to be the default for new blocks.
Testing instructions:
Since this simply builds on existing APIs and no core blocks have been ported to using it (unclear whether this is a direction we'd want to go), there should be no expected impact of these changes.
You may try including a third-party block code and changing to implement with the
register_block_typeAPI.Example:
https://gist.github.com/pento/19b35d621709042fc899e394a9387a54