Last modified: 2010-03-16 17:55:09 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 T24297, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22297 - There should be syntax for substitution that doesn't break normal transclusion
There should be syntax for substitution that doesn't break normal transclusion
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
: 11670 (view as bug list)
Depends on:
Blocks: 5453
  Show dependency treegraph
 
Reported: 2010-01-28 02:26 UTC by Conrad Irwin
Modified: 2010-03-16 17:55 UTC (History)
3 users (show)

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


Attachments
A patch to provide this (2.66 KB, patch)
2010-01-28 14:49 UTC, Conrad Irwin
Details
Same as previous patch with subst-if-substed: instead of safesubst: (2.69 KB, patch)
2010-01-28 15:20 UTC, Conrad Irwin
Details
A "for interest" patch implementing {{subst}} (2.87 KB, patch)
2010-01-29 22:37 UTC, Conrad Irwin
Details

Description Conrad Irwin 2010-01-28 02:26:21 UTC
At the moment it is not possible to create a template that substitutes the results of parser functions when substituted and that also works when the template is not substitued.

For example of current status:

Template:X {{<includeonly>subst:</includeonly>#if:{{{1|}}}|1|2}}

{{subst:X}} is transformed into "2" as expected, but
{{X}} generates "{{subst:#if:|1|2}}" - ooops. 

This feature can be used to good advantage, and some templates use a conditional around something that subst:s to nothing to warn users that they must substitute the template. 

I would like to propose an additional prefix "safesubst:" or words to that effect, which gives the same result in both cases above.

Template:X {{<includeonly>safesubst:</includeonly>#if:{{{1|}}}|1|2}}

{{subst:X}} is transformed into "2", as before
{{X}} generates "2" when it is rendered, as expected, and
{{safesubst:X}} works exactly like {{subst:X}}
Comment 1 Conrad Irwin 2010-01-28 14:49:22 UTC
Created attachment 7043 [details]
A patch to provide this

I have attached a patch which implements the proposed change by adding another special-cased magic word to Parser::braceSubstitution.

There is some thought on #mediawiki that instead of hacking it in like this, a more general framework should allow for any magic word to take specific action at this point in the parse. The process by which this might be done, and the concrete benefits of such an approach are not immediately obvious to me.
Comment 2 Conrad Irwin 2010-01-28 15:20:19 UTC
Created attachment 7044 [details]
Same as previous patch with subst-if-substed: instead of safesubst:

This patch incorporates the suggestion that subst-if-substed: it a better prefix than safesubst:. I have no opinion on which is better, it would likely be more consistent to chose a name that doesn't quite mean anything :).
Comment 3 Voyagerfan5761 / dgw 2010-01-28 19:28:18 UTC
(In reply to comment #1)
> Created an attachment (id=7043) [details]
> A patch to provide this
> 
> I have attached a patch which implements the proposed change by adding another
> special-cased magic word to Parser::braceSubstitution.
> 
> There is some thought on #mediawiki that instead of hacking it in like this, a
> more general framework should allow for any magic word to take specific action
> at this point in the parse. The process by which this might be done, and the
> concrete benefits of such an approach are not immediately obvious to me.

Adding a hook at this point in the parse would be similar to WordPress' "shortcode" system, the way I see it. That system has proven to be useful for many, many plugins and I'm sure MediaWiki extension developers would find such a hook useful, too.
Comment 4 Conrad Irwin 2010-01-28 20:16:52 UTC
(In reply to comment #3)
> 
> Adding a hook at this point in the parse would be similar to WordPress'
> "shortcode" system, the way I see it. That system has proven to be useful for
> many, many plugins and I'm sure MediaWiki extension developers would find such
> a hook useful, too.

As a feature requst, I think this belongs in a separate bug. The shortcode system looks more like normal tag extensions/parser functions/templates to me, which people can {{subst:#tag: if they wish.

At the moment the five "transclusion modifiers" (subst:, safesubst:, msg:, msgnw:, raw:), are fairly orthogonal, though it would not be impossible to create a new MagicWordArray to handle them all.
Comment 5 Voyagerfan5761 / dgw 2010-01-29 03:21:49 UTC
(In reply to comment #4)
> As a feature requst, I think this belongs in a separate bug. The shortcode
> system looks more like normal tag extensions/parser functions/templates to me,
> which people can {{subst:#tag: if they wish.
> 
> At the moment the five "transclusion modifiers" (subst:, safesubst:, msg:,
> msgnw:, raw:), are fairly orthogonal, though it would not be impossible to
> create a new MagicWordArray to handle them all.

I think I've been misunderstood. I was reacting to the suggestion of a more general framework for any magic word to hook in at this point in the parse and giving what I thought was a good example implementation. Obviously the shortcodes themselves are more like tag extensions or templates, but the concept of the parser acting on hooks registered by different magic words is what I was presenting. Hopefully that clears it up. I'm not entering a feature request. :)
Comment 6 Conrad Irwin 2010-01-29 22:37:01 UTC
Created attachment 7050 [details]
A "for interest" patch implementing {{subst}}

This is an alternative solution, instead of having subst: and safesubst:, we have subst: and {{subst}}. 

{{subst}} is a magic word that is automatically substituted (i.e. {{subst:subst}} == {{subst}}) and which returns "subst:" during the PST and "" thereafter. The `problem` with this is that it feels too "magic"; I don't expect things to substitute themselves unless they are prefixed by subst: (obviously if the patch were changed to require {{subst:subst}} to be used intstead of {{subst}}, the "magic" happens in the other direction). - maybe this isn't so much of a problem?

<includeonly>{{{{subst}}#if:{{subst}}||Please substitute this template}}</includeonly>

may be clearer than

<includeonly>{{safesubst:#if:{{subst:ns:0}}||Please substitute this template}}
</includeonly>

In the examples above, "safesubst:" may be replaced directly by "{{subst}}" and preserve the intended meaning; however I feel sticking to an alternative prefix is more consistent.

(Sorry Voyagerfan, I'll just let it lie)
Comment 7 Conrad Irwin 2010-01-30 12:10:33 UTC
I applied a patch that adds "safesubst:" in r61710.

The syntax was retained as alternative suggestions are (to my mind) no more clear in purpose, and in the case of {{subst}} (above) or <nosubst>, <substonly> bug 4484, have their own problems. Alternative names for the prefix "trysubst:", "subst-if-substed:" are not noticably improvements.
Comment 8 Stewart Gordon 2010-02-10 15:05:13 UTC
*** Bug 11670 has been marked as a duplicate of this bug. ***
Comment 10 Conrad Irwin 2010-03-16 17:55:09 UTC
Sorry, this particular change was not reverted by Tim, and is in 1.16beta.

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


Navigation
Links