Page MenuHomePhabricator

Don't parse subst:#var before parsing other Variables functions on a page
Closed, DeclinedPublicBUG REPORT

Description

If you use subst on a parser function like #if, you geht the expected output. If you use subst:#var: instead of #var: for a variable defined before, you get no output at all.

This shouldn't be the case. Variables should behave analogous to ParserFunctions instead.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2018, 5:50 PM

There's a similar issue reported at the extension talk page.

I've used subst: with the Variables functions (not just #varspecifically) to create numberings for not-quite-ordered-lists (e.g. numbering table rows), and don't recall facing any problems. For these, my code is usually some variant of {{ subst:#vardefineecho: n | {{ subst:#expr: {{ subst:#var: n | 0 }} + 1 }} }}. OTOH, I've admittedly never tried systematically checking the behavior of the Variables functions when used with subst: in various situations.

I'll check the validity and extent of this issue next week.

Be sure to report the MediaWiki and Variables version you test with.

Weird, that it doesn't work for me:
https://test.pokewiki.de/Vorlage:Var

I'm using MW 1.30.0 and Variables 2.2.0.

https://yugipedia.com/wiki/User:Dinoguy1000/sandbox/var (MediaWiki 1.30.0, Variables 2.2.0; feel free to edit and play around with the code there, though if you do, note that we've been having issues with pagesaves timing out, even though the save does happen)

It seems the key is that you can't mix substitution and non-substitution; it's all-or-nothing. I've never tested how ParserFunctions and the like behave in the same scenarios, but it seems counterintuitive and thus probably worth fixing (even if I also can't come up with scenarios where you'd want or need to only substitute some of your Variable usage on a given page).

@thiemowmde Du you have some idea, where this might come from?

I'm not that much of an expert, but from all I know about the parser it works in two passes. Parser functions prefixed with subst: are processed in an earlier, entirely separate pass than then ones without.

The examples provided above are quite fascinating. Let's see:

In {{subst:#vardefineecho:a|1}} {{#var:a|2}} the substitution is done the moment you save the page, but everything else is not executed. Therefore the saved page contains 1 {{#var:a|2}}. When this is executed later, there is no variable "a" defined any more because it got substituted away. Therefore the default 2 is printed.

Similarly, when you save {{#vardefineecho:a|1}} {{subst:#var:a|2}} it becomes {{#vardefineecho:a|1}} 2 because the substitution pass did not executed the vardefine, as it was not marked for substitution.

To me this appears to be expected and well defined behavior. I would argue this is not a bug then, and there is not really anything that can be done to change this behavior.

MGChecker closed this task as Declined.Sep 1 2018, 8:01 PM

This is interesting, I didn't know about that. I guess this behavior doesn't really come into play if you aren't using extensions that are storing persistent data over a parse.

As the reason for this behavior is the way the MediaWiki parser is fundamentally working, I agree that this is a WONTFIX for now. If there is a fundamental change in the way the parser works (for example because of the work of the parser team to unify the core Parser and Parsoid), this might be reopened.

MGChecker renamed this task from Make subst:#var work to Don't parse subst:#var before parsing other Variables functions on a page.Sep 1 2018, 8:01 PM
MGChecker triaged this task as Lowest priority.
MGChecker changed the subtype of this task from "Task" to "Bug Report".Mar 1 2019, 11:36 PM