Last modified: 2008-02-27 03:46:04 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 T8563, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 6563 - Section edit links for transcluded templates are not affected by <noinclude> or <includeonly>
Section edit links for transcluded templates are not affected by <noinclude> ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
1.12.x
All All
: Normal normal with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/User:Kev...
:
: 10170 (view as bug list)
Depends on: 12652
Blocks: 4899
  Show dependency treegraph
 
Reported: 2006-07-06 08:45 UTC by Kevin Breitenstein
Modified: 2008-02-27 03:46 UTC (History)
8 users (show)

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


Attachments

Description Kevin Breitenstein 2006-07-06 08:45:31 UTC
As can be whitnessed on
http://en.wikipedia.org/wiki/User:Kevin_Breitenstein/T_test_main.

Basically, there are two transcluded templates on the page.  Subpage 1 and
subpage 2.  Subpage 1 has its 2nd section surrounded by <noinclude>, and subpage
2 and its 1st section surrounded by <noinclude>.

Attempting to use the section edit links for the first template's 1st section is
easy and understandable.  But if you attempt to edit the 2nd section that
appears, you are taken to an edit page for a completely different section of the
template.

The attempt to produce a section edit link relies on only counting what ends up
on the transcluded page, but the edit link it produces relies upon the natural
layout of the page in question.

Its all messed up really.  Subpage 3 edits just fine, but try actually going to
subpage 3, you'll find that the includeonly has made it so that the only section
displayed 


To summarize: Section edit links are generated based upon displayed content, but
going to said section edit links leads to a section that does not take into
account noinclude or includeonly tags.  Therefor, section edit links should be
generated based upon content as if there were no <includeonly> or <noinclude>
links. 

This got annoying with Wikipedia's Request for Checkuser as we wanted a requests
related to a username to be on one page, and transcluded to the main page, but
edit links started acting 'strange'.


This bug may be related to 4926, and is still currently a problem as of 1.7alpha
r14796.
Comment 1 folengo 2006-11-18 17:18:07 UTC
I agree with Kevin.

For all practical matters, this bug prevents transclusion of selected sections
of pages that contain several sections. 

"< noinclude > " and "< includeonly >" are useless when you try to use them to
select some sections among many.

To understand what this means, try, for example, editing "section 3" of
[[:fr:Utilisateur:Teofilo/test1]] http://tinyurl.com/mhedy .
Instead of "text 3" as expected, you will find "text 1" in the edit box.

Similarly, try editing "section 5" of [[:fr:Utilisateur:Teofilo/test2]]
http://tinyurl.com/uvqgy . 
Instead of editing "text 5", as expected, you will find "text 3" in the edit box.


Comment 2 Steve Sanbeg 2007-04-03 21:46:09 UTC
I don't think template transclusion was intended to do that; it would be
somewhat complicated to fix, since there are three distinct types (noinclude,
includeonly, and onlyinclude) of tags that should be accounted for.

That's part of what the labeled section transclusion
(http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion) was
intended to address, so this extension can handle that case.  

But we're still waiting to hear if that can be installed on the official
projects.  Since that marks the sections by name, instead of behavior, it is
simpler to do in the extension, but it's not simple to port that functionality
into the core code.
Comment 3 Phil Boswell 2007-04-04 07:10:07 UTC
The distinction between using the built-in tags like <noinclude> and the LST extension is that in the former case 
the content of the **transcluded page** itself determines which portions are transcluded, and this does not change 
unless the transcluded page does. In the latter case the transcludING page decides which portions are transcluded, 
and this is subject to change in both places: the transcludING page might choose to transclude a different 
selection, the transcludED page might **offer** a different selection.

What appears to be happening here is that different code for counting sections is being used in different places, 
and the use of <includeonly> tags and the like causes the two different methods to come up with different answers. 
Hope this clears up your confusion.
Comment 4 Steve Sanbeg 2007-04-04 16:48:03 UTC
<includeonly> tags have the same behavior in both.  It's when using the
extension tags that the extension counts the number of sections that are skipped
in the beginning, so that transcluded links can be offset.  

includeonly and sections currently don't work well together, and I don't know of
a solution to that, at least not without a substantial rewrite to one or both of
the section edit & includeonly handling.  I'm not sure that this is intended to
be done with  the built in transclusion anyway, or if they'd want to rework the
core code that much, when it can be done in an extension.

Comment 5 LFaraone 2007-06-05 22:54:21 UTC
This error is also witnessed on WP:ERRORS (enwp)
Comment 6 Autocracy 2007-06-06 15:29:29 UTC
*** Bug 10170 has been marked as a duplicate of this bug. ***
Comment 7 Carl Fürstenberg 2007-09-14 22:07:48 UTC
marking the severity as major as I believe that it's a major issue. A pretty simple solution to the problem could be to introduce some meta directive to recount the sections, so for example this could work:
<includeonly>
#SECTIONNUMBERHEREIS 2</includeonly>
Comment 8 Steve Sanbeg 2007-09-18 16:49:55 UTC
(In reply to comment #7)
> marking the severity as major as I believe that it's a major issue. A pretty
> simple solution to the problem could be to introduce some meta directive to
> recount the sections, so for example this could work:
> <includeonly>
> #SECTIONNUMBERHEREIS 2</includeonly>
> 

It may be easier to see if the labeled section transclusion should be installed, or if enhancements should be made to that.  Since the extension counts sections automatically, it's less likely to cause weird behavior if someone edits the transcluded page later on.

Although there may be various ways to hack some kind of workaround into the core code, I don't know if that's the place for it; and since the extension is already running on some projects, that may be more useful in the long run.
Comment 9 Graham87 2007-12-11 14:18:00 UTC
I' think I've just encountered this problem, or something similar, while finding vandalism. This edit:
http://en.wikipedia.org/w/index.php?title=List_of_French_people&diff=174641184&oldid=174640959
caused all section links beyond "P-r of authors section" (which was most of the article) to point to the wrong place. (There is an item "<includeonly></includeonly>" in the edit toolbar. Interestingly includeonly causes this problem while noinclude does not, as can be shown by:
http://en.wikipedia.org/wiki/User:Graham87/sandbox2
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-06 03:50:17 UTC
r29292 looks to fix this, but Tim isn't sure if it will stick.

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


Navigation
Links