Implement init.php in the same way as the handbook

[hadamlenz]

This is a suggestion

The handbook is the only source of official reference at the moment. On this page it uses an init action to attach the block.js and call register_block_type. While this is a bit more code compared to what you have, and your code still works really well, it might be good to follow the precedent (not quite a standard yet) set forth by the handbook.

I had to implement register_block_type so that I could make my block dynamically rendered by the server.

5 stars and 3 cheers. It's wonderful

[ahmadawais]

@hadamlenz

🙌

Thanks for dropping by. I see what you are asking about here, but I think that enqueue_block_assets and enqueue_block_editor_assets are the right hooks for when all you need to do is hook styles and scripts for Gutenberg. init hook is not for Gutenberg and while it can be used, so I don't know about that.

👋 I'd like to refer this one to @felixarntz @mtias @gziolo @pento — what do you guys think is the right way to go here?

Here's the source code in question

<?php
/**
 * Blocks Initializer
 *
 * Enqueue CSS/JS of all the blocks.
 *
 * @since   1.0.0
 * @package CGB
 */

// Exit if accessed directly.
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

/**
 * Enqueue Gutenberg block assets for both frontend + backend.
 *
 * `wp-blocks`: includes block type registration and related functions.
 *
 * @since 1.0.0
 */
function my_block_cgb_block_assets() {
    // Styles.
    wp_enqueue_style(
        'my_block-cgb-style-css', // Handle.
        plugins_url( 'dist/blocks.style.build.css', dirname( __FILE__ ) ), // Block style CSS.
        array( 'wp-blocks' ) // Dependency to include the CSS after it.
        // filemtime( plugin_dir_path( __FILE__ ) . 'editor.css' ) // Version: filemtime — Gets file modification time.
    );
} // End function my_block_cgb_block_assets().

// Hook: Frontend assets.
add_action( 'enqueue_block_assets', 'my_block_cgb_block_assets' );

/**
 * Enqueue Gutenberg block assets for backend editor.
 *
 * `wp-blocks`: includes block type registration and related functions.
 * `wp-element`: includes the WordPress Element abstraction for describing the structure of your blocks.
 * `wp-i18n`: To internationalize the block's text.
 *
 * @since 1.0.0
 */
function my_block_cgb_editor_assets() {
    // Scripts.
    wp_enqueue_script(
        'my_block-cgb-block-js', // Handle.
        plugins_url( '/dist/blocks.build.js', dirname( __FILE__ ) ), // Block.build.js: We register the block here. Built with Webpack.
        array( 'wp-blocks', 'wp-i18n', 'wp-element' ) // Dependencies, defined above.
        // filemtime( plugin_dir_path( __FILE__ ) . 'block.js' ) // Version: filemtime — Gets file modification time.
    );

    // Styles.
    wp_enqueue_style(
        'my_block-cgb-block-editor-css', // Handle.
        plugins_url( 'dist/blocks.editor.build.css', dirname( __FILE__ ) ), // Block editor CSS.
        array( 'wp-edit-blocks' ) // Dependency to include the CSS after it.
        // filemtime( plugin_dir_path( __FILE__ ) . 'editor.css' ) // Version: filemtime — Gets file modification time.
    );
} // End function my_block_cgb_editor_assets().

// Hook: Editor assets.
add_action( 'enqueue_block_editor_assets', 'my_block_cgb_editor_assets' );

🤞

In this case is it better to use enqueue_block_assets and enqueue_block_editor_assets as done above or init action like the one below?

<?php

function gutenberg_boilerplate_block() {
    wp_register_script(
        'gutenberg-boilerplate-es5-step01',
        plugins_url( 'step-01/block.js', __FILE__ ),
        array( 'wp-blocks', 'wp-element' )
    );

    register_block_type( 'gutenberg-boilerplate-es5/hello-world-step-01', array(
        'editor_script' => 'gutenberg-boilerplate-es5-step01',
    ) );
}
add_action( 'init', 'gutenberg_boilerplate_block' );

Looking forward!

[gziolo]

The handbook is the only source of official reference at the moment. On this page it uses an init action to attach the block.js and call register_block_type. While this is a bit more code compared to what you have, and your code still works really well, it might be good to follow the precedent (not quite a standard yet) set forth by the handbook.

Yes, I also followed this API when working on the WP-CLI's command to scaffold a block wp scaffold block. You can see an example output of this command in the Gutenberg's handbook here. It also uses register_block_type and enforces to register all scripts and assets before they are enqueued. At the moment both approaches work technically the same, but if you want to have it future proof I would rather pick register_block_type because if we will need to pass some additional options we will rather do it using this function.

[felixarntz]

I think using the init hook to register the block type including its assets makes more sense since there is already centralized logic in place that automatically takes care of enqueueing the assets when needed (see this function which internally uses the enqueuing hooks anyway).

While at this point, server-side registration is not required, it provides a common foundation to use for all of WordPress, and there have also been discussions about requiring server side registration for all blocks, for that very reason (see https://github.com/WordPress/gutenberg/issues/2751).

[gziolo]

@felixarntz, thanks for explaining in depth what I said. Yes, having this as init hook will allow also allow all the plugin developers to have much better control over which blocks will be registered without passing anything to JS code.

[ahmadawais]

🙌 @gziolo @felixarntz I agree with your stance here. Thanks, @hadamlenz for bringing this to my attention and reporting it here. Anyone of you willing to send a PR for this? I'll accept that right away.

Looking forward!

[asharirfan]

Hi @ahmadawais 👋

I have implemented the above-mentioned changes in cgb-scripts/template/src/init.php & I am trying to test these changes to verify the solution.

I need a little help to confirm those changes 🙌

I believe you have already written the following commands in package.json of this repository to test with a demo block ✅

npm run demo

OR

node tasks/cgb.js demo

Whenever I try any of these commands, my terminal is stuck at the same point for hours. Please take a look at the following screencast:

Any insight into this issue is much appreciated. If this issue is not resolved, then I will send a PR anyway for you to test the changes 🔥

I would also love to contribute to the future development 💯

Thanks!

[ahmadawais]

@asharirfan have you read the Contribution guide in the root?

[asharirfan]

@ahmadawais Yes, I did. I thought it would work with npm too. Sorry, my bad. yarn create-guten-block demo-block command is working 🙌

❌ But the changes implemented in cgb-scripts/template/src/init.php are not rendering in the demo-block i.e. the file is still loading previous template.

[ahmadawais]

@asharirfan how about you install the latest build and change things in the node installation folder till I write the guide on how you do it?!

Once you install it with

npm i -g create-guten-block

It should be somewhere here

/Users/$USER/.nvm/versions/node/v{YOUR_NODE_VERSION}/lib/node_modules/create-guten-block

[drzraf]

By default, block's Javascript that takes care of rendering the content is only loaded for editors. IHMO this is a bit confusing for Gutenberg newcomers because it seems to ignore frontend rendering.