Last modified: 2011-03-13 17:46:08 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 T10322, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8322 - Links inside <includeonly></includeonly> not updated in link tables
Links inside <includeonly></includeonly> not updated in link tables
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
unspecified
All All
: Lowest major with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-19 14:15 UTC by NE2
Modified: 2011-03-13 17:46 UTC (History)
1 user (show)

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


Attachments

Description NE2 2006-12-19 14:15:50 UTC
Recently there has been vandalism to featured articles, where one user uploads a
shock image and another (possibly a sockpuppet) adds the image to a template
that the featured article uses with <includeonly> tags. Clicking on the image to
find which template was vandalized is not possible because of these tags, and
thus it takes a good deal longer to revert.

My recommendation is to include pages that contain the image in <includeonly>
tags on the "file links" section of the image description page.
Comment 1 Brion Vibber 2006-12-24 05:37:20 UTC
The obvious way to fix this would break the actual purpose of <includeonly>,
which is to keep special links such as category links meant to belong to 
target pages from being indicated on the template page.
Comment 2 Jean-Sébastien Girard 2006-12-24 17:03:21 UTC
Isn't it possible to have it work only for "whatlinkshere"-style funcions?
Comment 3 Ilmari Karonen 2006-12-27 19:41:28 UTC
I believe a reasonable solution would be to use the "obvious fix", but
explicitly exclude categories.  Yes, it means yet another parser kluge, and
there are still ways in which a clever deliberate vandal could work around it,
but it does solve the common case and would have practical benefits beyond just
vandal-fighting.

Of course, if we wanted to get fancy, we could add a new section to category
pages: "Templates that add a page to this category when transcluded"...
Comment 4 Conrad Dunkerson 2006-12-27 19:43:00 UTC
If a template is widely transcluded then the 'file links' list of any image
attached to it is going to be very long and difficult to sort through to locate
the template... if it can be made to show up in the list despite <includeonly>
tags in the first place. Another option might be to expand the list of
transcluded pages which is shown when the user clicks 'edit' to also list
included pictures... if pictures brought in by templates could be listed under
the appropriate template that could immediately identify the problem.
Comment 5 NE2 2006-12-30 23:56:34 UTC
Actually it won't be hard to sort through, because it will update only when each
page is refreshed (I believe) and there's no maximum number of entries, so
searching for "template" will find it right away.
Comment 6 Titoxd 2006-12-31 21:06:58 UTC
Isn't it possible to do the "obvious fix" on the imagelinks table only? Then,
that way, you can declare <noinclude>'d images (which are the entire issue) as
also included on the template.

Another solution would be to mark them the way Ilmari suggests, with a
"transcluded in all pages in which this template is transcluded", similar to the
(transclusion) marker on [[Special:Whatlinkshere]].
Comment 7 Brion Vibber 2006-12-31 22:05:27 UTC
No, that's not really possible without some significant retooling.
The <noinclude>, <onlyinclude>, <includeonly> etc sections are handled by simply
removing sections of text before parsing continues. There's no way to know
whether a particular link as it's being parsed is or is not inside such a
section; it's just either there or isn't.

So to treat some kinds of markup differently from others would require
completely changing how these sections are handled; which would very likely
change the behavior of them, which might break thousands of templates.
Comment 8 Brion Vibber 2007-03-15 04:53:00 UTC
cf bug 9293
Comment 9 Mark A. Hershberger 2011-03-13 17:46:08 UTC
Changing all WONTFIX high priority bugs to lowest priority (no mail should be generated since I turned it off for this.)

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


Navigation
Links