A module changes every page, in the order the modules were registered, through four hook traits #1269

The problem

A module changes a page through four hook traits, IntegrationAttributeRewriter, IntegrationScriptRewriter, IntegrationHtmlStreamProcessorFactory and IntegrationHeadInjector. Every hook of a selected module runs on every page, in the one order the modules were registered in. A publisher cannot run a change on part of a site, cannot choose the order, and cannot keep two changes of one module apart. Whether a hook's output may be stored in a template every reader shares rests on what the hook says about itself.

The change

A module changes a page through a middleware, which is one page change the module supplies under a name, and in no other way. A middleware runs only where an ordered entry of the settings names it.

[[fetch]]
media_type = "text/html"
path = "/news/"
middleware = ["tag.example.cleanup", "tag.example"]

[[serve]]
media_type = "text/html"
middleware = ["tag.example.reader"]

A page takes the first entry that covers it. An entry places a middleware, which is to say it names the middleware together with the media type and the path it runs on, and the entry's position among the entries is its order. An entry switches nothing on, because the section that selects a module still decides whether it runs. The fetch phase runs on the page as the origin sent it, and its output may be stored in a shared template. The serve phase runs on each reader's copy, is told about the reader, and is never stored. What a request left reaches a page through the serve entry alone, which makes the rule in section 3.7 of the seam design (#1084) structural.

A middleware is asked once for each document and answers with any of head markup, markup after the script bundle, element handlers, text handlers and a stream processor. Every module that changed a page is converted, core's script proxy included, and the four hook traits are removed. Twenty implementations become thirteen middleware. A deployment that selects a module and writes no entry gets no page change from it, and startup names each middleware no entry names. The example configuration and ts audit generate write the entries for the stock modules in the order their hooks ran.

Recording each module's page before converting it found two faults that are on main too. A rewritten inline script was written back with &, < and > escaped, which a browser does not decode inside <script>, and the Google Tag Manager module could send part of a script's text out of order. Both are fixed in the first commits, which stand on their own.

Where it is

Draft on the fork, jwrosewell#5, on top of the inspection endpoints (fork pull request 4). The text of section 3.7 is brought to what was built, where a middleware is named by its module's name with a part of its own after it, reads its module's own settings table, has a fifth part, converts twenty implementations with two in the serve phase, and puts serve markup straight before the script bundle.