Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix: Empty Classic Editor inside innerBlock fatal error #17164
The problem is that the
How has this been tested?
Types of changes
Thanks for working on this! I have my doubts regarding the fix itself. Indeed, the parser (
The result of the above is that the
@mcsf It seems like a valid case yes. I think we should just make sure that when we serialize a post composed of just empty classic blocks, we shouldn't end up with a lot of useless empty lines and just trim them from the serialization. (So basically move the fix to the serialization)
That makes sense. :)
@donmhico, is this something you’d like to take on? Would you also be able to add tests to cover this issue? Otherwise we can split the load.
First is, I'm unsure if the fix I provided is still valid and if I should just create unit tests for it. Or do I have to look into the serialization you both mentioned?
Thanks! We'll guide you, for sure.
So this particular PR would have to change so that:
From what I can see, this can be fixed by doing removing freeformContentFallbackBlock as a check for isFallbackBlock from
const isFallbackBlock = ( - name === freeformContentFallbackBlock || name === unregisteredFallbackBlock );
However, like you've said @mcsf. I'm unsure why it freeformContentFallbackBlock is included in the check in the first place.
Also applying the change above and running
I'm unsure how to achieve this. Any guidance would be greatly appreciated.
Hi, @donmhico. Riad is away for a few days, but I'm around to assist.
Yeah, this would achieve it.
Let's assume that the only reason was to avoid piling up "empty" freeform blocks that would later be serialised into unnecessary whitespace. See this particular comment: #663 (comment)
So, in the same way that we were checking for something like
These are expected. In the tests, there is a particular suite that tests parsing and serialisation, and it should fail unless the tests are patched:
What this suite does is test, for all core block types, that a particular block output in parsed in a specific way, and that it later gets reserialised in another particular way. See
The tests now fail because the fixtures have a lot of whitespace in between blocks that now are recognised in the parser as empty freeform blocks, and these don't correspond with the expect result stated in the test fixtures.
One way to address this would be to patch all the fixtures. But, now that I'm thinking about this, I think we can approach the problem slightly differently:
You see, initially a Freeform/Classic block was defined in the parser as "any area of content that wasn't part of a proper block". This worked well conceptually and functionally until we introduced nesting. We eventually had to change this in #16477.
Nowadays, the serialiser will check to see whether a Freeform block is at the root of the content or whether it's nested in other blocks.
<!-- wp:freeform --> Some classic content <!-- /wp:freeform -->
This brings me to the current PR. Here is what we could do in the parser:
Since Freeform blocks in nested contexts are always demarcated, this would fix the parent issue.
The way that we can recognise whether we're dealing with a non-demarcated Freeform block is by looking at the block node's
wp.blockSerializationDefaultParser.parse( `<!-- wp:group --> <div class="wp-block-group"><div class="wp-block-group__inner-container"><!-- wp:freeform /--></div></div> <!-- /wp:group --> <p>B</p> <!-- wp:paragraph --> <p>C</p> <!-- /wp:paragraph -->` )
the resulting array will show that the Freeform block with content
This should be enough to get you started, @donmhico! If not, feel free to reach out!
@donmhico, actually I'd like to merge more or less what you have now on this branch just so that we can release Gutenberg 6.4 with no critical errors in it. This would be a temporary fix — in which we still lose nested empty Classic blocks but we don't crash the application. I realise it's late in the day for you, so I think I'll merge your PR in a minute and we can continue refining this separately. :)