6.6: changed behaviour on pressing Enter on a selected block

[elzadj]

Description

Hi everyone!

We noticed that hitting Enter on our custom blocks inserts an empty paragraph since the 6.6.2 6.6 update. Before 6.6.2 6.6 it was inserting a copy of the same block.

We suspect that this has something to do with that fix: https://github.com/WordPress/gutenberg/pull/64992/files

The block in question: https://github.com/maxi-blocks/maxi-blocks/tree/master/src/blocks/text-maxi

Can you advise something, please? Maybe we can make some changes to revert it without rolling back to 6.5.5? Something for splitting the block, possibly?

Note: Adding support for "splitting": doesn't help.

Thanks!

Step-by-step reproduction instructions

1. https://wordpress.org/plugins/maxi-blocks/
2. Add a Container + Text inside a Column
3. Press Enter on the Text, Column, Row.
   Or check the videos below.

Screenshots, screen recording, code snippet

Before 6.6:

screencast-maxiblocks.com-2024.09.12-12_54_32.webm

On 6.6.2:

screencast-wordpress.local-2024.09.12-13_23_08.1.webm

Environment info

WordPress 6.6.2
PHP 8.3

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[Mamaduka]

cc @stokesman

[stokesman]

So far I’m not able to reproduce the desired behavior on 6.6.1. I find that, from a Text Maxi block, pressing Enter inserts a core paragraph, whether the the block is nested in a Container Maxi block or not. That was testing MaxiBlocks 1.9.5.

I notice in the "Before 6.6.2" screen recording there seem to be more plugins enabled than in the other screen recording. Also I don’t see the Document Bar. It has been around since before 6.6.1 so it makes me wonder what the actual version of WP is in that screen recording.

☝️ Document Bar for clarity’s sake.

We suspect that this has something to do with that fix: https://github.com/WordPress/gutenberg/pull/64992/files

It doesn’t seem likely to be related. Those changes and that whole file are solely involved with handling a mouse event and I don’t see how that would affect this keyboard behavior.

[Mamaduka]

This could be related to the onSplit callback deprecation in WP 6.6. I see that the Text Moxi block is using it.

This was mentioned in dev note as well.

[elzadj]

This could be related to the onSplit callback deprecation in WP 6.6. I see that the Text Moxi block is using it.

This was mentioned in dev note as well.

Yes, it definitely started from 6.6, and is connected to onSplit deprecation.

But it seems like we can't re-create the behaviour we had before 6.6? We want the block to support splitting, but we also want to create a new empty Text block when we hit Enter at the end of it. It looks like creating an empty paragraph is the default now , right?

It's also mentioned that onSplit should continue to work, but seems like it's not the case any more.

Is there any alternative to onSplit?

[joshualip-plaudit]

I tried to implement a block that I need to split off into a new heading today, and encountered the raft of issues you've found here.
Based on the digging through the code I've done, the answer is as maddening as it is simple: All functionality related to onSplit has been replaced with... something that has yet to be properly documented.
As far as I can tell, the proposed, "unified flow" devolved into, "just shove a paragraph in if the split happened at the end and duplicate the block otherwise" (which, obviously, is a poor replacement for onSplit).

However, none of that is what actually got implemented. As far as I can tell, the final functionality is currently remarkably buggy (#64071, #64771) and the actual outcome appears to be improperly dependent on metadata properties. In addition, support for onSplit was completely removed in direct contradiction to the PR comment you referenced. This is, of course, also in direct contradiction to the documentation on WordPress' own website.

[ellatrix]

Is there any alternative to onSplit?

Yes, set splitting to true in your block supports object. See https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/#splitting

It looks like #54543 (comment), right?

No, the default is whatever is configured as the default block. See https://developer.wordpress.org/block-editor/reference-guides/packages/packages-blocks/#setdefaultblockname

Let me know if something doesn't work, maybe with minimal block registration code to reproduce.

[stokesman]

It's also mentioned that onSplit should continue to work, but seems like it's not the case any more.

In addition, support for onSplit was completely removed in direct contradiction to the PR comment you referenced.

I was just testing this out with a block I’m developing and concur. onSplit has ceased to work. I found that adding the identifier prop to RichText makes it work again (though the onSplit callback isn’t invoked so I guess it’s just a non-falsy value at this point). To restate, identifier being required for onSplit to work is new—so the change was breaking. In my case it works to use the new splitting support and not a big deal.

[stokesman]

Also the reason splitting support works fine in my case is because the block to split is the only allowed block type in the parent. That means, even if the split is at the end, the same block type is used—not the default block. I can see how it is problematic that a split at the end would otherwise insert the default block. It doesn’t seem right that to have that work you’d need to use setDefaultBlockName since that’s the editor level setting.

[gchtr]

I can confirm that onSplit stopped working for us completely. When switching to splitting support, it only worked once we added the identifier property to the RichText component.

However, this only works if there’s an attribute name we can pass to the identifier property. It doesn’t work if the block takes the value from a source other than attributes. In our case, it’s a meta field, where we load the value through useEntityProp(). In this case, hitting enter does nothing.