Last modified: 2011-07-14 20:56:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11831 - <includeonce> for embedded pages
<includeonce> for embedded pages
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 22758 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-10-31 17:18 UTC by Jonathan Kovaciny
Modified: 2011-07-14 20:56 UTC (History)
5 users (show)

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


Description Jonathan Kovaciny 2007-10-31 17:18:39 UTC
An <includeonce> tag would be very valuable for creating useful templates and for transcluding mainspace pages inside other pages.

For example, let's say I have a page called [[Dodge Viper]], and lets' say I want to embed that entire page inside my [[Dodge models]] page. However, on my [[Dodge Viper]] page, I have a navbox template that uses {{PAGENAME}} as a variable. When the user is viewing the [[Dodge Viper]] page directly, the template is displayed correctly. However, when the user is viewing the [[Dodge models]] page, the template on the embedded [[Dodge Viper]] page now sends "Dodge models" to the template as the {{PAGENAME}}. I want to be able to specify in my template that the template should be rendered as it would be rendered by the [[Dodge Viper]] page, regardless of whether or not that page was embedded somewhere else.

In other cases, I don't want certain navboxes and infoboxes to display on embedded pages, only on the original page viewed alone. Currently, I have to put <noinclude>{{navboxtemplate|x|y|z}}</noinclude> on every page that uses {{navboxtemplate}}; it would make much more sense to have <includeonce> tags in the template itself so that I didn't need <noinclude> tags on all pages that might conceivably be embedded in another page at some point.
Comment 1 Jonathan Kovaciny 2007-12-27 16:35:17 UTC
Could anyone point me to some resources on developing this functionality myself? This would be very useful for my projects, and I suspect others would find it very useful as well.
Comment 2 Angel 2010-03-07 21:26:47 UTC

*** This bug has been marked as a duplicate of bug 22758 ***
Comment 3 Platonides 2010-03-07 21:29:13 UTC
*** Bug 22758 has been marked as a duplicate of this bug. ***
Comment 4 Platonides 2010-03-07 21:31:49 UTC
<includeonce> wouldn't work for a {{PAGENAME}} parameter. You would want something like setting the depth at which a template is transcluded. Or have a variable expanded with the name of the page in which it is written (as opposed to the page oon which it is shown).
Comment 5 Angel 2010-03-07 21:35:04 UTC
Well yeah, an <includeonce> though, would be a much simpler thing to implement. Why hasn't anyone done this in 3 years?
Comment 6 Angel 2010-03-07 21:38:34 UTC
I'm adding the description from my report, as I think it's much clearer:

There are many occasions where the usual <noinclude>, <includeonly>,
<onlyinclude> tags are not enough. It is often the case that something needs to
be transcluded or substituted once, but no more. This is the case with
templates that are transcluded in other templates, but it is not wanted to be
transcluded again in articles and such.

I propose tags <includeonce></includeonce> that will wrap sections that must
only transclude/subst once. Perhaps, they can be converted to <noinclude>,
after the get transcluded/substituted.
Comment 7 Platonides 2010-03-07 21:55:40 UTC
Angel, you don't specify when you want to transclude just one level. What's the case for wanting to do that?
Comment 8 Angel 2010-03-07 22:17:33 UTC
For instance, take a look at Template:Tfd at wikipedia. I'm not sure what's your relation to WP, so I'll elaborate. The template means "Template for discussion" and is put to other templates when they are nominated for deletion or whatever. On the templates I'd like Tfd to appear as a box, containing info about the nomination. On the articles it should appear as a smaller notification. 

All that works so far. It checks for the namespace. If it's template the box shows, if its mainspace, the notifications do. The problem is, when there is documentation in a template. The box then gets transcluded in every single example in them. Check for example Template:Rating-big.

I guess there are some workarounds for this, but it would make things a lot much easier to do this with such a tag. I think it would be very useful to anyone who's working on templates.
Comment 9 Angel 2010-03-07 22:44:39 UTC
And does that name denote Greek origin or something?
Comment 10 Svip 2010-03-24 11:23:24 UTC
Question:  Will <includeonce> be a <includeonly> like tag or will it be like regular?  I can imagine the need for inclusion of something only once, but not whether it needs to be *only* included or whether it could be viewed while viewing the template.  Perhaps a <includeonlyandonce> tag or some such.
Comment 11 Conrad Irwin 2010-03-24 14:12:11 UTC
This proposal, as it stands is horribly confusing. Firstly <includeonce> is a bad name, you still want this to be included multiple times (just not re-included).

The semantics of <includeonce> are also confusing, are <includeonlyonce> or <onlyincludeonce> also needed, what about <includetwice> etc. When an <includeonce> is subst:'d, does it morph into a <noinclude>, what about if I load the template with ?preload=, and what's poor [[mw:Extension:LabelledSectionTransclusion]] supposed to do. In many ways I prefer the solution hinted at by Platonides, creating {{#ifdepth: yX }} - where y is <, = or > and X is 0,1,(2 etc.?). (i.e. <includeonce> = "<2", <noinclude> = "=0", <includeonly> = ">0") or something nicer.

My main worry is, however, that this will only work in a very limited set of cases; whether to show the template or not (even in the given example of deletion template on a template) depends not really on "how many levels of inclusion", but rather on "do I want to see this template here". For example, it's arguable that a nominated meta-template's deletion notice should propagate up through the individual templates that use it - in the Dodge Viper case the reporter implies that the NavBox should be propagated in "some" cases. I am unable to think up a nicer solution, maybe creating the idea of "inclusion contexts", {{context1:Template}}, and then {{#ifcontext:1}} within it, and context number defaulting to namespace, but... yuck.

Implementation of this falls firmly into the "difficult" category, it breaks assumptions made by the parser, and whatever happens it's going to require threading a lot of state around (though that is needed for bug 9105 too - that's the {{PAGENAME}} part of the bug's introduction).
Comment 12 Angel 2010-03-24 16:03:14 UTC
Well, if having a depth or context parameter is not something that is easily implemented, then why not just something simple? Name it <noreinclude> if you will and <reincludeonly>. Those, combined with #ifeq:{{PAGENAME}} should work for most of the cases.

I think this should be easily implemented. Am I wrong?
Comment 13 Conrad Irwin 2010-03-24 16:03:54 UTC
(In reply to comment #12)
> I think this should be easily implemented. Am I wrong?

Comment 14 Angel 2010-03-24 16:09:48 UTC
So, nothing can be done? How about some sort of transclusion or substitution complementary to the existing ones, that will ignore <noinclude> tags and the like.
Comment 15 Angel 2010-03-24 16:11:09 UTC
Or <include> tags that will ignore other such tags.
Comment 16 P.Copp 2011-07-14 20:56:42 UTC
*** Bug 29889 has been marked as a duplicate of this bug. ***

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