Block Plugin Doesn’t work With Theme >= 2022

Resolved George Sexton
(@gsexton)

3 years, 3 months ago

I have a plugin, and it supports Gutenberg blocks. I’m using WordPress 6.1.1 On OpenSUSE with PHP 7.4.25. The plugin does work as expected with the 2021 theme. I can insert the block with the 2022 theme, and the block insertion/edit works as expected.

However, when viewing the page, the block doesn’t render.

I’ve poked around, and it looks like the block naming convention may have changed. Looking through my code, I have a fully qualified block prefix of: “plugin-name-gblock”. The code editor shows a block name of “plugin-name/gblock”.

Is this a known change? Can you give me any information about what happened and how I should remediate things?

Thanks!

George

Viewing 5 replies - 1 through 5 (of 5 total)

Thread Starter George Sexton
(@gsexton)

3 years, 3 months ago
I looked at this a little more closely. I am calling register_block_type() with the same naming format that I see the block name in the editor. The return value of register_block_type() is shown below.

What’s happening is the render callback isn’t getting hit. Again, with the WP 2021 theme, it works, with 2022/2023 it doesn’t. The render callback argument for register_block_type() is:

'render_callback' => array($this, 'renderGutenberg')
```
Class Name= WP_Block_Type Data= {
    "api_version": 1,
    "name": "pluginname/gblock",
    "title": "",
    "category": null,
    "parent": null,
    "ancestor": null,
    "icon": null,
    "description": "",
    "keywords": [],
    "textdomain": null,
    "styles": [],
    "variations": [],
    "supports": null,
    "example": null,
    "render_callback": [
        {},
        "renderGutenberg"
    ],
    "attributes": {
        "lock": {
            "type": "object"
        }
    },
    "uses_context": [],
    "provides_context": null,
    "editor_script_handles": [
        "pluginname-gblock-editor"
    ],
    "script_handles": [],
    "view_script_handles": [],
    "editor_style_handles": [
        "pluginname-gblock-editor"
    ],
    "style_handles": [
        "pluginname-gblock"
    ]
}
```
- This reply was modified 3 years, 3 months ago by George Sexton.
Moderator Kathryn Presner
(@zoonini)

3 years, 3 months ago

Hi @gsexton – I asked a developer to take a look at this for you, but they’d like to see the full plugin to be able to troubleshoot further. Could you please provide a link to your complete plugin, either in the WordPress.org repository, on GitHub, or elsewhere. Thanks!

Thread Starter George Sexton
(@gsexton)

3 years, 3 months ago

@zoonini Thanks for checking. The plugin is at:

https://wordpress.org/plugins/connect-daily-web-calendar/

The register_block_type() is in class-cdaily-wordpress-plugin.php around line 100.
Ryan Welcher
(@welcher)

3 years, 3 months ago
Hi there!

I dug into the code a bit and believe I have found the issue. The initGutenberg function which registers the block is being called in addPluginStylesheet which is being run on the wp_enqueue_script hook.

I believe this hook is run too late for it to work on the front end. I move the register_block_type call out of the hook and into the main plugin PHP file and it displayed correctly on the front end.

Please keep in mind that this is a very complicated plugin and I have only taken a cursory look but that is where I would start

Hope this helps!
- This reply was modified 3 years, 3 months ago by Ryan Welcher.
Thread Starter George Sexton
(@gsexton)

3 years, 2 months ago
@welcher Thanks so much for looking into this. Your assessment was correct. I restructured the code so that the block type is registered in the startup code and that resolved the problem.
- This reply was modified 3 years, 2 months ago by George Sexton.

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘Block Plugin Doesn’t work With Theme >= 2022’ is closed to new replies.

Tags