Extension talk:ImageMap/LQT Archive 1

Active graphics
- you might add additional/optional columns for the onmouseover and onmouseout attributes - simply have a look at this:

http://www.mrbbc.org/files/de/cloudlevels.htm

- you needn't understand what the text means to figure out how probably you could use JavaScript with image maps.

- But don't be overhasty. I think perhaps one column would be enough; for example if you make a tooltip, onmouseover will call a function that displays the tooltip, and onmouseout simply calls the counterpart that hides it. It should be first discussed whether there should be elementary JavaScript functions as a part of MediaWiki... --Mr. B.B.C. 16:49, 11 January 2007 (UTC)

Broken?
Seems, the extension does not work in templates. If I write in a template:

this is the result:

I think the extension is too early and interprets the brackets as signs instead of waiting for the replacement of the brackets with the parameter's content. If you omit the | it's even worse, then the whole page is broken. Am I right or do I make a mistake? --Slomox 17:30, 11 January 2007 (UTC)


 * I checked this, but I was able to use without problems in templates. jeroenvrp 02:58, 14 January 2007 (UTC)


 * You don't see <imagemap&gt;: invalid title in link at line 4 in the above example? --:Slomox:: &gt;&lt; 16:48, 15 January 2007 (UTC)


 * You can use it in a template, but only without parameters. JePe 20:07, 15 January 2007 (UTC)

Actually, if you use any curly braces at all, you can't even submit or preview the page. This also rules out any magic words. – Minh Nguyễn (talk, contribs) 05:26, 17 January 2007 (UTC)


 * Filed as Bug 8600. --Raymond 11:29, 18 January 2007 (UTC)

If it was possible to use template parameters in this it would make replacing existing template CSS hacks much easier. 131.111.195.8 18:08, 17 January 2007 (UTC)


 * Just wanted to note that using as part of the image name also doesn't work.  Trying to develope an imagemaped element table at Wikipedia:Template talk:Elementbox header.  I'll just use a single elements name while putting together the long list of coordinates, but this needs to be fixed if it's to be usefull for this particular (and other) applications.  Otherwise, this is Great, especially the auto coordinat resizing! --D0li0 04:27, 23 January 2007 (UTC)
 * Would love it too to see template substitution for the links working --202.134.25.5 09:16, 1 April 2007 (UTC)

Does not work in Opera (round missing)
The coordinates are rendered as double values (e.g. ) which is useless and causes errors in some browsers. For example, in Opera all circle areas are broken. Please  all coordinates. Thank you. --TM


 * I checked it in Konqueror 3.5.5, Firefox 2.0.0.1 and the Opera 9.1, all on Linux. I can confirm that the imagemap does not work correctly in Opera. Konqueror and Firefox work great. Anyhow I really like to thank the developer who made this possible, the possibilities are really great with this extension. jeroenvrp 03:06, 14 January 2007 (UTC)

Polygons
How polygons should be described? Can you give an example? I tried to define Display and Keyboard on the example, but it does not work, probably coordinates are wrong :( Maximaximax 10:10, 16 January 2007 (UTC) PS. Polygons I created with Map This. Maximaximax 10:14, 16 January 2007 (UTC)

Look at the example. I made 2 polygons - for display and keyboard, but they are wrong - only keyboard is shown and in wrong place:

Output of this example:

What is also strange - on the original example (with circle and square) it shows only display but no keyboard: Output of this example:


 * I can confirm this. jeroenvrp 12:42, 18 January 2007 (UTC)


 * So, can anybody help me? Explain what to do or fix the plugin? Maximaximax 07:39, 21 January 2007 (UTC)

This appears to work:

Things to note:
 * poly coords do not take commas.
 * poly-s are defined prior to any other shapes
 * the image is left full-size

Once you get past the documentation problem involving commas, the problem is that the script is not re-initializing its list of coordinates prior to parsing poly coordinates. Thus, when parsing a poly it starts with the previous shape's coordinate list and adds the poly's coordinates to it. If you leave the image full-size, then each subsequent poly is the aggregate of all the previous poly's, but you don't generally notice because the earlier ones are on top. If you're scaling, then each subsequent poly starts with a scaled version of the previous poly</tt>, which gets kinda weird.

If you're interested in fixing it, you might insert in ImageMap_body.php</tt> right after case 'poly': the line $coords = array;

Mine now looks like this (lines 140-146) }                                       break; case 'poly': $coords = array; /*<<<FIX*/ $coord = strtok( " \t" ); while ( $coord !== false ) { $coords[] = $coord;

Piped links
The documentation says that the format  should work. However, once I place that in the call to imagemap, the extension has the same issue that we've seen with curly braces: you can't submit or preview the page. – Minh Nguyễn (talk, contribs) 05:29, 17 January 2007 (UTC)

Longdesc not working
In my screen reader JAWS, when I encounter an image with a long description, I can press enter to hear the description. That doesn't work at the moment - when using the example on the page, I get with the extra " " in the address. I don't see a problem with using the extension otherwise as long as sensible image descriptions are used. Graham87 07:22, 17 January 2007 (UTC)
 * Filed as bug 8667. Graham87 03:25, 18 January 2007 (UTC)

Image description link size

 * Would it be possible to add a way to reduce the size of the image description link? Currently existing 'clickable images' using template hacks are generally used for small icons. When the ImageMap is applied to these the link for the image description page winds up covering a large part of the image. The sister projects links on the en-wikip 'Main Page' are a good example of this. --12.42.50.51 15:27, 17 January 2007 (UTC)


 * Also, it would be nice if it were possible to use:

or


 * Currently you have to specify a rectangle, circle, or polygon region before you can set a default for the rest of the image... but 99.99% of the time people are going to want the entire image to be clickable and link to a single location. --12.42.50.51 15:34, 17 January 2007 (UTC)


 * filed as Bug 8603. --Raymond 11:27, 18 January 2007 (UTC)
 * Quick hack for the default is:

→ Aza Toth 22:32, 11 March 2007 (UTC)
 * Another issue, if 'imagemap' is used within a template it does not seem to be able to handle parameters. That is, at the end of the call to  . – Minh Nguyễn (talk, contribs) 19:29, 17 January 2007 (UTC)

Inline use
First of all, thanks to TimStarling for this fantastic and long-awaited extension! It is really handy. However, there is one (minor) problem with it: It can't be used inline. If I want a line that links a country's flag to the country (instead of the image, of course), then write something next to the flag, that text will come one liner further down. See what I mean here:


 * Nauru

The possibility to use it in templates would also be handy. Otherwise it is excellent. Thanks for making it! Jon Harald Søby 20:16, 18 January 2007 (UTC)

Try floating the image:


 * Nauru

It's not very flexible, but it works for displaying flags next to countries' names.

– Minh Nguyễn (talk, contribs) 20:01, 20 January 2007 (UTC)


 * Inline use is possible with this extension. It is explained in the German Wikipedia: see here and here. --WIKImaniac 13:09, 3 August 2007 (UTC)

Get no link
Can anyone explain why this doesn't work? I am trying to link the big logo image in the center to a page. But using Thanks, Cocjh1 18:49, 21 January 2007 (UTC)

I was also looking for this function. Is it coming soon? Otherwise, thanks for good work!

Anchors
This doesn't seem to work with anchor links either e.g.

gives with a link to http://www.mediawiki.org/wiki/ rather than. the wub "?!"  16:25, 22 January 2007 (UTC)


 * Noticed this is bug 8917. the wub "?!"  18:52, 1 March 2007 (UTC)

Dutch Translation
I don't know were or how to post it so I put it here, you are free to movie to another more appropiate location:

I have made a Dutch translation for the ImageMap extension which could be incorporated in a later version: /* Dutch (Erik van Berkum) */ 'nl' => array( 'imagemap_no_image'            => '&lt;imagemap&gt;: moet een afbeelding specificeren in de eerste  regel', 'imagemap_invalid_image'        => '&lt;imagemap&gt;: afbeelding bestaat niet of er is een spelfout', 'imagemap_no_link'              => '&lt;imagemap&gt;: ongeldige link gevonden aan het eind van de regel $1', 'imagemap_invalid_title'        => '&lt;imagemap&gt;: ongeldige titel in de link bij regel $1', 'imagemap_missing_coord'        => '&lt;imagemap&gt;: niet genoeg coordinaten voor een vorm bij regel $1', 'imagemap_unrecognised_shape'   => '&lt;imagemap&gt;: de vorm wordt niet herkent bij regel $1, elke lijn moet starten met een van de volgende: '.								   'default, rechthoek, circel or poly', 'imagemap_no_areas'             => '&lt;imagemap&gt;: op zijn minst een gebied moet gespecificeerd worden', 'imagemap_invalid_coord'        => '&lt;imagemap&gt;: ongeldige coordinaat bij regel $1, het moet een nummer zijn', 'imagemap_invalid_desc'        => '&lt;imagemap&gt;: ongeldige desc specificatie, moet een van de volgende zijn: $1', 'imagemap_description'         => 'Over deze afbeelding', 'imagemap_desc_types'          => 'boven-rechts, beneden-rechts, bodem-links, boven-links, geen', ),
 * 1) Note to translators: keep the same order

Possible bug report
I've discovered why some of the click maps seem to be far too small: The pixel co-ordinates specified are for the original-sized image, not for the image as resized by this tag. Since this tag is itself resizing images, and since the image map coordinates come after the resize statement, shouldn't the co-ordinates refer to the transformed pixels rather than the original ones? 18:09, 23 January 2007 (UTC) Rawling from Wikipedia
 * Well, I've noticed this is explicitly referenced on the main page, so I'll just leave now. Hopefully this might explain it if, like me, someone else fails to notice... 18:36, 23 January 2007 (UTC) Rawling from Wikipedia

Bug 8835: No links from image caption
Filed as |bug 8835:

Try this from within Wikipedia (the links from the image won't lead anywhere in MediaWiki):

Urhixidur 20:40, 30 January 2007 (UTC)

Installation Instructions
I have copied these files into extensions/ImageMap and added the necessary line to LocalSettings.php, however the example produces no image and no error messages.

Could someone provide a list of the steps necessary to enable this extension.

Many Thanks RGuest 22:44, 4 February 2007 (UTC)

Done. --GunterS 14:24, 10 February 2007 (UTC)

Another imagemap variant
I've developed an ImageMap extension at the same time and published documentation before this was published. In my opinion I was ready before all of this was posted. This seems to be an accident or a mistake. I do not like to work at something another guy already coded. I searched all extension sources and MediaWiki and I've not found an imagemap extension at the end of January 2007. Than I started to write an extension at my own. The major benefit of my work compared to this imagemap extension is that using my extension a user can use kImageMapEditor to create imagemaps. This is just a huge benefit compared to this extension.

GeraldR


 * There is also Shannon McNaught's version that is older than yours or Tim's.
 * I'm currently writing a php program to convert a generic HTML file with <MAP>...</MAP> included into the map tag format that Tim's ImageMap extension uses. I have a bunch of wiki articles that use the older ImageMap format with files and this will allow me to convert them.  As well, it will allow me to convert files generated by generic Map editors for use with Tim's ImageMap.
 * I was also thinking of taking the two ImageMap extensions and merging them into a single extension so that one can use either format - external files with map data uploaded to the wiki (McNaught's)or imbedded map tags (Tim's). I wonder if there'd be any interest?  Michael Daly 19:24, 25 March 2007 (UTC)
 * I've done this as Extension:ImageMap (Alternate). Michael Daly 05:51, 5 May 2007 (UTC)

No image found: more information
I added the name of the image to the error message. Makes it easier to find the missing image.

// ImageMap_body.php $domDoc = DOMDocument::loadXML( $imageHTML ); $xpath = new DOMXPath( $domDoc ); $imgs = $xpath->query( '//img' ); if ( !$imgs->length ) { return self::error( 'imagemap_invalid_image' . ': ' . $image ); // change this line }


 * This fix will break the internationalization. The text 'imagemap_invalid_image' is the key to a table that contains the full text of the message in the user's language.  There is a better way to do this but it requires a change to the error messages. Michael Daly 07:09, 12 May 2007 (UTC)

MediaWiki 1.8.2
I found that it works in 1.8.2 also.


 * I get "Table 'wikidb.mw_cur' doesn't exist (localhost)" in MediaWiki 1.8.2 -- Adrianm, 28 February 2007


 * the cur table hasn't been used since the days of 1.4 - i find it unlikely this extension is using it (in fact, it does not appear to use any direct db access at all). So that error must be caused by something else. -- Duesentrieb ⇌ 10:26, 28 February 2007 (UTC)


 * thanks, I now get: "Class 'DOMDocument' not found", even though this class should be included in PHP 5 (I am using PHP 5.1.6) -- Adrianm, 2 March 2007

Eliminate Case Sensitive Shape Names
I added a couple of lines to ImageMap_body.php: here: $cmd = strtok( $line, " \t" ); $cmd = strtolower( $cmd ) ; and here: $shape = strtok( $shapeSpec, " \t" ); $shape = strtolower( $shape ) ;
 * 1) Handle desc spec
 * 1) ignore case
 * 1) Tokenize shape spec
 * 1) ignore case

to eliminate case sensitivity in the shape parameters - this to make it easier to convert from Shannon McNaught's older version of ImageMap to this one.

Thanks for the extension! Michael Daly 21:46, 7 March 2007 (UTC)

Fallback for mobile phones etc?
Just wondering how the image maps behave on less capable browsers like mobile phones etc. I'm a bit concerned that lists of links on Wikipedia are being replaced by image maps, without regard for browsers that can't render them (or in which clicking on a link in an image is basically impossible). If this is a valid concern, we might need a policy like "Every image map should be accompanied by a link to an equivalent list of the links"? Stevage 13:26, 11 March 2007 (UTC)

Single Area / clickable image
It would be nice if you could make clickable images easily by just giving the default area. Now you have to specify also a dummy rect area. And the default does not seem to work (bug?)

Can do!
I believe that we could enable clickable images simply by removing the test that requires at least one area to be defined. Ie. in, remove these lines starting about line 190:

if ( $output == '' ) { return self::error( 'imagemap_no_areas' ); }

This works for me, at least on MW 1.9.3:

I think this would be useful, and I can't see any harm. JohanTheGhost 19:49, 4 April 2007 (UTC)
 * This is in the latest release of ImageMap. BTW - the above patch is not "safe" as it prevents a check on no imput at all!  The fixed version has a safer check. Michael Daly 05:54, 5 May 2007 (UTC)

Extension extension
Hi Tim. Great extension!

I have a question:
 * Is it possible for a mapped area to trigger "Lupin's popups" like the unmapped area does? Or is that a question for Lupin?

And 2 really cool additions that should excite and intrigue you :->
 * 1) add a color-key (or similar) to individual areas. (Ambitiously with a "legend".)


 * 2) add an optional "detail" field to ImageMap such that a sub map will be displayed. E.g. for a detailed "ImageMap:Countries of the world allow a grab of (x1,y1, x2,y2) to display just an ImageMap-ed detail of central Africa.  (Even if the sub-map has to be created as a seperate image, allows the use of the larger ImageMap coords.)

Think of the possibilities! A single, really detailed map of the world/motherboard/whatever that can/would be populated as needed and grabbed willy-nilly the next time someone needs a submap. Now, a sub-map has to be re-ImageMap-ed all over again.

Don't those sound like fun???? --Saintrain 02:40, 2 April 2007 (UTC)

Other formats than JPEG?
I noticed that png-images are not working as image-source. Could this be changed?


 * This extension works just fine with png, gif and jpg. Perhaps your problem is that your installation does not premit png.  In DefaultSettings.php, you have the valid uploadable file extensions with


 * $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg');


 * If png isn't in there, copy the line into LocalSettings.php and change it to include png. Michael Daly 16:25, 13 May 2007 (UTC)

Enhance extension/fix bug
Linking to internal page works fine:

rect x1 y1 x2 y2 internalPage

But linking to section within internal page does not work. Instead of arriving to someSection you arrive to the top of the internalPage:

rect x1 y1 x2 y2 internalPage

Code fix
Look in Imagemap_body.php and find a line of code that looks like:

$attribs['href']  = $title->escapeLocalURL;

and change it to add the following end.:

$attribs['href']  = $title->escapeLocalURL. $title->getFragmentForURL; I've updated my version (Extension:ImageMap (Alternate)) with the same fix. Michael Daly 10:19, 18 April 2007 (UTC)

This fix is in the latest version of ImageMap Michael Daly 05:56, 5 May 2007 (UTC)


 * Fixed with 21299. --Raymond 08:12, 10 May 2007 (UTC)

Php Error
Right now the code works, but produces the following PHP error: [Wed Apr 18 16:03:03 2007] [error] [client 10.34.18.28] PHP Notice: Undefined variable: extLinks in /x/eng/wiki/xwikid/extensions/ImageMap/ImageMap_body.php on line 292 [Wed Apr 18 16:03:03 2007] [error] [client 10.34.18.28] PHP Warning: Invalid argument supplied for foreach in /x/eng/wiki/xwikid/extensions/ImageMap/ImageMap_body.php on line 292


 * Fixed with 21360. --Raymond 08:11, 10 May 2007 (UTC)

Special chars in external url
It seem extension done incorrectly when there are some special characters in external url. For example:

The link will be http://en.wikipedia.org/w/index.php?title=Main_Page &amp;amp; action=edit.

To correct this problem, just remove htmlspecialchars for $title in case of external linking.

--- ImageMap_body.php  (revision 22019) +++ ImageMap_body.php  (working copy) @@ -129,11 +129,11 @@                               $alt = $title->getFullText; } elseif ( $wgImageMapAllowExternalLinks && ( in_array( substr( $link, 1 , strpos($link, '//' )+1 ) , $wgUrlProtocols ) || in_array( substr( $link , 1 , strpos($link, ':' ) ) , $wgUrlProtocols ) ) ) { if ( preg_match( '/^ \[ ([^\s]*+)  \s  ([^\]]*+)  \] \w* $ /x', $link, $m ) ) { -                                      $title = htmlspecialchars( $m[1] ); +                                      $title = $m[1]; $alt = htmlspecialchars( trim( $m[2] ) ); $externLink = true; } elseif ( preg_match( '/^ \[ ([^\]]*+) \] \w* $ /x', $link, $m ) ) { -                                      $title = htmlspecialchars( $m[1] ); +                                      $title = $m[1]; $alt = htmlspecialchars( trim( $m[1] ) ); $externLink = true; }


 * Please open a new bug at http://bugzilla.wikimedia.org and attach your patch. Thanks. --Raymond 08:10, 10 May 2007 (UTC)

Possible Bug ?
I get the next bug : Warning: call_user_func_array: First argumented is expected to be a valid callback, 'ImageMap::render' was given in includes/Parser.php on line 468

The code is:

And nothing is displayed, anyone could help me? Thanks !

please support external links in the new version
Current version is only supporting internal links. Please support external links, too. --Yes0song 13:26, 14 June 2007 (UTC)


 * External links are already supported, but you have to enable them with "$wgImageMapAllowExternalLinks = true;".
 * See Extension:ImageMap


 * Oh, "NOTE: This parameter has been removed in the latest version (Revision 23292). It now always permits external links." is wrote on Extension:ImageMap. I think the extension should re-support external links and hope that the Wikimedia Foundation will set the parameter "true" on all the Wikis hosted by the foundation. --Yes0song 08:29, 13 July 2007 (UTC)


 * This is not an issue with the extension - it is an issue with Wikipedia. You can make the request to enable external links on Wikipedia via Mediawiki Bugzilla.  Michael Daly 17:35, 14 July 2007 (UTC)


 * I misread "now" in "It now always permits..." as "not". --Yes0song 04:20, 15 July 2007 (UTC)

Integration in default mediawiki distribution
Couldn't it be possible to implement this (very useful) function natively into mediawiki? It doesn't have to be exactly in this form, but I can think of something like: ...therefore simply allowing image inside a usual link would also be an intuitive way for authors to include images within links.

error
Fatal error: Call to undefined method Title::getFragmentForURL in /extensions/ImageMap/ImageMap_body.php on line 199

what's the problem?
 * What version of Mediawiki are you running? Michael Daly 17:37, 23 June 2007 (UTC)


 * I'm having the same problem. Using fully patched Ubuntu server (mediawiki 1.7) with no other extensions, and subversion rev 23292130.102.0.178 06:39, 28 June 2007 (UTC)
 * Read the description again, particularly the part where it says that this extension works with MediaWiki version 1.9 and later. HTH HAND —Phil | Talk 07:20, 28 June 2007 (UTC)

I was just about to correct myself. Thanks 130.102.0.178 07:39, 28 June 2007 (UTC)

Port to Mediawiki 1.7
Hi

I was unable to find any information on porting this extension to mediawiki 1.7 here or anywhere else.

I was however able to do this myself. The two necessary changes are outlined below. Hopefully they will be useful to someone. '''Only two changes are necessary to the file ImageMap_body.php</tt>
 * 1. Change call $title->getFragmentForURL</tt> to $title->getFragment</tt> (line 199)
 * 2. Change call $parser->mOutput->addLink( $title );</tt> to $parser->mOutput->addLink( $title, null );</tt> (line 295)

Hope this helps!

--208.17.34.25 15:21, 11 July 2007 (UTC)