Page MenuHomePhabricator

PreSaveTransform (~~~~, subst: etc) is done on JavaScript and CSS content models
Open, MediumPublic

Description

Like in title.


Version: 1.23.0
Severity: normal

Details

Reference
bz59616

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:42 AM
bzimport set Reference to bz59616.
bzimport added a subscriber: Unknown Object (MLST).

maybe preSaveTransform was kept for backward compatibilty

You can change this with $wgTextModelsToParse

I think this behaviour is intentional for js/css content models. People were using subst: on js/css pages

I'm unsure if this bug should be fixed. It is hacky to do pst on js/css but people seem to rely on it.

Bawolff renamed this task from ParserFunctions (like ~~~~ sign) processing is enabled on different content model page (js, css), it shouldn't to PreSaveTransform (~~~~, subst: etc) is done on JavaScript and CSS content models.Sep 9 2016, 4:24 AM
Bawolff set Security to None.

For reference and context, there's two old tickets about parsing of JS/CSS pages (or not), see T34858: Do not parse .js/.css pages and save their parsed content in database tables and T43155: [Regression] ContentHandler should not disable parsing of .js/.css wiki pages. Oh, and there's also T18683: User CSS/JS should not be parsed for link tables without rendering. Fun.

Which text types are parsed es wikitext to extract categories etc is controlled by $wgTextModelsToParse:

/**
 * Determines which types of text are parsed as wikitext. This does not imply that these kinds
 * of texts are also rendered as wikitext, it only means that links, magic words, etc will have
 * the effect on the database they would have on a wikitext page.
 *
 * @todo On the long run, it would be nice to put categories etc into a separate structure,
 * or at least parse only the contents of comments in the scripts.
 *
 * @since 1.21
 */
$wgTextModelsToParse = [
	CONTENT_MODEL_WIKITEXT, // Just for completeness, wikitext will always be parsed.
	CONTENT_MODEL_JAVASCRIPT, // Make categories etc work, people put them into comments.
	CONTENT_MODEL_CSS, // Make categories etc work, people put them into comments.
];

This was introduced by commit 8b568be5e2dfb889e1eeedbdca50b304864174f7: Record links on CSS/JS pages in the DB. ContentHandler removed wikitext parsing for CSS and JS pages. However, people seem to rely on links and categories embedded in script comments.

For the record, I'm all for removing wikitext pst for JS and CSS (and everything except wikitext). But ContentHandler::preSaveTransform should still be called for all kinds of content - it should just do nothing for most kinds of content.

Please note that even PST in JS models is (ab-)used. E.g. https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups says: "Other installation method: add {{subst:navpop}} to your current skin's .js page. See below for full installation instructions." And look how many wikis have the same template
https://en.wikipedia.org/wiki/Template:Navpop Or https://en.wikipedia.org/wiki/Template:Js Or https://en.wikipedia.org/wiki/Template:Install_user_script

IMHO this isn't a reason not to deprecate wikitext PST for JS content model, but it will require quite a long transition period to fix all those documentation.

@Schnark Thanks for finding examples. Yes, I think you are right.

At some point, we could perhaps disable PST, and have special code that replaces {{subst:xyz}} with /* SUBSTITUTION IN JAVASCRIPT IS DISABLED, SEE .... */

This is bitting us again for other reasons.

Because wikitext is parsed on JS/CSS pages, it was common back in the day to surround the code inside <pre></pre> or <source></source> tags inside comments.

Now <source> tags are deprecated syntax, and pages using them are automatically placed in Category:Pages using deprecated source tags. Normal admins can't edit user scripts, so most of those pages won't be cleared in a while... until the deprecated syntax is deleted from MediaWiki code and some cleanup/migration script is run on those pages, causing a reparse and save, and bringing up T236828 again...

See https://www.mediawiki.org/wiki/Topic:Wm3we36bpjqh4zur