TemplateStyles uses the page_props table to store its css. However, that table is updated independently of saving a page. It might also not have the right version, depending on parser altering user preferences. I think it would be better to just directly use $parser->getOutput()->addHeadItem(). This ensure's that the user always see's the version of the css that corresponds to the version of the page currently viewing, and if LinksUpdate is delayed (due to job queue issues), you don't get weird inconsistencies, or bad versions cached due to race conditions.
Description
Details
Subject | Repo | Branch | Lines /- | |
---|---|---|---|---|
Use wikimedia/css-sanitizer, and rewrite the hooking | mediawiki/extensions/TemplateStyles | master | 1 K -953 |
Event Timeline
I think it would be better to just directly use $parser->getOutput()->addHeadItem(). This ensure's that the user always see's the version of the css that corresponds to the version of the page currently viewing
It should use the version of the css that corresponds to the version of the page being used in the parser output (especially with regards to transclusions). Can we guarantee that somehow? So that whatever version is used as part of template expansion, is kept and then used for the templatestyles as well.
That is what using properties of the ParserOutput would do. (Provided that the extension abandoned the idea of putting the tag inside a <noinclude>).
On FlaggedRevs wikis the CSS from the stable version of the template needs to be shown on stable articles, which complicates the page_props approach even further. And then there is the issue of displaying old revisions of the template.
Change 346808 had a related patch set uploaded (by Anomie):
[mediawiki/extensions/TemplateStyles@master] Use wikimedia/css-sanitizer, and rewrite the hooking
Change 346808 merged by jenkins-bot:
[mediawiki/extensions/TemplateStyles@master] Use wikimedia/css-sanitizer, and rewrite the hooking