[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:               |     Focuses:  docs, performance
-------------------------+--------------------------------

Comment (by westonruter):

 @flixos90 I know that @dmsnell has had similar thoughts in the past.
 However, there are use cases beyond just processing HTML. For example,
 caching plugins don't need to do any processing at all. They just need to
 capture the output buffer to put in the persistent object cache (for
 example) and maybe append an HTML comment to say that it was cached.

 Also, some applications on the output buffer would only need the lighter-
 weight HTML Tag Processor which doesn't have all of HTML's complicated
 parsing rules internalized, so such extensions shouldn't be required to
 use it. For example, Optimization Detective is mostly able to get by using
 the HTML Tag Processor by taking into account the most common HTML
 idiosyncrasies (e.g. being able to omit closing tags on `P` tags, although
 WP is pretty good about having tags balanced). But Optimization Detective
 would be eventually be better off using the HTML Processor so scenarios
 like missing closing `DIV` tags could be better handled. (Although in the
 end, the only impact is the XPath is not accurately computed, but it would
 still be stable to identify that tag regardless.) Note that Optimization
 Detective uses a subclass of `WP_HTML_Tag_Processor` so it wouldn't be
 able to use a single instance supplied by core anyway.

 Also, other use cases like I mentioned in the
 [https://core.trac.wordpress.org/ticket/43258#comment:17 previous comment]
 could be implemented without the use of the HTML API by instead injecting
 a placeholder into the `HEAD` and then replacing it in the output buffer.

 So I think adding a filter for the output buffer is the right approach,
 leaving the use of filter callbacks to decide how to process the HTML
 string.

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