Last modified: 2014-09-23 23:43:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4777, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2777 - Provide a recursive subst: function in the PST – {{substall:foo}}
Provide a recursive subst: function in the PST – {{substall:foo}}
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 19 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://test.leuksman.com/index.php?ti...
: patch, patch-need-review
: 8081 9470 9499 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-09 17:20 UTC by lɛʁi לערי ריינהארט
Modified: 2014-09-23 23:43 UTC (History)
21 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
A (hacky) patch (8.79 KB, patch)
2010-04-02 02:26 UTC, Conrad Irwin
Details

Description lɛʁi לערי ריינהארט 2005-07-09 17:20:34 UTC
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]]
Comment 1 lɛʁi לערי ריינהארט 2006-04-16 11:25:28 UTC
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.
Comment 2 Ligulem 2006-04-29 08:48:54 UTC
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).
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-05-01 03:54:38 UTC
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.
Comment 4 omniplex 2006-05-01 13:29:21 UTC
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]].
Comment 5 Ligulem 2006-05-01 15:30:28 UTC
(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".

Comment 6 alerante 2006-05-01 19:54:37 UTC
(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.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-05-01 20:26:17 UTC
(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).
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-05-01 20:28:41 UTC
(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.
Comment 9 omniplex 2006-06-29 15:54:28 UTC
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.
Comment 10 Gabriel Tran 2006-07-06 09:40:10 UTC
> 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.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-30 03:12:16 UTC
*** Bug 8081 has been marked as a duplicate of this bug. ***
Comment 12 Rob Church 2006-12-22 02:12:40 UTC
You can now use the ExpandTemplates extension to perform the requested recursive
substitution.
Comment 13 Rob Church 2007-04-01 16:40:11 UTC
*** Bug 9470 has been marked as a duplicate of this bug. ***
Comment 14 Rob Church 2007-04-01 16:48:30 UTC
*** Bug 9470 has been marked as a duplicate of this bug. ***
Comment 15 Rob Church 2007-04-08 07:37:53 UTC
*** Bug 9499 has been marked as a duplicate of this bug. ***
Comment 16 SJ 2008-01-30 07:06:26 UTC
See also #2003, which would make resolving this bug much easier.  
Comment 17 Chad H. 2008-07-26 03:00:35 UTC
Extension:SubstAll committed in r38054
Comment 18 lɛʁi לערי ריינהארט 2009-12-23 02:02:07 UTC
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
Comment 19 Roan Kattouw 2009-12-23 12:51:46 UTC
(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.
Comment 20 Chad H. 2010-01-27 19:03:13 UTC
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.
Comment 21 Svip 2010-04-02 00:15:10 UTC
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.
Comment 22 Conrad Irwin 2010-04-02 02:26:00 UTC
Created attachment 7259 [details]
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:
Comment 23 Jarek Tuszynski 2010-07-02 18:03:43 UTC
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.
Comment 24 p858snake 2011-04-30 00:09:52 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 25 Sumana Harihareswara 2011-11-09 16:35:13 UTC
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!
Comment 26 Chad H. 2011-12-23 19:56:06 UTC
(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.
Comment 27 Sumana Harihareswara 2012-08-17 11:00:02 UTC
(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.
Comment 28 Jackmcbarn 2014-09-23 01:28:39 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links