Gutenberg: Custom block rendered as a classic editor block automatically

Created on 26 Apr 2018  路  8Comments  路  Source: WordPress/gutenberg

Issue Overview

I'm taking my first steps in developing a custom block plugin based on the core gallery block and recently I stumbled into a problem. Everything seems to work as expected: at first glance the block is rendered correctly both on the editor and the frontend. But, if I save the post, then preview it and at the end I come back to edit it again, the custom block is automatically rendered in the editor as a classic editor block, although the HTML code beneath it shows that it's still a custom block. The console shows no errors.

My question is, in which conditions Gutenberg falls back to render a custom block as a classic editor block? Which is the Gutenberg function deciding this? I'm checking my registerBlockType function and I don't see anything strange (no block name collisions or anything similar).

[Feature] Blocks [Type] Question

All 8 comments

This is duplicate of #5661. The plugin is loaded too late and that's why editor uses the fallback block.

Can you try to use the solution described in: https://github.com/WordPress/gutenberg/issues/5661#issuecomment-376147009?

It might be an actual issue with the wrong order of assets loaded by Gutenberg. Can you share how do you register your script in PHP?

PHP:

    function register_block() {
        wp_register_style(
            'gutenberg-slider',
            plugins_url( 'css/editor.css', __FILE__ ),
            array( 'wp-edit-blocks' ),
            filemtime( plugin_dir_path( __FILE__ ) . 'css/editor.css' )
        );
        wp_register_style(
            'gutenberg-slider-frontend',
            plugins_url( 'css/style.css', __FILE__ ),
            array( 'wp-blocks', 'slick' ),
            filemtime( plugin_dir_path( __FILE__ ) . 'css/style.css' )
        );
        wp_register_script(
            'gutenberg-slider',
            plugins_url( 'block.build.js', __FILE__ ),
            array( 'wp-blocks', 'wp-components', 'wp-element', 'wp-utils', 'wp-i18n', 'lodash' ),
            filemtime( plugin_dir_path( __FILE__ ) . 'block.build.js' ),
            true
        );
        register_block_type( 'my/slider', array(
            'editor_style'  => 'gutenberg-slider',
            'editor_script' => 'gutenberg-slider',
            'style' => 'gutenberg-slider-frontend'
        ) );

    }
    add_action( 'init', 'register_block' );

JS:

    registerBlockType( 'my/slider', 
        title: __( 'Slider' ),
    description: __( 'An Image slider.' ),
        .... (the rest is omitted for clarity) ....
    );

I tried to load the block script at the header like you proposed and now I get two block validation errors:

Block validation: Expected token of type `EndTag` ( 
Object { type: "EndTag", tagName: "ul" }
 ), instead saw `StartTag` ( 
Object { type: "StartTag", tagName: "li", attributes: [鈥, selfClosing: false }
 ).

Block validation: Expected tag name `div`, instead saw `ul`.

I must be doing something wrong but I don't know what it is.

I tried to load the block script at the header like you proposed and now I get two block validation errors:

This sounds much better. It means it solved the root issue. I'm working on a patch which will make it work regardless if you put true or false as 5th param :)

Regarding your error, can you try to get some more help on WordPress.org slack #core-editor channel?

Ok, I'll try that.
Thanks

Closing this because I've already found the crux of my second problem: a typo in my code.
Thanks for helping me, gziolo.

It should work now regardless of the location of the script (footer vs header) after #6448 got merged.

Was this page helpful?
0 / 5 - 0 ratings