Last modified: 2011-07-18 18:04:31 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 T6484, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4484 - <substonly> and <nosubst>
<substonly> and <nosubst>
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: Normal enhancement with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 15773 (view as bug list)
Depends on:
Blocks: 2376
  Show dependency treegraph
Reported: 2006-01-04 20:10 UTC by Carl Fürstenberg
Modified: 2011-07-18 18:04 UTC (History)
12 users (show)

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

probably the only thing needed to be done (902 bytes, patch)
2006-10-28 12:35 UTC, Carl Fürstenberg
correct path (1.34 KB, patch)
2006-10-28 12:51 UTC, Carl Fürstenberg

Description Carl Fürstenberg 2006-01-04 20:10:00 UTC
I would like to propose an enchantment simlar to includeonly and noinclude, but
trigger on subst instead.

Comment 1 Riley McArdle 2006-03-20 17:29:29 UTC
I'd like to second that request.  I think <substonly> instead of <onsubst> would be better though, to keep the 
syntax the same as <includeonly>.
Comment 2 omniplex 2006-05-26 05:11:15 UTC
Today I tried...
<includeonly<noinclude>[[Category:foo]]</noinclude></includeonly> a template used by other templates, which should be in the
template category foo, but pages using those other templates are
no foo-templates. That experiment failed miserably, is it related
to this report? 
Comment 3 Minh Nguyễn 2006-05-26 15:38:44 UTC
First of all, the opening tag should be "<includeonly>", not "<includeonly".
Second of all, no, this bug report is requesting a way to include code only when
substituting ([[m:Help:Substitution]]).
Comment 4 Carl Fürstenberg 2006-10-28 12:35:11 UTC
Created attachment 2584 [details]
probably the only thing needed to be done
Comment 5 Carl Fürstenberg 2006-10-28 12:51:06 UTC
Comment on attachment 2584 [details]
probably the only thing needed to be done

didn't test the path, this one is minor wrong, next one is correct
Comment 6 Carl Fürstenberg 2006-10-28 12:51:48 UTC
Created attachment 2585 [details]
correct path

This is the correct version of the patch, tested on local wiki
Comment 7 Brion Vibber 2006-10-28 17:49:25 UTC
Behavior should never be different between straight inclusion and subst; strongly
inclined to WONTFIX this.

If there are problems with subst behavior, these should be found, reported, and
addressed specifically.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-28 23:12:52 UTC
(In reply to comment #7)
> Behavior should never be different between straight inclusion and subst; strongly
> inclined to WONTFIX this.
> If there are problems with subst behavior, these should be found, reported, and
> addressed specifically.

The first that comes to mind that we probably don't want to fix is that substed
headers act like normal headers, transcluded headers have a section edit link
going back to their template.  This causes problems on any number of templates,
like [[Template:Imagesource]] on enwiki, that are generally dumped on the user
talk pages of newbies who will then attempt to edit the section to respond.  The
templates are supposed to be substed anyway (see bug 2003), but if someone
doesn't, then you don't want to have to protect a low-risk template for such a
silly reason.  It would also be useful for seamless template-side implementation
of bug 2777, so that the user doesn't have to use a different word just because
the template happens to contain some other templates or whatever.  And probably
other things as well.

In general, this feature is emulated right now via abuse of bug 5453, possibly
among other behaviors that might be undefined or subject to change or just messy.
Comment 9 Titoxd 2006-11-25 18:57:29 UTC
At first glance, having different behavior on substitution and transclusion
sounds like a bad idea, but there are several uses for this, particularly
phasing out the abuse of bug 5453. I just spend about 20 minutes trying to fix
[[Template:Class parameter]], which is a meta-template used to add a particular
function to WikiProject banners on the English Wikipedia. It is much better to
tell someone "add the following line of code here:" than "add the following
block of code and replace every single appearance of 'blah' for something else",
and the way we accomplish it is via an extremely ugly hack, which renders the
code unreadable and makes babies cry. A {{substonly:}} function could be used
for easier integration of these metatemplates, and could also be used to shrink
the awful [[Template:Afd]] and others.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-02-05 15:45:46 UTC
Comment on attachment 2585 [details]
correct path

Obviously, the patch is no longer remotely applicable with the Parser changes ("noinclude" doesn't even occur in Parser.php except in a comment).
Comment 11 Erwin Dokter 2008-02-28 16:08:39 UTC
Just to add my STRONGEST support for this feature. Right now, I'm fighting with including an optional parameter to [[en:Template:Afd top]] that should work when both transcluded and substed. As it is now, I can't subst parser functions when transcluding; all the parser code is transcluded instead. Likewise, when NOT substing parser function, the template exposes the function code in the wiki source when substed, which breaks bots. A simple <substonly>subst:</substonly>(parser function) would fix these two major problem at the same time.
Comment 12 MZMcBride 2008-09-30 07:04:40 UTC
*** Bug 15773 has been marked as a duplicate of this bug. ***
Comment 13 Conrad Irwin 2010-02-10 14:44:09 UTC
Since safesubst: was added in r61710. You will be able to use "safesubst:"
instead of "subst:" in templates that require both transclusion and substitution to work. As this is the main use-case of <nosubst> and <substonly>, this should be good enough. 

If you need more behaviour it is possible to tell whether the template has been substituted or not using the behaviour of "subst:", though I'll agree this is a bit hacky.

{{ {{{|safesubst:}}} #if: {{subst:ns:0}} | nosubst | substonly }}
Comment 15 Conrad Irwin 2010-03-16 17:56:20 UTC
This change was not reverted, so re-closed as comment 13

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