tstarling(a)svn.wikimedia.org wrote:
Revision: 40850
Author: tstarling
Date: 2008-09-15 07:10:40 +0000 (Mon, 15 Sep 2008)
Log Message:
-----------
It's incorrect to use both Sanitizer::escapeHtmlAllowEntities() and
Parser::recursiveTagParse(). Parser::recursiveTagParse() accepts plain wikitext as input,
and will handle any invalid entities itself.
Note that ideally, ImageMap would parse the image options in the same way as the parser
does image links. This would mean replaceVariables(), removeHTMLtags(), doTableStuff(),
<hr/>, doDoubleUnderscore(), doHeadings(), DateFormatter::reformat(), doAllQuotes(),
replaceExternalLinks() and replaceInternalLinks2(). But recursiveTagParse() is almost the
same anyway: only doMagicLinks() and formatHeadings() are added, and RIL/REL are done in
the opposite order.
Modified Paths:
--------------
trunk/extensions/ImageMap/ImageMap_body.php
Modified: trunk/extensions/ImageMap/ImageMap_body.php
===================================================================
--- trunk/extensions/ImageMap/ImageMap_body.php 2008-09-15 06:37:57 UTC (rev 40849)
+++ trunk/extensions/ImageMap/ImageMap_body.php 2008-09-15 07:10:40 UTC (rev 40850)
@@ -71,7 +71,7 @@
return self::error( 'imagemap_bad_image' );
}
// Parse the options so we can use links and the like in the caption
- $parsedoptions = $parser->recursiveTagParse(
Sanitizer::escapeHtmlAllowEntities($options) );
+ $parsedoptions = $parser->recursiveTagParse( $options );
$imageHTML = $parser->makeImage( $imageTitle, $parsedoptions );
$parser->mOutput->addImage( $imageTitle->getDBkey() );
That's what I expected, but using Parser::recursiveTagParse() on
'thumb|right|250px|Area Codes 304 & 681' returns 'thumb|right|250px|Area
Codes 304 & 681', the & is not replaced with & and causes ImageMap
to return an 'imagemap_invalid_image' error (bug 15289). Is this a bug
with the parser, or the way ImageMap handles the output?