This notice drove me insane, especially because I couldn’t quite figure out what was being compared. It turns out it’s that the save function in registerBlockType() compares its return value to whatever is between the block’s html comment tags in the database.

SO

if my original save function is (I’m returning a hardcoded string for clarity)

which saves to this in the post’s entry in the database (in the wp_content column in wp_posts table)

but then I decide that I need my own class on that, so change it to

Then it’ll fail with the error message in the console

Frustrating.

I’ve taken to storing the attribute values in the comment and rendering them using the php register_block_type() function. As Daniel Bachhuber points out here, it’s probably good to have fallback HTML content in case the block plugin or what have you disappears. It’s just that once I introduce that, it’s going to make my life difficult if I change it. It might be possible to use “transforms” in the registerBlockType object (see edit below) but thinking about that makes me tired, so I’m going to make every effort to avoid in the first place.

(The circle-text block is taken from this plugin I made to figure these things out. 🙂 )

=== edit courtesy of Herb Miller ===

Herb pointed out that the correct way to change the return value is by using the “deprecated” key in the registerBlockType object. Now this is much easier and the correct way to do it. But does it update previously saved blocks? It can’t unless a post using those blocks is saved, at least.

Also, my blocks would contain a quite large array of deprecated objects so I’m going to stick with using the php server side rendering. But this means that I can go back and change previous blocks to use that and am much more comfortable adding in some fallback HTML.