-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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: Normalize data types and fix default implementation #10107
Conversation
cab05fe
to
6a48131
Compare
6a48131
to
8800237
Compare
8800237
to
335f5b9
Compare
Thanks for working on this. My thoughts:
*: By late I don't mean that we can't ever circle back to this, but rather that at this stage when we're so close to 5.0 I'd really rather focus on other pieces, and we could have another look at this in a post-5.0 cycle. |
335f5b9
to
783adcb
Compare
Resolves #10041 Resolves #10047 A few inconsistencies have remained in the grammar specification concerning freeform blocks and blocks without attributes in the block delimiters. Freeform blocks were returned without block names and blocks without attributes returned `null` instead of an empty set of attributes. Further, the default parser implementation (from #8083) was returning an array of block objects instead of an array of generic arrays. This resulted in mismatches in PHP of accessing properties with `$block[ 'attrs' ]` syntax vs `$block->attrs` syntax. In this patch I've updatd the specification to remove all of the type ambiguity and have updated the default parser to match it. After this patch every block should be accessible as a normal array in PHP and have all properties: `blockName`, `attrs`, `innerBlocks`, and `innerHTML`. If no attributes are specified then `attrs` will be an empty set (in JavaScript `{}` and in PHP `array()`).
c2cc5bc
to
1b686b6
Compare
@dmsnell, I've shrunk the scope of this to exclude the introduction of |
b18e94e
to
25d31ca
Compare
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.
❤️
Resolves #10041
Resolves #10047
A few inconsistencies have remained in the grammar specification
concerning freeform blocks and blocks without attributes in the
block delimiters. Freeform blocks were returned without block
names and blocks without attributes returned
null
instead ofan empty set of attributes.
Further, the default parser implementation (from #8083) was
returning an array of block objects instead of an array of
generic arrays. This resulted in mismatches in PHP of accessing
properties with
$block[ 'attrs' ]
syntax vs$block->attrs
syntax.
In this patch I've updatd the specification to remove all of
the type ambiguity and have updated the default parser to match
it. After this patch every block should be accessible as a normal
array in PHP and have all properties:
blockName
,attrs
,innerBlocks
, andinnerHTML
. If no attributes are specifiedthen
attrs
will be an empty set (in JavaScript{}
and inPHP
array()
).Status
I haven't tested this yet. I'd like some feedback on the design change
though. My plan is to run the tests through the parser comparator and
make sure that the spec and the default parsers remain consistent.
If you look at the automated test results you can see what the impact is
of making HTML soup turn implicitly into a freeform block. I'd appreciate
some feedback on what you think of that. Personally I think it's a reasonable
change: at the time we didn't do that we weren't as sure of what would
happen with the "HTML soup" but it seems like we've locked down the idea
of the classic block which is
core/freeform
- maybe I'm wrong 🤷♂️Checklist: