While in a LOCKED block template, multiple Freeform blocks in a row will merge data breaking the block template

[amarinediary]

Description

While in a LOCKED block template, multiple Freeform blocks in a row will merge data breaking the block template.

Step-by-step reproduction instructions

1. Register multiple Freeform block in a new or existing, default or custom, post type.

   //...
   'template' => [
   [ 'core/freeform' ],
   [ 'core/file' ],
   [ 'core/freeform' ],
   [ 'core/freeform' ],
   [ 'core/freeform' ],
   [ 'core/freeform' ],
   ],
   'template_lock' => 'all',
   //...

2. Add a new post.
3. Add some content to our Freeform block.
4. Publish, quit and come back.
5. Data from all Freeform blocks that are following one an other will have merge breaking the post template, with a warning displaying at the very to "The content of your post doesn’t match the template assigned to your post type."
6. Two options are associated with that warning "Keep it at is" or "Reset the template", the 2nd option will result in the template reloading with the old content being injected in a new block.

Expected behaviour

Multiple Freeform block in a row shouldn't merge data. Each block should keep existing.

Actual behaviour

Data between multiple Freeform block are merging under the first Freeform block, breaking the page pre-set locked block template.

Screenshots or screen recording (optional)

WordPress information

• WordPress version: 5.7
• Gutenberg version: 9.3-9.9
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? No

Device information

• Device: MacBook Air (13-inch, 2017)
• Operating system: macOS Mojave
• Browser: Version 89.0.4389.82 (Official Build) (x86_64)

[talldan]

Interesting issue, thanks for reporting. The problem is that the classic block doesn't have delimiters like other blocks.

That's best observed in the code editor (the middle paragraph is a classic block):

<!-- wp:paragraph -->
<p>test</p>
<!-- /wp:paragraph -->

<p>test</p>

<!-- wp:paragraph -->
<p>test</p>
<!-- /wp:paragraph -->

Anything in a classic block doesn't have a <!-- wp:block --> comment (the delimiter).

It's implemented this way because the classic block is used for handling content from the classic editor that won't have block content.

What essentially happens is that anything without the delimiter becomes a single classic block—which explains why you're seeing them merged.

I'm not sure this is something that will be feasible to fix, unfortunately. What's the reason for using multiple classic blocks in a template instead of just one?

[amarinediary]

@talldan An emerging practice is to use common blocks as meta blocks or using common blocks to fit a specific design. On the front end you can, instead of using the_content, pick and choose which block you want to use and where. Those practices are mainly used around a locked template 'template_lock' => 'all',.

<?php
$blocks = parse_blocks( get_the_content() );
foreach ( $blocks as $block ) :
    if ( $block['attrs']['className'] == 'myCustomClassName' ) :
        echo wp_strip_all_tags( render_block( $block ) );
    endif;
endforeach;  ?>

In regards to potential fixes or alternatives at least, the question to ask ourselves is:

Why would someone use a core/freeform block instead of a core/paragraph block for designing a block template?

From time to time, your data need an other type of formatting than plain text. Currently you can't switch from a core/paragraph block to a core/list block in a locked blocks template.

Giving the ability to switch between a core/paragraph block and a core/list block (while keeping the same className) or any other blocks related to text formatting would render the Freeform pretty much irrelevant (In a locked blocks template context that is).

[talldan]

Why would someone use a core/freeform block instead of a core/paragraph block for designing a block template?

@amarinediary A classic block isn't the equivalent of a paragraph block. A single classic block can still contain multiple paragraphs, lists, images, anything.

So I think my question is still valid - why use multiple classic blocks in a template instead of just one?

From time to time, your data need an other type of formatting than plain text. Currently you can't switch from a core/paragraph block to a core/list block in a locked blocks template.

There might also be other ways to achieve this, you could consider using a Group block in a template, and setting the templateLock attribute to false. That should make the whole post template locked, but the inner part of the group block could be edited freely.

[amarinediary]

There might also be other ways to achieve this, you could consider using a Group block in a template, and setting the templateLock attribute to false. That should make the whole post template locked, but the inner part of the group block could be edited freely.

@talldan Interesting, I will definitely take a look at the core/groupe block in conjunction with 'templateLock' => false. I just assumed that 'template_lock' => 'all' would also affect a core/group block.

But even tho, if the core/freeform block soul purpose is to to be used as a transition block between WYSIWYG and Gutenberg then wouldn't it be more logical to restrain the use of it ? As you're suppose to achieve the same result with Gutenberg's blocks ?

[amarinediary]

This behavior can now be bypass by grouping each core/freeform in a core/block. Tho now, in a locked template, using backspace on an empty nested core/freeform will delete it with no ability add it back.