[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:25 flixos90]:
 > > 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.
 >
 > Thanks for clarifying the differences. If we wanted to make this
 possible, we could run two action hooks, one for each. Then extenders can
 choose what works best for their purpose, yet still the API wouldn't allow
 them to go for problematic patterns like regexes.

 As seen in my examples,
 [https://gist.github.com/westonruter/99af37489334927aaf04a46eaf2a11eb
 Always Load Block Styles on Demand] and
 [https://gist.github.com/westonruter/f9e67442c674c3176b95cd1ed0e784c1
 Always Print Script Modules in Head], certain optimizations don't need the
 overhead of a tag processor. If, for example, an HTML comment placeholder
 is printed at `wp_head` then this can be processed with a simple string
 replacement (//not// regex).

 There's also the issue of being able to use extended processor subclasses.
 If core only allowed you to use either `WP_HTML_Tag_Processor` or
 `WP_HTML_Processor` specifically, then if a plugin wanted to instead use a
 subclass of either then they wouldn't be able to.

 I think the output buffer string should be filterble, with documentation
 that advises against the use of regex, but at the same time doesn't
 somehow prevent it. If the API is too restrictive, developers will just
 resort to doing their own output buffering as they are today (as mentioned
 by you and @OptimizingMatters). WordPress isn't in full control of the
 output today anyway, and without having a central core-supported filter
 for the output-buffered there is extreme fragmentation with how plugins
 handle output buffer processing. By having a single output buffer and
 filter, there can be more consistency in how output buffering is handled.

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