Page MenuHomePhabricator

Provide means for Content model to tweak ParserOptions
Open, Needs TriagePublic

Description

There are a few cases where the content model wants to tweak parser options. These are both handled in includes/page/WikiPage.php right now, but as a huge & ugly hack:

  • LanguageConverter "conversion tables" should have content conversion disabled on them, so that they are viewable. There's a comment in WikiPage that was "ConversionTable should become a separate content model, so we don't need special cases like this one" but (as the title of this bug lays out) that wouldn't by itself help, because there's no current way for a ContentModel to tweak the ParserOptions used either.
  • JavaScript and CSS want to be "parsed as wikitext" so that categories and PST expansions work, among other features (magic words, links will add the page to "what links here", etc) but do *not* want to actually /render/ as wikitext. Since they are not actually wikitext, they don't want a ToC generated either (T307691) just because they might happen to have == or <h2> embedded somewhere. ToC is suppressed by setting ParserOptions::setSuppressTOC() but this *ought* to happen in the ContentModel somewhere/somehow, not by a WikiPage hack.

As @daniel says, "the actual solution would be to allow Contenthandler to use different (or cloned and adjusted) parser options for the 'fake parse'" -- although the Conversion Table case is slightly different, since it's not really a "fake parse" in that case.

See also T267067: Make language variant a parser option

Event Timeline

I don't think ParserOptions should be tweaked based on a page's (or slot's) content model. The interpretation and use of ParserOptions depends on the content model, the options themselves should be based solely on what the caller wants to get, without requiring the caller to know about the content model in advance.

In particular, when the caller requests HTML for a page that has mutliple slots, they pass only one ParserOptions object, and the same options will have to work for all slots.

I think conversion table pages should have their own content model. When generating HTML, the ConversionTableContentHandler would tell Parser to not apply conversion. Only if the Parser instance is instructed to apply conversion should it look at getDisableContentConversion() in the parser options. Conversion should be applied only if the ContentHandler and the top level caller both agree that they want conversion to be applied. If content conversion is enabled in ParserOptions, but the ContentHandler doesn't support it, then the option should remain unused.