-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parser (Fix): Output freeform content before void blocks #9984
Conversation
Resolves #9968 It was noted that a classic block preceding a void block would disappear in the editor while if that same classic block preceded the long-form non-void representation of an empty block then things would load as expected. This behavior was determined to originate in the new default parser in #8083 and the bug was that with void blocks we weren't sending any preceding HTML soup/freeform content into the output list. In this patch I've duplicated some code from the block-closing function of the parser to spit out this content when a void block is at the top-level of the document. This bug did not appear when void blocks are nested because it's the parent block that eats HTML soup. In the case of the top-level void however we were immediately pushing that void block to the output list and neglecting the freeform HTML. I've added a few tests to verify and demonstrate this behavior. Actually, since I wasn't sure what was wrong I wrote the tests first to try and understand the behaviors and bugs. There are a few tests that are thus not entirely essential but worthwhile to have in here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the quick fix, looks good!
Confirmed the test from #9968 and was able to reproduce the missing classic block in |
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "@wordpress/block-serialization-default-parser", | |||
"version": "1.0.0-rc.0", | |||
"version": "1.0.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the idea is that we don't touch the package.json ourselves, we let lerna do so at the moment of releasing. What we need to do though is to just add a not in the changelog and add an ( unreleased )
next to the version, that way the person that will publish the packages to npm will know what version to pick using lerna.
you can check CHANGELOG files from other packages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @youknowriad! I had no idea but TIL
Are there PHP tests [at all / for the fix intended here] ? |
No. Good point. |
* Parser (Fix): Output freeform content before void blocks Resolves #9968 It was noted that a classic block preceding a void block would disappear in the editor while if that same classic block preceded the long-form non-void representation of an empty block then things would load as expected. This behavior was determined to originate in the new default parser in #8083 and the bug was that with void blocks we weren't sending any preceding HTML soup/freeform content into the output list. In this patch I've duplicated some code from the block-closing function of the parser to spit out this content when a void block is at the top-level of the document. This bug did not appear when void blocks are nested because it's the parent block that eats HTML soup. In the case of the top-level void however we were immediately pushing that void block to the output list and neglecting the freeform HTML. I've added a few tests to verify and demonstrate this behavior. Actually, since I wasn't sure what was wrong I wrote the tests first to try and understand the behaviors and bugs. There are a few tests that are thus not entirely essential but worthwhile to have in here.
Resolves #9968
It was noted that a classic block preceding a void block would
disappear in the editor while if that same classic block preceded
the long-form non-void representation of an empty block then things
would load as expected.
This behavior was determined to originate in the new default parser
in #8083 and the bug was that with void blocks we weren't sending
any preceding HTML soup/freeform content into the output list.
In this patch I've duplicated some code from the block-closing
function of the parser to spit out this content when a void block
is at the top-level of the document.
This bug did not appear when void blocks are nested because it's
the parent block that eats HTML soup. In the case of the top-level
void however we were immediately pushing that void block to the
output list and neglecting the freeform HTML.
I've added a few tests to verify and demonstrate this behavior.
Actually, since I wasn't sure what was wrong I wrote the tests first
to try and understand the behaviors and bugs. There are a few tests
that are thus not entirely essential but worthwhile to have in here.
Checklist: