tstarling@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 &amp; 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?