Parser: Parse superfluous classes as custom classes#7538
Conversation
|
Correct if I'm wrong but we're still persisting the custom className in the comment of blocks. I wonder if it's possible to drop it entirely from there with this new filter. I'm thinking of this extra filter as a way to define custom "source" in the block parser. |
It may be possible, yes, though I'm actually motivated to not allow for custom sources, particularly with how it impacts the viability of ever being able to parse blocks from the server. The current set of supported sources could be recreated on the server; if we allow for custom sources, not so much. |
youknowriad
left a comment
There was a problem hiding this comment.
LGTM 👍
I think I'd prefered to drop the className comment attribute entirely but I'm fine with this too.
|
|
||
| return blockAttributes; | ||
| return applyFilters( | ||
| 'blocks.getBlockAttributes', |
There was a problem hiding this comment.
Do we want to document this or keep it "secret" for now :)
There was a problem hiding this comment.
Do we want to document this or keep it "secret" for now :)
I'm fine to document. Will add.
| if ( filteredClassName ) { | ||
| blockAttributes.className = filteredClassName; | ||
| } else { | ||
| delete blockAttributes.className; |
There was a problem hiding this comment.
I'm not certain why we're deleting the className attribute in this case? This creates this bug #9991. Can you clarify a bit?
There was a problem hiding this comment.
Oh actually the filsterClassName variable have been removed at some point which is causing the bug.
|
Hi, this seems to have been broken in the upgrade from WP 5.8 to 5.9. Now custom classes on HTML content are being dropped again when converting to blocks using the rawHandler. Anyone else seeing this? |
Closes #5028
Maybe addresses #6826 (?)
Related: aduth/hpq#2
This pull request seeks to enable a block which supports
customClassName(defaulttrue) to inherit as part of itsclassNameattribute any classes which the user has added manually. This avoids a block being marked as having been modified externally, and further treats the extra classes the same as any other custom class (specifically in exposing by its Inspector > Advanced > Additional CSS Class).Implementation notes:
This adds a new filter on the parsed block attributes, determining if there is a difference between how classes were parsed and what was received as original markup of the block.
Noting that there is some relation between this and aduth/hpq#2 , particularly in how we retrieve the class attribute from the root element of the markup. Currently this requires adding a dummy wrapper node. The changes proposed in aduth/hpq#2 may still be in our interest to explore, but would be a significant breaking change affecting a large number of existing blocks. At this point, we may just want to be content with the current behavior, despite its drawbacks.
Testing instructions:
Verify that adding a class to a block which supports custom class names (e.g. paragraph) via the block menu's Edit as HTML view does not invalidate the block, is persisted between editor sessions, and is displayed in its Additional CSS Class advanced inspector field.