-
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
Consider filter for allowing block asset registration index.asset.php
optional
#57234
Comments
We are discussing in #46954 (comment) removing the check to enforce the Instead, maybe we should put a filter just before registering the block related script to allow developers to apply their modifications before this code: What do you think? |
👍 🤔
I'm not sure what the benefit would be. It would seem to just a be courtesy that could lead to confusion. 🤔
Accounting for the input and considerations in #46954 – I'm trying to distinguish where there is inclusivity or exclusivity in each feature request. I like the idea of allowing developers to opt out of the required As @lgladdy expressed #46954 (comment):
This is a benefit I had not considered. 👍 Also, considering @lgladdy:
And @gziolo offering:
I'm not sure that the extra step would be necessary? Could it potentially be a follow-up Issue and Pull Request, or would it be required as part of the work to get #46954 resolved? It might take some code exploration. |
Just a heads up - I will be off for the rest of the year. I look forward to the momentum of 2024. ❤️ |
For clarity, when registering decoupled blocks via Faust.js, the blocks are correctly appearing/functioning in the inserter. This can be seen in the project's block-support example. I've outlined some potential solutions that would work for my use case; removing what I believe to be an unnecessary warning that does not account for all block registration scenarios.
|
After reading the comments, I'm in favor of removing the Let's also work on the |
I think the description of the ticket here is somewhat misleading. The error only happens when a block tries to register any asset via a local {
"viewScript": "file:./view.js"
} If you don't want that handling, it is not a requirement for building & registering blocks. Instead you can always either completely manually handle all the asset registration and enqueueing without even making WordPress aware of it. Or you can register all your assets and then pass the handles to the various properties in the wp_register_script(
'my-custom-handle',
$url,
$dependencies,
$version,
[ 'strategy' => 'defer' ]
); {
"apiVersion": 3,
"viewScript": "my-custom-handle"
} Having said all that I'm not strictly against adding some more / better handlig for cases where the And also yeah I'm 100% still in favor of adding more options to |
@fabiankaegy thanks for the additional clarity. 👍
Indeed. 😄 |
PR has been updated! |
@gziolo do you think this is ready for merge? Need more feedback? |
Yes, it’s almost ready. I have enough to land it. I need to find some time next week for it 👍 |
This is now resolved in WordPress core with WordPress/wordpress-develop@0ff0842. |
What problem does this address?
As previously discussed in #40447, it is a hard requirement that a
*.asset.php
file is present to register a block in WordPress. Otherwise, it throws a Warning:function register_block_script_handle was called incorrectly. The asset file (/wp-content/uploads/faustwp/blocks/block-a/index.asset.php) for the "editorScript" defined in "create-block/block-a" block definition is missing. (This message was added in version 5.5.0.)
, and the block will not appear in the inserter.Decoupled applications would benefit from allowing this condition as optional.
Leaning into the rich history of WordPress hooks and filters, it could become optional for this file to exist, opening up a world of possibilities in decoupled architecture. Please see Faust.js's example: wpengine/faustjs#1656.
This would also allow developers flexibility in tooling and possibly set up custom webpack integrations (or even other build tools). Similarly, this may benefit progress toward the experiments in lazy-loading block infrastructure #2768.
What is your proposed solution?
One solution: allow filtering of
$script_asset_path
, as seen in this proof-of-concept PR from @josephfuscoWordPress/wordpress-develop#5799
The text was updated successfully, but these errors were encountered: