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.

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).

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.

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]].

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".

(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.

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).

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.

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.

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.

ayg wrote:

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

robchur wrote:

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

robchur wrote:

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

robchur wrote:

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

robchur wrote:

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

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

Extension:SubstAll committed in r38054

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

(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.

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.

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.

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:

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.

The {{{|safesubst:}}} solution, as far as I understand it, works only if you alter all the sub-templates used by your main one. Because of that it is not very practical in a lot of cases.

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

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!

(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.

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.

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.

There is some potential for an infinite loop here. What if someone tries to substall a template that is unsubstified, for example.