Compat: Support unwrapped paragraph text via deprecation#4874
Conversation
| }, | ||
| }, | ||
| save( { attributes } ) { | ||
| return attributes.content; |
There was a problem hiding this comment.
Interesting, the issue I see about this is that anything (any HTML) could be considered a valid paragraph block
There was a problem hiding this comment.
Interesting, the issue I see about this is that anything (any HTML) could be considered a valid paragraph block
Wouldn't it only be tried for the paragraph blocks, since it happens during the parse step for the individual block?
There was a problem hiding this comment.
Yes, that's true but if I tweak the paragraph block with any markup (say in a code editor, I add an image), this markup will be upgraded and shown in the editor. I don't know if we want to fix this or consider it a rare edge case
There was a problem hiding this comment.
Yes, that's true but if I tweak the paragraph block with any markup (say in a code editor, I add an image), this markup will be upgraded and shown in the editor. I don't know if we want to fix this or consider it a rare edge case
Hmm, that's a good point. If we cared to, we could filter the HTML allowed here. Is this something the raw handler would be well-suited for, @iseulde ?
There was a problem hiding this comment.
Could an example be given here? Not sure I follow entirely. A few weeks ago I was thinking to add the valid_elements TinyMCE filter to only include the formatting we allow and if multiline the tag + formatting. This could then be enforced on setting initial content. This whitelist could also be shared with raw handling.
There was a problem hiding this comment.
I think this is ok, you currently can write plenty of HTML within the paragraph content if you want so, and that is not really different.
There was a problem hiding this comment.
mmm that's true, I guess we need to fix this separately if we ever want to then. (Maybe apply a filter in the save function which would invalidate the block)
There was a problem hiding this comment.
Yes, this seems like another layer of refinement that we might want to explore separately. But not even sure we should care too much about it.
|
I'm assuming here that the issue is the following: someone edits the block as HTML, remove the "main" tag ( |
|
@iseulde it's not so much about removing the Also what @aduth mentioned about external editors running their replacep for compat purposes increasing the likelihood of messing with the paragraph content. That's not true on the same level for headings, etc, so I think we can draw a line there. That said, for sources that have a single value, it might be interesting to explore a general solution where plain-text or the source attr are both matched. |
|
This looks 👍 from me. |
|
I've tested and it solves the issue, thank you! This was my hope for #4813 It is kinda cool that you can see the P tags get auto added when editor loses focus switching between Visual/Code editor modes. The minor concern would be if a user for some reason wants a block of text without P tags - but that can easily be made with custom HTML block, and not a paragraph. |
aduth
force-pushed
the
update/p-deprecated-repair
branch
from
bd72c3b to
54802d9
Compare
5 participants
Closes #589
Related: #589, #3922
This pull request seeks to enhance the paragraph block to accommodate technically-broken-but-common markup of text without a paragraph tag wrapper.
Specifically, this can assist in cases where:
removepbehavior and strips paragraph tags from the inner contents of<!-- wp:paragraph -->blocksImplementation notes:
The approach here
abusesuses the block deprecation pattern to consider an unwrapped paragraph as deprecated, even though it was never truly a supported implementation. The idea is that we anticipate the block invalidation and repair it to its supported equivalent.Testing instructions: