Last modified: 2014-04-30 10:50:48 UTC
BUG MIGRATED FROM SOURCEFORGE http://sourceforge.net/tracker/index.php?func=detail&aid=963066&group_id=34373&atid=411192 Originally submitted by Nobody/Anonymous - nobody 2004-05-30 11:51 If there are two sections with the same name, e.g: "X", "Examples" (of X) "Y", "Examples" (of Y) and you edit "Examples" (of Y), after saving the page you will be returned to "Examples" (of X) ------------------------- Additional comments ------------------------ Date: 2004-08-09 07:13 Sender: SF user vibber Lowering priority. It's kind of annoying, but rare and non-destructive.
*** Bug 118 has been marked as a duplicate of this bug. ***
*** Bug 2022 has been marked as a duplicate of this bug. ***
*** Bug 2404 has been marked as a duplicate of this bug. ***
renamed to "Return to page after edit of section *(where section name occurs multiple times)*" last note in bug 2831 coment 0 releates to this Regards Reinhardt [[user:gangleri]]
*** Bug 3196 has been marked as a duplicate of this bug. ***
*** Bug 5395 has been marked as a duplicate of this bug. ***
A possible fix would be to keep an lookup array of used id/names and keep on adding to it as you parse the wikitext. If there's a collision, append a number, and try again (if another collision, increment the number). Not sure how this would affect the rest though, and there would be no way of figuring out the anchor name from an isolated section.
I beleive you may have to simply re-parse the entire file until we get to the section in question and just count the number of ocurrances where we see the same title (this can be done before the edit screen shows up, special care must be taken during edit conflicts). The section headings following the one we edit really do not affect the nomenclature of the emerging link. HOWEVER, I do see a problem with changing heading names breaking external links to specific sections. See this test page for an example: http://test.wikipedia.org/w/index.php?title=User:Stux/sectionTest1&action=history But that belongs at a different bug and I think that duplicate headings should be handled differently (i.e. #Section_Subsection_SubSubsection).
While in the main namespace, #Section_Subsection_SubSubsection may both be logical and solve this problem, in talk pages it is not uncommon for there to be more than one heading with the same name on the same level. This would still not be addressed, and I would assume that the numbering as currently used in anchors would be best.
I believe the section IDs can be obtained from the parser output structure these days, and we do a parse on save. Should be possible to grab the proper formulation of the section name for the redirect.
This bug is related to bug 18700 ("Link to section does not work in edit summaries in case of multiple sections with the same name").
*** Bug 18700 has been marked as a duplicate of this bug. ***
*** Bug 15847 has been marked as a duplicate of this bug. ***
*** Bug 21275 has been marked as a duplicate of this bug. ***
*** Bug 34225 has been marked as a duplicate of this bug. ***
Partial fix in Gerrit change #55508.
*** Bug 60463 has been marked as a duplicate of this bug. ***
Keywords for finding this bug again: duplicate section header, duplicate section heading, same section headers, same section headings, post-save redirect
Still reproducible today, both with "Edit source" and "Edit links". Filed almost 10 years ago, with 9 duplicates (the last one less than 4 months old), 20 users CCed, 10 votes, and a -1 changeset that went through 12 revisions last Summer, I think this is the oldest relevant bug that still bothers people. Any ideas to solve it? Dan, this might be a good candidate in your list. PS: adding "design" keyword because this is a UX problem.
Quim, while I agree it is a bad user experience, the fix seems to be a purely engeineering one. If this is 10 years old hopefully Parsoid offers a solution now.
(In reply to Quim Gil from comment #19) > Any ideas to solve it? Dan, this might be a good candidate in your list. My list (context: https://www.mediawiki.org/wiki/Platform_product_microtasks) is for problems where I can clearly define the engineering solution. In this case, I can only think of one easy solution, and it's a bit of a ridiculous one, so it's better that I leave it off the list. (In reply to Jared Zimmerman (WMF) from comment #20) > Quim, while I agree it is a bad user experience, the fix seems to be a > purely engeineering one. If this is 10 years old hopefully Parsoid offers a > solution now. Sure. We can leave the keyword off.
Alright, then this means that nobody is planning to work on this right now. Setting priority accordingly. The fact is that a MediaWiki page with several sections with the same label will have a different anchor for each. See "#Test", "#Test_2", "#Test_3"... at https://www.mediawiki.org/wiki/User:Qgil/Sandbox#Test_2 The TOC can deal well with these anchors. How difficult would be to make that, after editing a section, the browser lands in the specific anchor and not in the first one? Sorry, I don't know enough to understand where MatmaRex's patch got stuck.
(In reply to Quim Gil from comment #22) > MatmaRex's patch IAlex's patch, not mine :)
*** Bug 64147 has been marked as a duplicate of this bug. ***
(In reply to Quim Gil from comment #22) > > The fact is that a MediaWiki page with several sections with the same label > will have a different anchor for each. See "#Test", "#Test_2", "#Test_3"... > at https://www.mediawiki.org/wiki/User:Qgil/Sandbox#Test_2 > > The TOC can deal well with these anchors. There's still one gotcha though: if you have sections "Test", "Test", and "Test 2". The last two get the same hash-name!
