-
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
Parsing Issues with classic editor and php rendered blocks. #9968
Comments
Strange…thanks for reporting! I haven't tried reproducing with those steps yet but I tried adding a new test to the parser just to see what's happening and I think we'll need to dig in more to find out what's up. diff --git a/packages/block-serialization-default-parser/test/index.js b/packages/block-serialization-default-parser/test/index.js
index 68a46b39c..90eaf5cc9 100644
--- a/packages/block-serialization-default-parser/test/index.js
+++ b/packages/block-serialization-default-parser/test/index.js
@@ -24,4 +24,11 @@ describe( 'block-serialization-spec-parser', () => {
},
] );
} );
+
+ test( 'treats void blocks and empty blocks identically', () => {
+ const voidBlock = parse( '<!-- wp:block /-->' );
+ const emptyBlock = parse( '<!-- wp:block --><!-- /wp:block -->' );
+
+ expect( voidBlock ).toEqual( emptyBlock );
+ } );
} ); I'll check in later but maybe this has something to do with another oddity? @jrmd I'll try and reproduce later with the steps you added, but in the meantime if you could post here a copy of the test document that produced the error that would be helpful (for example, the minimal document showing the bug). Maybe there's something funny with newlines or whitespace… |
here is the entire post content to make this issue occur
|
I was able to reproduce this. You can also see in Code Editor mode that if you paste in the content @jrmd provided, the classic block content is immediately deleted. |
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.
Found it! this one was staring us down - I'm not sure why I missed it but the fix is simple. It was the case where we had leading HTML in front of a void block and we weren't pushing it to the output list. I've submitted a patch in #9984 and it's ready for review. If you are able to confirm that this fixes the problem for you that'd be awesome to have the additional confirmation. |
* 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.
* 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.
Describe the bug
in Gutenberg 3.8 where the classic editor doesnt show in the backend if a php rendered block is added just after the classic editor block.
It seems to be something to do with how the comments work. For example my php rendered block would be stored in the database like this:
<!-- wp:my-blocks/block-custom /-->
This causes the classic editor not to render, however if you change the comment to
<!-- wp:my-blocks/block-custom --><!-- /wp:my-blocks/block-custom -->
Everything will render in the editor correctly
Going back through the commits - it seems that it was caused by the new parser ( #8083 )
If my description you can see the conversation here in slack - https://wordpress.slack.com/archives/C02QB2JS7/p1537188435000100
To Reproduce
Steps to reproduce the behavior:
latest posts
block (its a php rendered block)Expected behavior
Classic editor should be visible
Additional context
The text was updated successfully, but these errors were encountered: