Last modified: 2010-05-15 15:34:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1033 - Closing square brackets (including ext. link syntax) break image parsing
Closing square brackets (including ext. link syntax) break image parsing
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.4.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-07 20:24 UTC by Alfio Puglisi
Modified: 2010-05-15 15:34 UTC (History)
2 users (show)

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


Attachments

Description Alfio Puglisi 2004-12-07 20:24:55 UTC
An image with an external link (in the form [url desc]) inside the description
will not be recognized as valid image syntax by the parser. See:

http://commons.wikimedia.org/w/index.php?title=Grenada&oldid=24868

It was edited multiple times in the last weeks, so I suppose that it was working
before 1.4 beta.
Comment 1 John Pozniak 2004-12-23 08:17:40 UTC
The bug also seems to make other images in the same article not render properly.
 In the old version of the article below, the image with the external link is in
the "History" section of the article, while an image in the "Arts and
architecture" section also fails to render properly despite not having an
external link.

http://en.wikipedia.org/w/index.php?title=San_Jose%2C_California&oldid=8737066

John Pozniak [[w:en:User:Gentgeen]]
Comment 2 Daniel U. Thibault 2004-12-24 13:59:21 UTC
Images were working before 1.4 beta. ALL of the "Flag of" pages are now
horrendously broken. See for example [[Flag of Afghanistan]]; the firts flag
image is supposed to be
<nowiki>[[Image:Afghanistan_flag_large.png|thumb|250px|[[Image:FIAV_56.png]]
Flag Ratio: 1:2]]</nowiki>, that is to say a 250px wide thumb of the Afghanistan
flag, with a legend prefixed with the small image FIAV_56. That result is there,
but is prepended and appended with extraneous bits of the legend and code.
Comment 3 Rowan Collins [IMSoP] 2004-12-27 20:50:35 UTC
I've moved the "image in an image caption" issue (comment 2) to a seperate bug
(bug 1217), because it has a sufficiently different effect that I suspect it of
being a different part of the code (i.e. it renders, but badly, whereas ext.
links don't render at all).

I've just realised that this bug is actually triggered by any "]" in the image
caption (see simplified test case at http://test.wikipedia.org/wiki/Bug_1033),
which points back to Parser::replaceInternalLinks(), and either the odd code for
parsing links within captions, or the original regex for what a link might look
like:
 $e1 = "/^([{$tc}]+)(?:\\|([^]]+))?]](.*)\$/sD";
In the check for links-in-captions, I made an unsupported assumption that
anything matching $e1_img and not $e1 represents a line that ends without its
"]]". This isn't true, because "[[Foo|...]...]]" also fails $e1 (I think), but
there's no inner link to close. So if you invent and then close an inner link,
you can fool that code: "[[Image:AllisonCrowe.jpg|frame|foo ] bar]] [[]] ]]"
works as you'd expect, and so does "[[Image:AllisonCrowe.jpg|frame|foo
[http://example.com example] bar]] [[]] ]]". Yeuch!

Comment 1: > The bug also seems to make other images in the same article not
render properly.
I appear to have predicted that side-effect in bug 637 comment 11 - a "broken"
image syntax has knock-on effects for the whole rest of the page. I later
realised that we can avoid "eating" *any* additional text - if we don't need it
for the caption, it can stay in the array for the next iteration, but I never
got round to implementing that; I, or somebody (who has any idea what I'm on
about), should do so.

I'm CCing Wil Mahan on this, because he and I hashed out the current
replaceInternalLinks() function in response to bug 637, so he might have some
thoughts.
Comment 4 Rowan Collins [IMSoP] 2005-01-13 16:49:47 UTC
It seems JeLuF has spotted a duplicate report of this issue (bug 1317) and fixed
it by simply allowing any link to have a "]" after the "|". While this obviously
only makes sense for image captions, it seems a reasonable enough solution, so
I'll mark this as fixed.

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


Navigation
Links