-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Proposal: add "assets_callback" to "register_block_type" #5705
Comments
This was discussed in Slack #core-editor weekly triage meeting: https://wordpress.slack.com/archives/C02QB2JS7/p1522944533000262 |
@kanishkdudeja is working on something similar, can you double check if you have common goals? See #6166 :) |
@gziolo yeah, that's what I thought when I looked at #5445. I have a PR for this issue already on #5740, but it would be much better if custom styles were bundled into a static css file based on what @kanishkdudeja is doing. |
@diegoliv sounds great, I hope you two can come up together with something mergeable 👍 |
Closing in favor of #5445 where a similar issue is tackled on a much broader level. |
Issue Overview
After working with some custom blocks on Gutenberg and post meta, I felt the need of a better way to to leverage individual block attributes in more specific ways. For example, when we have some attributes to style the block (like font size, colors, etc), but we don't want to inline these styles. We could use
wp_add_inline_style()
to build<style>
tags inside the<head>
. To do that, we need a way to access a block's attributes inside hooks likewp_enqueue_scripts / styles
orwp_print_scripts / styles
. So we can properly use these functions along with useful checks likewp_style_is()
orwp_script_is()
. In other words, we need a proper callback function to handle assets or other stuff that relates to them.Currently,
register_block_type()
has arender_callback
parameter that you can add a custom function to run and render the block html. This function can almost be used for that, but it runs too late on a post / page. So we could do a callback that works in a similar way (returning$attributes
as a variable ), but runs inside proper hooks, likewp_enqueue_scripts
or evenenqueue_block_assets
.By offering this kind of callback, we could eliminate the need of using attributes to store post_meta related to the block itself (resolving issues like #5599 and #5626 and providing a viable solution for tickets like #5251 and #5360).
Possible Solution
Right now I'm working on a PR for this, but wanted to get some feedback on the idea. Thoughts?
The text was updated successfully, but these errors were encountered: