Last modified: 2005-12-28 23:17:37 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 T5495, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3495 - Broken links to special pages with action=render
Broken links to special pages with action=render
Status: RESOLVED DUPLICATE of bug 3397
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.6.x
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://de.wikipedia.org/wiki/Benutzer...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-18 10:41 UTC by Henning Heitkötter
Modified: 2005-12-28 23:17 UTC (History)
0 users

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


Attachments

Description Henning Heitkötter 2005-09-18 10:41:37 UTC
Using action=render on a page that links to a special page (e.g.
[[Special:Allpages]]) results in a weird link in the output (see URL): obviously
the link is parsed twice, as two html link-tags are visible.

Cause: this bug arises from the special treatment of links to Specialpages in
combination with the full links (incl $wgServerUrl) in the href-attribute.
Unlike normal links, those to special pages are not replaced by a linkholder but
inserted directly (via Skin::makeKnownLinkObj). With $action == 'render' links
are inserted with $wgServerUrl (which is useful). After this parsing of the
internal links the external links are parsed. The value in the href-attribute is
now considered as a free external link and replaced with a new link-tag of class
'external free'.

Solution: ?, perhaps the regex '/(\b(?:'.$wgUrlProtocols.'))/S' in
Parser:replaceExternalLinks could be adjusted?
Comment 1 Tim Starling 2005-12-11 16:40:50 UTC
This also occurs for [[:Image:xxx]] links, for the same reason. This could
probably be fixed by replacing makeKnownLinkObj() with makeLinkHolder(), as is
done with interwiki links.
Comment 2 Rowan Collins [IMSoP] 2005-12-12 18:04:50 UTC
There's also the dummy links used for commons images and links inside captions,
using UNIQ_PREFIX."NOPARSE" [That should probably happen in a function, btw, so
it can be changed in one place, without risk of doom]. Don't know what the
advantages and disadvantages of using each in these cases are.
Comment 3 bdk 2005-12-14 21:37:58 UTC
(In reply to comment #1)

not really a duplicate, but please compare bug 2726 
regarding broken image links from the Commons
Comment 4 Brion Vibber 2005-12-28 23:17:37 UTC

*** This bug has been marked as a duplicate of 3397 ***

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


Navigation
Links