[wp-trac] [WordPress Trac] #43258: Output buffer template rendering and add filter for post-processing (e.g. caching, optimization)

[WordPress Trac]

#43258: Output buffer template rendering and add filter for post-processing (e.g.
caching, optimization)
-------------------------+--------------------------------
 Reporter:  nextendweb   |       Owner:  westonruter
     Type:  enhancement  |      Status:  accepted
 Priority:  normal       |   Milestone:  6.8
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  docs, performance
-------------------------+--------------------------------

Comment (by westonruter):

 Replying to [comment:26 DaanvandenBergh]:
 > > I think at the very least, we shouldn't allow filtering the string,
 but modifications should go through an actual API where WordPress Core
 retains central control over the output. For example there could be a new
 class that receives the HTML string and provides methods to modify it
 (e.g. through one of the HTML tag processor classes or in other ways), and
 that class instance could be made available through an action.
 >
 > Allowing the string to be filtered, would make the lives of us,
 developers of optimization or slider plugins, easier as there's only one
 point of entry and therefore, one point of error. Right now, we often need
 to implement compatibility fixes because one plugin's buffer conflicts
 with another.
 >
 > As for the part about using Regex to manipulate the HTML; that's because
 of the point that @westonruter already mentioned: DOMDocument currently
 doesn't handle HTML5 properly, and since we need to be backwards
 compatible back to 7.2 (if we follow WP Core's example) we can't even use
 PHP 8.4 DOM\HTMLDocument for the next several years (until WP drops
 support for PHP 8.3). In short, currently using a regex is the most
 reliable (and faster) way to manipulate HTML.

 Regular expressions aren't reliable actually. This is why
 `WP_HTML_Tag_Processor` and `WP_HTML_Processor` were introduced in core as
 part of the HTML API starting in WP 6.2. I strongly recommend you look at
 switching. See [https://make.wordpress.org/core/tag/html-api/ posts tagged
 html-api] for more details.

 If the output buffer is filterable as a string, the filter documentation
 should heavily discourage the use of regex to parse the output in favor of
 the HTML API.

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