Skip to content
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

Closed
diegoliv opened this issue Mar 20, 2018 · 5 comments
Closed

Proposal: add "assets_callback" to "register_block_type" #5705

diegoliv opened this issue Mar 20, 2018 · 5 comments
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience

Comments

@diegoliv
Copy link

diegoliv commented Mar 20, 2018

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 like wp_enqueue_scripts / styles or wp_print_scripts / styles. So we can properly use these functions along with useful checks like wp_style_is() or wp_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 a render_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, like wp_enqueue_scripts or even enqueue_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

    function my_block_register_block(){
        register_block_type( 'namespace/block-example', array(
            'assets_callback' => 'my_block_do_assets',
        ) );
    }

    add_action( 'init', 'my_block_register_block' );

    function my_block_do_assets( $attributes ){
        // do whatever you need with the block attributes. For example, you can generate <style> tags, 
        // with wp_add_inline_style(), enqueue scripts / styles, or call wp_localize_script().
    }

Right now I'm working on a PR for this, but wanted to get some feedback on the idea. Thoughts?

@danielbachhuber danielbachhuber added the [Feature] Extensibility The ability to extend blocks or the editing experience label Mar 30, 2018
@aduth
Copy link
Member

aduth commented Apr 5, 2018

This was discussed in Slack #core-editor weekly triage meeting: https://wordpress.slack.com/archives/C02QB2JS7/p1522944533000262

@gziolo
Copy link
Member

gziolo commented Apr 13, 2018

@kanishkdudeja is working on something similar, can you double check if you have common goals? See #6166 :)

@diegoliv
Copy link
Author

@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.

@gziolo
Copy link
Member

gziolo commented Apr 13, 2018

@diegoliv sounds great, I hope you two can come up together with something mergeable 👍

@gziolo
Copy link
Member

gziolo commented Apr 20, 2018

Closing in favor of #5445 where a similar issue is tackled on a much broader level.

@gziolo gziolo closed this as completed Apr 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience
Projects
None yet
Development

No branches or pull requests

6 participants