[wp-trac] [WordPress Trac] #45312: parse_blocks return non-existing empty blocks
WordPress Trac
noreply at wordpress.org
Wed Dec 5 19:31:06 UTC 2018
#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
More information about the wp-trac
mailing list