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

 Replying to [comment:22 flixos90]:
 > Replying to [comment:21 westonruter]:
 > > 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.
 >
 > That's what I covered with my note on having an action for the raw
 string, but not making it filterable, to discourage problematic patterns
 as mentioned.

 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.

 > > 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.
 >
 > Maybe I'm missing something. Can you clarify what do you mean by
 lighter-weight HTML Tag Processor? What class is that, compared to what
 other class?

 The HTML API has two classes:
 [https://developer.wordpress.org/reference/classes/wp_html_tag_processor/
 WP_HTML_Tag_Processor] and
 [https://developer.wordpress.org/reference/classes/wp_html_processor/
 WP_HTML_Processor]. The latter is a subclass of the former which adds
 awareness of all of HTML's complicated parsing rules. In many cases, the
 desired HTML processing can use `WP_HTML_Tag_Processor`, for example to
 iterate over to a given `IMG` tag to apply mutations. But to have full
 awareness of the //structure// of the tags in an HTML document, the more
 robust `WP_HTML_Processor` should be used. It is a superset and has more
 capabilities, but it should only be used if it is needed since it is more
 expensive to use. See @dmsnell's short summary in
 [https://make.wordpress.org/core/2024/06/24/updates-to-the-html-api-
 in-6-6/#:~:text=The%20Tag%20Processor%20was%20initially%20designed%20to%20jump%20from%20tag%20to%20tag%2C%20then%20it%20was%20refactored%20to%20allow%20scanning%20every%20kind%20of%20syntax%20token%20in%20an%20HTML%20document.%20Likewise%2C%20the%20HTML%20Processor%20was%20initially%20designed%20to%20jump%20from%20tag%20to%20tag%2C%20all%20the%20while%20also%20acknowledging%20the%20complex%20HTML%20parsing%20rules.
 Updates to the HTML API in 6.6]:

 "The Tag Processor was initially designed to jump from tag to tag, then it
 was refactored to allow scanning every kind of syntax token in an HTML
 document. Likewise, the HTML Processor was initially designed to jump from
 tag to tag, all the while also acknowledging the complex HTML parsing
 rules."

 > > 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.
 >
 > Couldn't this be handled by e.g. a decorator pattern? Alternatively, you
 mentioned it should eventually use the Core class anyway.

 Optimization Detective could eventually use the HTML Processor instead
 which should indeed eliminate most of the need for subclassing, but there
 are a couple capabilities blocking this:

 1. Insert HTML at an arbitrary point (e.g. in the `HEAD` and at the end of
 `BODY`).
 2. Obtain the node sibling index for breadcrumbs (e.g. this `DIV` is the
 4th element child).

 OD's subclass also introduces helper methods like `get_xpath()`,
 `set_meta_attribute()`, and `set_attribute()`/`remove_attribute()` are
 overridden to add meta attributes to indicate how the attributes were
 mutated.

 But also, other applications wouldn't need a tag processor at all, as I
 [https://core.trac.wordpress.org/ticket/43258#comment:17 mentioned above]
 with hoisting styles from the footer to `wp_head` (e.g. implemented be
 printing a placeholder comment that gets replaced in the output buffer).
 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.

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