[wp-trac] [WordPress Trac] #45312: parse_blocks return non-existing empty blocks

[WordPress Trac]

#45312: parse_blocks return non-existing empty blocks
--------------------------+------------------------------
 Reporter:  Chouby        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  5.0
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by dmsnell):

 @birgire thanks for the response; it's accurate.

 @Chouby we're seeing a smashing of abstraction layers here. the `\n\n`
 freeform segments exist in the string `post_content` so they in a sense of
 reality are truly there. The biggest surprise is that the visual editor
 doesn't show them and it won't let you get rid of them in the underlying
 content…

 [[Image(https://cldup.com/lw06BVN1B8.gif)]]

 …while the parsed response has them…

 {{{#!js
 [
   {
     "blockName": "core/paragraph",
     "attrs": {},
     "innerBlocks": [],
     "innerHTML": "\n<p>One explicit block.</p>\n",
     "innerContent": [
       "\n<p>One explicit block.</p>\n"
     ]
   },
   {
     "blockName": null,
     "attrs": {},
     "innerBlocks": [],
     "innerHTML": "\n\n",
     "innerContent": [
       "\n\n"
     ]
   },
   {
     "blockName": "core/paragraph",
     "attrs": {},
     "innerBlocks": [],
     "innerHTML": "\n<p>Two explicit blocks.</p>\n",
     "innerContent": [
       "\n<p>Two explicit blocks.</p>\n"
     ]
   }
 ]
 }}}

 Right now I believe that the editor is actually manually filtering the
 returned blocks and
 [https://github.com/WordPress/gutenberg/blob/a3785cd15bcfaa17df20f7a6afc74d9254fe2c47/packages/blocks/src/api/parser.js#L449
 skipping them] if they are empty after `autop( innerHTML ).trim()`. This
 adds to the confusion because they are ripped from the document then
 implicitly recreated on serialization when the post undergoes HTML
 prettifying.

 There are many different ways I'm thinking about this in my head on what's
 really wrong here or how we should resolve this. From the parser's
 perspective there is no problem - we decided that anything that //isn't//
 a block is freeform content and that's why they are there.

 Could you help out and clarify what issues specifically this is causing
 you if it's breaking something? Are you noting here because something is
 difficult to interact with or mainly because it was surprising?

 Thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45312#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform