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?
--
Alex (w:en:User:Mr.Z-man)