Needs proper reassessment of priority

Not sure why this needs triage now. It's a long standing broken part of the system, which should have been fixed a long time ago. If the foundation can't fix it in 14 years, and with, I suppose, about $1bn to spent, I despair of having anythung useful done. Certainly lowering the priority won't help, and raising it seems unlikely to either.

TOKEN FOR RICH!

@Rich_Farmbrough: Please bring up meta-level discussions on priorities or who should spend money on what in a better suited place. Also see https://www.mediawiki.org/wiki/Bug_management/Development_prioritization about prioritization and wrong expectations. Thanks for your understanding.

@Aklapper You refer @Rich_Farmbrough to https://www.mediawiki.org/wiki/Bug_management/Development_prioritization - but that's a very long essay with multiple claims. Which of them do you think applies to this bug?

"Hence there are many tasks which will stay unresolved forever. It is unrealistic to expect all tasks to ever get fixed.", perhaps?

Or perhaps Rich has seen it, and has noted that it suggests "sometimes the best bet is ... to convince someone else (maintainers, developers, external developers) to write that software patch."

More generally, please be specific, not vague, just as you enjoin others to be

@Pigsonthewing: I'm not sure if I get the question correctly, sorry... I replied to a comment mentioning "should have been a fixed long time ago" and "Priority".
Hence all of that page applies to this ticket, and for example also the two sentences that you quoted.

The whole page cannot apply, since the two quotes I gave involve mutually exclusive outcomes.

Here's another possible use case that is blocked by this bug.

This problem has just been raised again in a discussion at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Srich32977_and_FAITACCOMPLI where the subst'ed template "Format ISBN" is seen as a solution to a problem ... but does not, currently, work within <ref> tags. So I add my voice here to urge that this problem should be fixed ASAP for the benefit of readers and editors.

Change 981193 had a related patch set uploaded (by Thomas-topway-it; author: Thomas-topway-it):

[mediawiki/core@REL1_39] parsing of nested tabs with 'parse-wikitext' attribute, see phabricator T4700 and T3310

https://gerrit.wikimedia.org/r/981193

hello, I have created the following patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/981193 that may solve the issue without modifying the parser

see also https://phabricator.wikimedia.org/T3310
and https://wikisphere.org/wiki/Template:Page_upload
for more information (I will post a pure-mediawiki example soon)

Once resolved, please correct/remove the mention of the bug in the lede of Wikipedia:Substitution. Thank you!

Is this bug seriously twenty years old? Is there some reason we can't fix it?

@JPxG_: Hi, age of a ticket is always irrelevant - issues do not get more likely fixed only because they get older. You can find the creation data of this ticket under "Authored By" above. You can find reasons in the review of the latest patch mentioned in this ticket; if you'd like to see this or another issue fixed then please provide code changes for review. For general questions, please use https://www.mediawiki.org/wiki/Talk:Phabricator/Help . Thanks for your understanding.

In T4700#11063245, @JPxG_ wrote:

Is this bug seriously twenty years old? Is there some reason we can't fix it?

It's less a case of why can't we?, more a case of why hasn't it been?.

The first priority should be to pinpoint which part of the code is responsible for the problem. However, there aren't any notes here indicating what the root cause might be. While troubleshooting code is often easier than writing it from scratch, some direction is needed to proceed efficiently.

There have been previous attempts to resolve this issue, but unfortunately, those efforts were unsuccessful.

I just figured out that a unresolved long-standing issue affecting c:Commons:Photo_challenge is due this this bug from 2005. When we create new page for the monthly photo challenge we automatically preload it from Commons:Photo_challenge/preload page, where we set up a bunch of "subst:" commands to correctly fill most of the fields. All of those work except for couple of "{{subst:FULLPAGENAMEE}}" statements which for some reason never work. I was just experimenting with them and after long debugging session discovered that what prevent those from working are <gallery.</gallery> brackets. I wonder how many other volunteers waste their time rediscovering this 20 year old bug.

Hi. Just a question. Is this bug the reason why we at svwiki have to make updates like this every year, or is our problem solvable in some other way? Thanks!

In T4700#11490344, @Nirmos wrote:

Hi. Just a question. Is this bug the reason why we at svwiki have to make updates like this every year, or is our problem solvable in some other way? Thanks!

There is no bug, but expected behavior of pre wikitext tag which prevent any wikitext inside it. If you want to use {{CURRENTYEAR}} magic word, you should find another way to both indent and prevent wikitext. There are several options, here is one:

wikitext:
 == Nyval/Omval/Återval aktuell månad och år ==
 <<nowiki/>section begin="{{CURRENTYEAR}}"/>
 <<nowiki/>small>Valet bör inte avslutas före den {<nowiki/>{Byt:#timel: j F Y "kl". H.i (T) | +7 days}}.</small>
 {<nowiki/>{Byt:Nominering
 |användarnamn=
 |till= Administratör/Administratör och byråkrat/gränssnittsadministratör/IP-kontrollant
 |valtyp= Nyval/Omval/Återval
 |självnominerad= Ja/Nej
 |motivering= Varför ~~<nowiki/>~~
 |länk= Länk till kandidatens bekräftelse (utgår vid självnominering)
 }}
 <<nowiki/>section end="{{CURRENTYEAR}}"/>

If needed, please continue the discussion elsewhere (eventually pinging me) to avoid flooding with off-topic messages.

I'm not sure if it's been mentioned in detail, so here's what I've noticed. The bug is gone during editing via VisualEditor and appears after saving the edit.

1. Open English Wikipedia, e.g. 'User:ShabeTest/sandbox'.
2. Click 'Edit'. Make sure it's Visual editing and not Source editing.
3. Click 'Site'.
4. Click 'Manual'.
5. Click e.g. 'Website'.
6. Insert '{{subst:CURRENTYEAR}}-{{subst:CURRENTMONTH}}-{{subst:CURRENTDAY2}}' in the 'URL access date' parameter.
7. Insert 'title' in 'Title' and 'https://example.org' in 'URL' not to get any error that would interfere with the test.
8. Click 'Insert'.
9. You'll see the date looking normal! 😯
   
10. Click 'Publish changes' twice.
11. Alas, you'll see the bug ☹️
    

So VisualEditor seems to be doing something right. It uses the {{subst:}}'s properly even inside <ref>'s. But then something fails while saving the page.

Well, yeah, the error is in saving the page, and it's an error based on the order of operations. To fix this, we need to work out what the operations are, and change the order in which they're executed. So, what needs to be done is some code analysis to identify that.

Sorry if that is obvious, but I think it best to state the problem in the simplest way possible.