Provide a recursive subst: function in the PST – {{substall:foo}}
OpenPublic

Description

Author: gangleri

Description:
Hallo!

at FiverAlpha "Template:This_version" is a nested template containing
{{this_version/version}}   {{this_version/installed}}  
{{this_version/last_update}}<br />
because the content of "Template:This_version/installed",
"Template:This_version/version" and "Template:This_version/last_update" is used
in another context two.

{{subst:this_version}} will generate
{{this_version/version}} &nbsp; {{this_version/installed}} &nbsp;
{{this_version/last_update}}<br />

*The requested:* {{subst:this_version}} should be equivalent to
{{subst:this_version/version}} &nbsp; {{subst:this_version/installed}} &nbsp;
{{subst:this_version/last_update}}<br />
in this particular example. This would be used to reference to the configuration
valid at a certain time.

As a general request *{{substall:foo}}* should make a general substitution at
*all* levels. It should be possible to the user to use either {{substall:foo}}
*or* {{subst:bar}} depending on the context and of the used templates.

Best regards Reinhardt [[user:gangleri]]


Version: unspecified
Severity: enhancement
URL: http://test.leuksman.com/index.php?title=Template:This_version&action=edit

bzimport added a project: MediaWiki-Parser.Via ConduitNov 21 2014, 8:39 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz2777.
bzimport created this task.Via LegacyJul 9 2005, 5:20 PM
bzimport added a comment.Via ConduitApr 16 2006, 11:25 AM

gangleri wrote:

Another example is at [[id:template_talk:Userbox]] where double substitution was
required to see / understand the code.

{{substall:foo}} would realy help to save some time.

bzimport added a comment.Via ConduitApr 29 2006, 8:48 AM

ligulem wrote:

Templates that use [[m:ParserFunctions]] would benefit a lot from
{{substall:...}}, as with subst, #if & Co. are not evaluated and inserted
verbatim into the subst target location. See for example [[en:template:afd]]
which is regularly substed on a lot of pages. Another example is
[[en:template:cite book]] which leaves an unmaintainable mess of #if constructs
when users subst that.

OTOH it might be possible to just "subst" #if & Co without the introduction of
that new "substall". It makes not that much sense to insert a #if into the subst
target location if that could be eliminated entirely (i.e. optimized away at
subst time).

bzimport added a comment.Via ConduitMay 1 2006, 3:54 AM

ayg wrote:

I would suggest that {{subst:subst:...subst:This version}} would be a better way
to format it. It gives the user more control.

Either way, it makes sense that if Parserfunctions aren't dealing with variables
(e.g., {{CURRENTYEAR}}), they should subst automatically when their including
template is substed.

bzimport added a comment.Via ConduitMay 1 2006, 1:29 PM

omniplex wrote:

Apparently "substall" could work for "switch" and "ifdef", but not "ifndef" (and
therefore also not "qif"). I'm not sure about "#if:", see [[mediazilla:5678]].

bzimport added a comment.Via ConduitMay 1 2006, 3:30 PM

ligulem wrote:

(In reply to comment #4)

Apparently "substall" could work for "switch" and "ifdef", but not "ifndef" (and

therefore also not "qif"). I'm not sure about "#if:", see [[mediazilla:5678]].

Could you give an example that would prove your claim about [[en:template:qif]]? Why
should substall not work for "#if:"? If I feed constants into templates, then these are
also fed into #if: et al. So all expressions are known and can be evaluated and thus can
be replaced with their results. Example: "{{subst:#if:bla|green|blue}}" *is* replaced
with "green" and "{{subastall:#if:bla|{{#if:|yellow|pink}}}}" *could* be replaced
with "pink".

alerante added a comment.Via ConduitMay 1 2006, 7:54 PM

nospam+wikimedia wrote:

(In reply to comment #3)

I would suggest that {{subst:subst:...subst:This version}} would be a better way
to format it. It gives the user more control.

That would require too much knowledge of how the template works. It would be a nice feature in addition to
{{substall:}}, though.

Either way, it makes sense that if Parserfunctions aren't dealing with variables
(e.g., {{CURRENTYEAR}}), they should subst automatically when their including
template is substed.

Variables are also capable of being subst'd. Anything subst'd is generally expected to remain constant, so
not subst'ing variables is not that great of an idea in my opinion.

bzimport added a comment.Via ConduitMay 1 2006, 8:26 PM

ayg wrote:

(In reply to comment #6)

Anything subst'd is generally expected to remain constant

Not necessarily. If, for instance, I subst a template containing something like
"All works first published in the United States whose authors died before
{{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to
update. It wouldn't update anyway unless the page's cache were cleared, and it
might be better as a matter of policy to transclude, but you can't make the
assumptions that people would never want to do something like that.

If the argument is constant, however, you'd always want to just print the
result, unless you intend to modify the argument or conditional after editing
(which is probably a rare enough case that it can be put aside; almost always in
such a case you could edit the result as easily as the function itself).

bzimport added a comment.Via ConduitMay 1 2006, 8:28 PM

ayg wrote:

(In reply to comment #7)

(In reply to comment #6)
> Anything subst'd is generally expected to remain constant

Not necessarily. If, for instance, I subst a template containing something like
"All works first published in the United States whose authors died before
{{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to
update. It wouldn't update anyway unless the page's cache were cleared, and it
might be better as a matter of policy to transclude, but you can't make the
assumptions that people would never want to do something like that.

If the argument is constant, however, you'd always want to just print the
result, unless you intend to modify the argument or conditional after editing
(which is probably a rare enough case that it can be put aside; almost always in
such a case you could edit the result as easily as the function itself).

(In reply to comment #7)

(In reply to comment #6)
> Anything subst'd is generally expected to remain constant

Not necessarily. If, for instance, I subst a template containing something like
"All works first published in the United States whose authors died before
{{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to
update. It wouldn't update anyway unless the page's cache were cleared, and it
might be better as a matter of policy to transclude, but you can't make the
assumptions that people would never want to do something like that.

If the argument is constant, however, you'd always want to just print the
result, unless you intend to modify the argument or conditional after editing
(which is probably a rare enough case that it can be put aside; almost always in
such a case you could edit the result as easily as the function itself).

(In reply to comment #7)

(In reply to comment #6)
> Anything subst'd is generally expected to remain constant

Not necessarily. If, for instance, I subst a template containing something like
"All works first published in the United States whose authors died before
{{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to
update. It wouldn't update anyway unless the page's cache were cleared, and it
might be better as a matter of policy to transclude, but you can't make the
assumptions that people would never want to do something like that.

If the argument is constant, however, you'd always want to just print the
result, unless you intend to modify the argument or conditional after editing
(which is probably a rare enough case that it can be put aside; almost always in
such a case you could edit the result as easily as the function itself).

Of course, I don't mean to say that {{substall:foo}} or {{subst:subst:...foo}}
shouldn't subst variables. I'm saying that {{subst:foo}} should *not*
automatically subst all variables within the substed text, but it probably
*should* subst all parserfunctions in the substed text that have constant articles.

bzimport added a comment.Via ConduitJun 29 2006, 3:54 PM

omniplex wrote:

The "optional recursive substitution" explained on
[[Help:Substitution]] (use the Meta version) can
emulate "substall" in some cases where it doesn't
collide with [[mediazilla:5678]]. It's tricky, for
a good solution 2777 might depend on 5678.

bzimport added a comment.Via ConduitJul 6 2006, 9:40 AM

tran.gabriel wrote:

The "optional recursive substitution" explained on
[[Help:Substitution]] (use the Meta version) can
emulate "substall" in some cases where it doesn't
collide with [[mediazilla:5678]]. It's tricky, for
a good solution 2777 might depend on 5678.

I'm afraid this solution is not good enough, as we need to modify a lot of
templates. Plus, if the substall is coded, we'll have to revert those templates.
I hope you guys can make it.

bzimport added a comment.Via ConduitNov 30 2006, 3:12 AM

ayg wrote:

*** Bug 8081 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitDec 22 2006, 2:12 AM

robchur wrote:

You can now use the ExpandTemplates extension to perform the requested recursive
substitution.

bzimport added a comment.Via ConduitApr 1 2007, 4:40 PM

robchur wrote:

*** Bug 9470 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitApr 1 2007, 4:48 PM

robchur wrote:

*** Bug 9470 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitApr 8 2007, 7:37 AM

robchur wrote:

*** Bug 9499 has been marked as a duplicate of this bug. ***

Sj added a comment.Via ConduitJan 30 2008, 7:06 AM

See also #2003, which would make resolving this bug much easier.

demon added a comment.Via ConduitJul 26 2008, 3:00 AM

Extension:SubstAll committed in r38054

bzimport added a comment.Via ConduitDec 23 2009, 2:02 AM

gangleri wrote:

Dear friends;

innocentkiller has marked this bug as fixed : https://bugzilla.wikimedia.org/show_activity.cgi?id=2777

[[testwiki:template:bugzilla/002777]] shows that there is no {{substall:foo}} beside {{subst:bar}} .

Please provide some syntax exmples about the usage at WikiMedia Foundation wikis.

Thanks in advance! REOPENing this bug.

refference link:
http://www.mediawiki.org/w/index.php?title=Special%3ASearch&search=SubstAll&fulltext=Search

Catrope added a comment.Via ConduitDec 23 2009, 12:51 PM

(In reply to comment #18)

Dear friends;

innocentkiller has marked this bug as fixed :
https://bugzilla.wikimedia.org/show_activity.cgi?id=2777

[[testwiki:template:bugzilla/002777]] shows that there is no {{substall:foo}}
beside {{subst:bar}} .

Please provide some syntax exmples about the usage at WikiMedia Foundation
wikis.

Thanks in advance! REOPENing this bug.

He closed the bug because he wrote an extension that provides {{substall:}}. If you want this extension to be enabled on Wikimedia wikis, file a separate bug for that. Reclosing.

demon added a comment.Via ConduitJan 27 2010, 7:03 PM

I don't know why I ever thought that was a viable solution, deleted the extension in r61588. Should be done (if at all) as part of PST, not some crappy hook on ArticleSave.

REOPENING.

bzimport added a comment.Via ConduitApr 2 2010, 12:15 AM

svippy wrote:

Drop the idea of {{substall:}} and introduce {{substthis:}} instead. That would allow you to specify what templates inside a template should be be subst'ed when subst'ed, otherwise, do not subst.

Why? Imagine you having a template inside this template situation that you do NOT wish to subst. That would make this feat pointless, this is a much better solution.

bzimport added a comment.Via ConduitApr 2 2010, 2:26 AM

conrad.irwin wrote:

A (hacky) patch

I've attached a patch showing how it might be possible to implement this currently. This patch is NOT well tested, and NOT complete, but should give an idea, and works for simple cases.

<Technical>
The problem, as can be seen, is that there is no provision for statefulness in ther Parse on a level higher than the Preprocessor. While one could add these as properties of the Frame objects, (even for this simple case as yet another flag) it would be compounding the two levels of parsing. Adding provision for higher level state is also blocking other similar bugs. (Like int: not tracking language, being able to act based on template call stack from wikitext etc.)

The price for this of course means more work for the parser, it also reduces (albeit slightly for this particular case) caching opportunities. While I think something like this is the way forward, it needs a lot of care and attention before it can be implemented.
</Technical>

For this bug itself, I am not convinced it should be fixed. A much nicer solution would be to use {{{|safesubst:}}} at strategic points in your templates http://en.wikipedia.org/wiki/Help:Subst#safesubst:

Attached: PATCH.substall

Jarekt added a comment.Via ConduitJul 2 2010, 6:03 PM

I was rather unplesently surprised that subst: stopped at the first level I always assumed the saved text would be the same as what I get from Special:ExpandTemplates. Hopefully substall: would fix it.

No interpreter found: The
Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

bzimport added a comment.Via ConduitNov 9 2011, 4:35 PM

sumanah wrote:

Adding the "need-review" keyword for patches that need review by developers. Conrad, thank you for your patch, and sorry it's taken so long for a response on this!

demon added a comment.Via ConduitDec 23 2011, 7:56 PM

(In reply to comment #25)

Adding the "need-review" keyword for patches that need review by developers.
Conrad, thank you for your patch, and sorry it's taken so long for a response
on this!

From what I remember, Conrad and I weren't even convinced this should be committed. Reading back over it, I am inclined to agree.

Maybe we could ask Gabriel or Brion to weigh in how they think PST-type magic like this would be handled in the new parser, but as it stands I'm inclined to say WONTFIX.

bzimport added a comment.Via ConduitAug 17 2012, 11:00 AM

sumanah wrote:

(In reply to comment #26)

Maybe we could ask Gabriel or Brion to weigh in how they think PST-type magic
like this would be handled in the new parser, but as it stands I'm inclined to
say WONTFIX.

Now that we have Parsoid, I'm cc'ing Subbu & Gabriel to ask.

Jackmcbarn added a comment.Via ConduitSep 23 2014, 1:28 AM

If a template wants itself to be substed all the way, it can do so by putting {{{|safesubst:}}} before all of its template calls. I see no reason to complicate things by letting this work for templates that aren't set up for it.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.