cc @ockham @gziolo

It might be good to handle these errors more gracefully, or perhaps prevent blocks with a save function from working altogether?

That's a good point. I would say that for a start, we should allow only dynamic blocks with render_callback (render applies, too). There is no way to use save in PHP to automatically inject the block with the expected HTML syntax.

More broadly, I believe there should be a way of saying - save function doesn't use HTML to store any attributes (it might not be a strict requirement), so we can use it as a fallback. In effect, it should NOT be used for block validation. In particular, the block referenced in the description, will get reported as invalid when someone opens the editor after the current year changes. The reason is that the block gets saved to the database the following syntax after it gets inserted into the editor in the regular flow:

<p class="outermost-copyright-date-block">© 2017-2023</p>

When someone opens the editor in 2024, then the save will produce:

<p class="outermost-copyright-date-block">© 2017-2024</p>

This is enough to trigger the block invalid warning.

I hope that we can improve handling for dynamic data like the current year with #54536.

Interesting, that's a pattern that hadn't occurred to me 🤔

A simple WordPress block plugin that utilizes both a render.php file and a save.js file. On the front end, the render.php file takes precedence, but if the plugin is ever disabled, the save.js file serves as a fallback, so a copyright date is still displayed.

The other examples of having both a render.php and a save.js that I seem to recall are typically along the lines of a "template" block, i.e. something like the Comment Template block that the user can customize in the editor (by rearranging inner blocks etc), which is then "populated" on the frontend with data from the DB that is dynamically fetched by PHP.

The problem you're encountering is indeed somewhat inherent in how Block Hooks work: As @gziolo said, since we want them to function on the frontend even if the user never loads and saves them in the editor, they have to be dynamic, and have to render the desired output from their default state, i.e. with no attributes set or inner blocks present. However, since save() is called by the editor during load time for block validation, it's bound to cause a validation error if the default markup returned from save() is non-empty -- which in the context of your example block is by design.

This kind of block validation happens at a fairly low level, so I'm leaning towards disallowing blocks like that from being used as hooked blocks. Note that we might be able to widen the set of allowed blocks a bit beyond "only has a render_callback but not save.js": It's probably permissible to have a save.js in addition to a render callback, as long as that save.js returns the exact same output as does the render callback, if invoked with no attributes set (i.e. only default values) and no inner blocks present. This might allow for (some) "template-style" blocks such as Comment Template to be used as hooked blocks (but I'll have to verify, and maybe tweak the markup returned from save.js and the render callback a bit).

@ndiego @ockham @gziolo This seems to be more discussion on what's possible and what's not rather than about something that can be fixed. It's more about defining the boundaries. It made it on to the project board for WordPress 6.4 release, though. What's are your thoughts about taking it off the board?

This seems to be more discussion on what's possible and what's not rather than about something that can be fixed. It's more about defining the boundaries. It made it on to the project board for WordPress 6.4 release, though. What's are your thoughts about taking it off the board?

Sounds fine to me 👍 (@ndiego feel free to veto/overrule 😄 )

Sounds good

AFAICT, this is no longer a limitation in WP 6.5 (see e.g. the Copyright Date block being used in this example in the Dev Blog post on Block Hooks).