-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Accordion Block: Simplify script module enqueueing #71742
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
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Flaky tests detected in 3c4f9b3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17857456722
|
| ); | ||
|
|
||
| wp_enqueue_script_module( '@wordpress/block-library/accordion' ); | ||
| wp_enqueue_script_module( '@wordpress/block-library/accordion/view' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be in the viewScriptModule block.json instead of an enqueue here? That seems like the simplest and most direct approach:
gutenberg/packages/block-library/src/accordion/block.json
Lines 65 to 66 in fd62fb2
| "style": "wp-block-accordion" | |
| } |
Some blocks enqueue in their render callback because the enqueue is conditional.
I suppose this is conditional if $content is falsy, however when inserting an empty accordion block the module is enqueued, so that seems more like defensive coding than an optimization to conditionally enqueue the asset.
Aside: I noticed the field is not in the block.json handbook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simply defined the viewScriptModule field, but for some reason the src attribute is not correct:
I've looked into the code and can confirm that at least the path here is correct:
gutenberg/lib/client-assets.php
Line 672 in 500dd9b
| wp_register_script_module( $script_module_id, $path, $script_module_data['dependencies'], $script_module_data['version'], $args ); // The $args parameter is new as of WP 6.9 per <https://core.trac.wordpress.org/ticket/61734>. |
Is there an error somewhere in this PR? By the way, there are no other core blocks that use the viewScriptModule field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Registration should be handled elsewhere, rather than using local file: for the module, it can refer to the registered module ID (suggested here: #71742 (review)).
I believe the rest of the changes in this PR can then be reverted.
Sorry, I didn't mean to complicate this simplification 🙂
there are no other core blocks that use the viewScriptModule field.
I think that's because the conditionally enqueue, like in the image block that only enqueues the module if some attributes are present:
gutenberg/packages/block-library/src/image/index.php
Lines 67 to 73 in 99d25fb
| if ( | |
| isset( $lightbox_settings ) && | |
| 'none' === $link_destination && | |
| isset( $lightbox_settings['enabled'] ) && | |
| true === $lightbox_settings['enabled'] | |
| ) { | |
| wp_enqueue_script_module( '@wordpress/block-library/image/view' ); |
3d93db8 to
12b0304
Compare
12b0304 to
9a0aa26
Compare
b1ad605 to
318be0a
Compare
318be0a to
12b1034
Compare
|
@sirreal I suspect that the It seems that 12b1034 fixed the problem commented here. If this fix is suitable, we can submit a separate PR to fix the script module itself. What do you think? |
|
The latest change doesn't output the script tag itself.. |
|
Thank you, it works! However, the |
It should (and I believe it does that correctly) however it's quite tricky in the case of the block library. The modules can exist in two different places and refer to a different file depending on whether Gutenberg has swapped its versions for the Core versions. In this case, with Core/Gutenberg modules, there are systems in place that handle registration and it's easier to refer to a registered module ID and not care about where it comes from. |
sirreal
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and working for me. Nice simplification, thanks!
* Accordion Block: Simplify script module enqueueing * Use `viewScriptModule` field * Replace build module path * Change viewScriptModule field value and revert some changes * Update viewScriptModule ID --------- Co-authored-by: t-hamano <[email protected]> Co-authored-by: sirreal <[email protected]>
* Accordion Block: Simplify script module enqueueing * Use `viewScriptModule` field * Replace build module path * Change viewScriptModule field value and revert some changes * Update viewScriptModule ID --------- Co-authored-by: t-hamano <[email protected]> Co-authored-by: sirreal <[email protected]>
What?
I'm not sure why such complicated logic is used to enqueue the script module in the Accordion block. It should work by just running
wp_enqueue_script_module.Testing Instructions
Insert an Accordion block and confirm that it's interactive on the frontend.