Page MenuHomePhabricator

<includeonce> for embedded pages
Closed, DeclinedPublic

Description

Author: kovo1

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz11831

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:57 PM
bzimport set Reference to bz11831.
bzimport added a subscriber: Unknown Object (MLST).

kovo1 wrote:

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.

anagg83 wrote:

*** This bug has been marked as a duplicate of bug 22758 ***

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

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

anagg83 wrote:

Well yeah, an <includeonce> though, would be a much simpler thing to implement. Why hasn't anyone done this in 3 years?

anagg83 wrote:

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.

Angel, you don't specify when you want to transclude just one level. What's the case for wanting to do that?

anagg83 wrote:

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.

anagg83 wrote:

And does that name denote Greek origin or something?

svippy wrote:

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.

conrad.irwin wrote:

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.

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

anagg83 wrote:

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?

conrad.irwin wrote:

(In reply to comment #12)

I think this should be easily implemented. Am I wrong?

Yes.

anagg83 wrote:

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.

anagg83 wrote:

Or <include> tags that will ignore other such tags.

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