Last modified: 2011-12-21 12:23:11 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 T35254, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33254 - What Links Here does not detect transclusion within #if parser function
What Links Here does not detect transclusion within #if parser function
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-19 17:13 UTC by Dan Barrett
Modified: 2011-12-21 12:23 UTC (History)
3 users (show)

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


Attachments

Description Dan Barrett 2011-12-19 17:13:53 UTC
If you transclude a template inside of {{#if:}}, it sometimes does not show up in "What Links Here". Now that extension/ParserFunctions is an official part of the 1.18 core release, this may be considered a legitimate bug.  

Case study: save this code in an article "Foo":

{{#if:{{{whatever|}}} | {{TranscludeMe}}}}

and then you visit Template:TranscludeMe and click "What Links Here", the article "Foo" does not show up.

I assume this is because the #if is false at parsing time, so dynamically speaking, TranscludeMe is not transcluded. However, in a static sense, the page Foo arguably DOES transclude Template:TranscludeMe because the wikitext exists on the page; it's just that the runtime semantics of #if prevent the actual transclusion.
Comment 1 Bawolff (Brian Wolff) 2011-12-21 05:50:25 UTC
That's intentional/desired behaviour I thought? (in any case side effect of not actually parsing the unused part of the if, which is extremely unlikely to change).

Consider if Foo was transcluded every where, you'd only want the pages that actually call it with the parameters that make TranscludeMe appear, appear on special:whatlinkshere

>Now that extension/ParserFunctions is an official part of
>the 1.18 core release, this may be considered a legitimate bug. 

Umm, we've always considered bugs for extensions (or at least extensions generally used on Wikimedia) as legitimate bugs. Bundling parser funcs with 1.18 has neither increased nor decreased its legitimacy (we still consider it an extension, so this isn't a core bug, not that that changes anything), but it was always legit in the first place.
Comment 2 Dan Barrett 2011-12-21 12:23:11 UTC
Bawolff, thanks for your insightful comments.

>...you'd only want the pages that actually call it with the parameters
>that make TranscludeMe appear, appear on special:whatlinkshere

You're correct for some cases, but in others you really do want to see all pages. For example, suppose you are modifying the behavior of Template:TranscludeMe and you want to know how wide-ranging the impact will be. You need to know every page that transcludes Template:TranscludeMe in order to test properly. But pages that contain {{#if:{{{foo|}}}||{{TranscludeMe}}}} simply cannot be found today. You need a static analysis, not a dynamic analysis, to locate these instances.

I do understand that you don't want to parse the unused portion of #if (for performance/correctness).  I just wish there were a solution to the above problem, even if it were search-engine-based rather than parser-based.

As for my calling the bug "legitimate" now that 1.18 is here, what I meant is that this is something the core is doing intentionally, and I figured it would be unlikely to modify core behavior to satisfy an extension (rather than vice-versa) until the extension is officially part of MediaWiki.

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


Navigation
Links