-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Prevent usage of gutenberg_url
in block-library
#58242
Conversation
'@wordpress/block-library/file-block', | ||
gutenberg_url( '/build/interactivity/file.min.js' ), | ||
'@wordpress/block-library/file', | ||
defined( 'IS_GUTENBERG_PLUGIN' ) && IS_GUTENBERG_PLUGIN ? gutenberg_url( '/build/interactivity/file.min.js' ) : includes_url( 'blocks/file/view.min.js' ), |
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.
Just checking my understanding here. What's the long term vision for these wp_register_script_module
calls? Are they going to be done automatically using block.json
or if we need conditionals, maybe instead we should have generic calls like wp_hydrate_block( 'core/file' )
or something where the actual files are not hard-coded by guessed from block.json or something.
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.
As far as I remember @sirreal is working on a viewModule and viewScriptModule feature in block json. So should be done automatically.
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.
Yes. In the short term, we should replace them with viewScriptModule
entries in the block.json
. Then, at some point, I'd like to resume our work on behaviors where a single block can have a set of behaviors defined, and depending on the active ones, WordPress will enqueue the required JS and CSS files for those behaviors.
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.
why not viewModule? or do we use that for something else?
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.
or viewScript?
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.
In the beginning, we called it the Modules API but then everything was renamed to "script modules":
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.
Here's the viewScriptModule
for Core: WordPress/wordpress-develop#5860
viewModule
support was implemented in Gutenberg, but when "modules" became "script modules" in Core it seemed to make sense to align and use viewScriptModule
, but that's still up for review.
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.
LGTM
* Prevent usage of gutenberg_url in block-library * Add includes_url * Update enqueue module identifiers
I just cherry-picked this PR to the release/17.6 branch to get it included in the next release: 385bf9f |
* Prevent usage of gutenberg_url in block-library * Add includes_url * Update enqueue module identifiers
What?
Prevent the usage of
gutenberg_url
in the interactive blocks of theblock-library
package.Why?
Because we mistakenly left it in the #57778 PR and
block-library
should never contain direct usage of Gutenberg functions because it's synced "as it is" in WordPress Core, where those functions don't exist.How?
By checking first if Gutenberg is activated, and if it's not, using
includes_url
instead ofgutenberg_url
.