[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 flixos90):

 Replying to [comment:23 westonruter]:
 > That could work, but some things commonly done by caching plugins
 wouldn't be supported, like adding an HTML comment at the end of the
 response.

 There's ways to address this, such as providing specific extension points
 to add HTML comments before or after the output (this would only allow
 comments, not any HTML as that could easily break the response).

 > 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.

 > Going the opposite extreme, other applications may want to load the
 entire HTML document into the DOM (e.g. the AMP plugin), especially as PHP
 8.4's new `Dom\HTMLDocument` is fully HTML5 compliant, in order to do much
 more advanced mutations of the document.

 Sure, there are always cases for everything - but that doesn't mean they
 all should be encouraged by the APIs provided by Core.

 At the end of the day, plugin developers will do whatever they need to get
 the job done - whether Core's APIs support it or whether they need to work
 around it. If we have an API that allows anything, it avoids the need to
 work around it. But at the same time it's a wildcard where anyone can do
 whatever they want very easily, like even wipe the entire output.

 FWIW I'm just thinking out loud with my above ideas of multiple actions
 for specific integration points, there may be more elegant solutions. But
 I think for an API as powerful as this (for both good and bad), we need to
 have guardrails in place instead of just opening everything up - that sets
 us up for chaos. For some other APIs being less strict is not so bad, but
 this can alter the entire HTML output so it's a different level of risk.

 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.

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