Last modified: 2014-01-12 20:18:12 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 T20295, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18295 - Strip markers exposed in anchor links with ==[[Link|<nowiki>text</nowiki>]]==
Strip markers exposed in anchor links with ==[[Link|<nowiki>text</nowiki>]]==
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.15.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser, patch, patch-need-review
Depends on:
Blocks: UNIQ
  Show dependency treegraph
 
Reported: 2009-04-01 02:41 UTC by smile
Modified: 2014-01-12 20:18 UTC (History)
7 users (show)

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


Attachments
Proposed fix: Swap the order of tag and link unstripping in Parser::formatHeadings() (1.19 KB, patch)
2009-04-01 09:32 UTC, P.Copp
Details

Description smile 2009-04-01 02:41:13 UTC
1) Page sections containing UNIQ key can no longer be referenced directly by permanent/external links.


2) "API prop=sections" fails in section-titles containing UNIQ key, for example

<s toclevel="1" level="2" line="UNIQ28cf615b3f10792f-nowiki-0000000B-QINU" number="39" />

where section-title-text behind the UNIQ key is lost:

http://de.wikipedia.org/w/api.php?action=parse&page=Wikipedia:Fragen_zur_Wikipedia/Archiv/2009/Woche_10&prop=sections
Comment 1 Splarka 2009-04-01 03:02:27 UTC
UNIQ strings are not a feature, they are a consequence of malformed parsing (basically a big flashing sign that says "BAD WIKICODE HERE". In this case it seems no valid anchor string can be formed from [[Link|<nowiki>text</nowiki>]]. Changing topic appropriately. This might be a dupe or WONTFIX though.
Comment 2 smile 2009-04-01 04:06:54 UTC
(In reply to comment #1) OK, thanks. What puzzles me is, why do UNIQ strings have to change at all and/or so frequently? And even when a wiki-page doesn't change? That's a real drag in archived talk-pages, where "nowiki" is used quite frequently in section-titles.
Comment 3 P.Copp 2009-04-01 09:32:48 UTC
Created attachment 5983 [details]
Proposed fix: Swap the order of tag and link unstripping in Parser::formatHeadings()

Easy fix: Swap the order of link unstripping and extension tag unstripping in Parser::formatHeadings().
It is IMHO far more likely that a link contains an extension tag (like above), while offhand I can't think of a case, where an extension tag would contain an half-parsed link at that stage of parsing.

(In reply to comment #2)
> (In reply to comment #1) OK, thanks. What puzzles me is, why do UNIQ strings
> have to change at all and/or so frequently? And even when a wiki-page doesn't
> change? That's a real drag in archived talk-pages, where "nowiki" is used quite
> frequently in section-titles.
> 
The whole point of UNIQ keys is that they are not predictable, so you can't break parsing by inserting some of them to a page.
Comment 4 db [inactive,noenotif] 2010-12-03 19:40:45 UTC
related: bug 25417 (<ref> used also strip markers inside wikilink)
Comment 5 Mark A. Hershberger 2011-07-07 13:57:35 UTC
(In reply to comment #3)
> Created attachment 5983 [details]
> Proposed fix: Swap the order of tag and link unstripping in
> Parser::formatHeadings()

Paul, could you apply the patch now that you have commit privs?
Comment 6 Mark A. Hershberger 2011-07-09 20:33:25 UTC
Looks like this is already fixed from my testing on wikipedia.
Comment 7 P.Copp 2011-07-12 17:45:11 UTC
(In reply to comment #6)
> Looks like this is already fixed from my testing on wikipedia.

It's not. Try putting 

== [[Link|<nowiki />]] ==

in a page and look for <span class="mw-headline" id=".7FUNIQ...QINU.7F">.

However, I don't think this can be fixed at the moment, as Brion points out at bug 93 comment 30 that the parser is currently being frozen and rewritten.
Comment 8 Mark A. Hershberger 2011-07-18 01:47:10 UTC
(In reply to comment #7)
> However, I don't think this can be fixed at the moment, as Brion points out at
> bug 93 comment 30 that the parser is currently being frozen and rewritten.

http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/54555
Comment 9 Tim Starling 2012-03-20 04:43:38 UTC
Fixed in r114231.
Comment 10 Gadget850 2013-02-01 02:00:33 UTC
Looks like this is fixed. Tested with 1.21wmf8.

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


Navigation
Links