-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Fix using the classic block in nested contexts #16477
Conversation
@@ -280,9 +281,12 @@ export function serializeBlock( block ) { | |||
* Takes a block or set of blocks and returns the serialized post content. | |||
* | |||
* @param {Array} blocks Block(s) to serialize. | |||
* @param {Object} options Serialization options. |
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.
We should document these options. I think the "best" way would to define a JSDoc typedef of something like WPBlockSerializationOptions
with each property described. Unfortunately docgen
won't yet output these, but it seems prime for a future enhancement.
* | ||
* @return {string} Serialized block. | ||
*/ | ||
export function serializeBlock( block ) { | ||
export function serializeBlock( block, { isNested = false } = {} ) { |
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.
Nit: I think we should try to consolidate our vocabulary around "inner blocks". Do we have many other references of "nested" in code? I know there's a tendency to refer to them this way in casual conversation. Is isInnerBlock
reasonable as an alternative here?
switch ( blockName ) { | ||
case getFreeformContentHandlerName(): | ||
case getUnregisteredTypeHandlerName(): | ||
switch ( true ) { |
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.
At this point, I think we'd just not want to bother with a switch
and use if
instead. Alternatively, we could intentionally use fallthrough to allow the nested case to fall through to default
.
switch ( blockName ) {
case getUnregisteredTypeHandlerName():
return saveContent;
case getFreeformContentHandlerName():
if ( ! isNested ) {
return saveContent;
}
default: {
const blockType = getBlockType( blockName );
const saveAttributes = getCommentAttributes( blockType, block.attributes );
return getCommentDelimitedContent( blockName, saveAttributes, saveContent );
}
}
It's pretty confusing though. Maybe less-so if default
was just code following the switch
instead of a case, but still confusing I think.
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.
Pretty simple fix 👍
* | ||
* @return {string} Serialized block. | ||
*/ | ||
export function serializeBlock( block, { isNested = false } = {} ) { | ||
export function serializeBlock( block, { isInnerBlocks = false } = {} ) { |
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.
Should be singular isInnerBlock
?
Edit: Oh, I guess in the context that this is an option just passed along from serialize
which is for multiple blocks, it makes sense as written, unless we wanted to rename the option as it applies to the context of the singular block being serialized. I think that comes with its own confusion. I'll leave it to you to judge, but I'm fine either way.
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 I'd leave it as is.
At the root level, the classic block omits its delimiters in order to support posts written with alternative editors. In nested contexts though, the classic editor should be rendered with delimiters otherwise the parser won't be able to reparse the post properly.
closes #13187
Testing instructions