[wp-trac] [WordPress Trac] #59443: Block Supports: Re-use instance of Tag Processor when adding layout classes

[WordPress Trac]

#59443: Block Supports: Re-use instance of Tag Processor when adding layout classes
---------------------------------------+----------------------------
 Reporter:  dmsnell                    |       Owner:  isabel_brison
     Type:  enhancement                |      Status:  reopened
 Priority:  normal                     |   Milestone:  6.4
Component:  Editor                     |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  gutenberg-merge has-patch  |     Focuses:  performance
---------------------------------------+----------------------------

Comment (by dmsnell):

 > WP_HTML_Tag_Processor is done on innner content in a while loop.

 @spacedmonkey are you referring to `do_blocks()` here? to which `while`
 loop are you referring?

 > A while loop is also used to next tag.

 this is normative within the HTML API; an unfortunate requirement to avoid
 breaking the HTML is to scan through it.

 >  I wonder if we could add some conditional logic to make sure that
 expressive function / class classes are avoid, I think that would be
 helpful for performance.

 absolutely true, but it would also be good to remember why these are in
 place. the expressive functions are not the goal, but a happy side-effect
 of building a safe system. the motivation for and guiding principles of
 the HTML API are eliminating the security vulnerabilities and data
 corruption that have plagued WordPress for the past couple decades, and
 which are continually added in new code.

 if we can find a way to avoid processing HTML that would be even better;
 until then, there's a tradeoff between moving faster and avoiding
 breakage.

 I do agree that this function could use some help; particularly the bit
 where it tries to find an inner-block wrapping element, since that's not
 only non-deterministic here, but it's not guaranteed in any way to be
 correct, which is something I tried to note in this refactor (which itself
 was motivated by things you are raising: before the refactor we had some
 superfluous instantiation of the class and needless re-parsing and
 iteration).

 I'm not sure of any immediate solutions, but it does seem like we could
 find a way to communicate when we're entering and existing the render of
 inner blocks, and that would eliminate the need to search for a fuzzy
 target the way this is.

 Thanks for your continued measurements and sharing. Have you compared this
 performance against the revert of this patch yet?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59443#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform