Gallery 1.5.8 Imagemap - problems and fixes, still need help

Found some bugs in imagemap.php that I've posted along with my corrections on my own install, but need some help with javascript changes for displaying the maps when editing existing maps.

First up, here's the version information requested.

Gallery URL (optional but very useful): not yet live
Gallery version: 1.5.8 (downloaded from this site 4 days ago)
Apache version: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.1.3 Python/2.3.5 PHP/5.1.6-0.dotdeb.2 mod_perl/1.999.21 Perl/v5.8.4
PHP version (don't just say PHP 4, please): PHP v5.1.6-0.dotdeb.2
Graphics Toolkit: ImageMagick 6.0.6
Operating system: Debian Sarge 2.6.8-3-386
Web browser/version (if applicable): IE7/FF2

I've just spent the weekend working on upgrading my existing Gallery 1.4.4-pl6 install with a number of customisations (I did a lot of tinkering to get it working the way I wanted) along with PHP Nuke 7.6. I was particularly interested in the Imagemaps feature, but discovered that it didn't actually work. I've tinkered with the code and it seems to work now, but I want to check what I've done won't affect anything else. All changes are to imagemap.php

1) Submitting an imagemap always took me to the gallery home page. I realised that this was due to it checking for $gallery->session->albumName at the start, and this was blank according to my debugging. I added a hidden form field called set_albumName with the current album name to the imagemap intro and that cured that step:

Replace this

echo makeFormIntro('imagemap.php',
    array('name' => 'areas'),
    array('index' => $index, 'formaction' => '')
    );

with this

echo makeFormIntro('imagemap.php',
    array('name' => 'areas'),
    array('index' => $index, 'formaction' => '','set_albumName' => $gallery->session->albumName)
    );

2) Every time I submitted a new map, I got an error stating that it need at least 3 points. This is due to the sizeof functions being called on the raw X and Y strings, not the exploded arrays.

Replace:

			if(sizeof($xvals) >= 3 && sizeof($yvals) >= 3) {

				$xcoords = explode(',', $xvals);
				$ycoords = explode(',', $yvals);

with this:

			$xcoords = explode(',', $xvals);
			$ycoords = explode(',', $yvals);

			if(sizeof($xcoords) >= 3 && sizeof($ycoords) >= 3) {

3) Finally, the text entered was not being passed. This is due to the embedded form field for the text not having a name when PHP Nuke is used (it doesn't affect the form otherwise).

Replace:

	<?php if($GALLERY_EMBEDDED_INSIDE_TYPE != 'phpnuke') { ?>
	<textarea name="areatext" id="areatext" cols="40" rows="5"></textarea>
	<?php } else { ?>
	<input type="text" id="areatext" size="40">
	<?php } ?>

with this:

	<?php if($GALLERY_EMBEDDED_INSIDE_TYPE != 'phpnuke') { ?>
	<textarea name="areatext" id="areatext" cols="40" rows="5"></textarea>
	<?php } else { ?>
	<input type="text" id="areatext" name="areatext" size="40">
	<?php } ?>

(only the second to last line in the above is changed, but I posted it all to show how easy it is to miss it.

So the upshot is I now have imagemaps working. The downside is that if click on a map in the imagemaps edit page, the map is drawn right near the top of the screen, not on the image. It looks like there is no X or Y offset being added to the position when drawing. I've yet to start digging around in the javascript, so if anyone has already done this and can post the required code changes it would be a great help.

I hope the fixes I've posted above help out anyone else with the same issue.

I've only taken the imagemap parts across, it's going to take me a day to two to implement all my mods into the newest build. Why isn't 1.5.9 available for download rather than 1.5.8 from the download page? Would have saved me a lot of time patching that instead of working with 1.5.8 and now having to patch again to 1.5.9.

It still isn't working though - it's still directing to the gallery home page, which appears to be due to (1) in my original post, and it's still drawing the imagemaps as if the image is at 0,0 on the page so it's not taking into account the actual position of the image due to the surrounding HTML. Which part of the code handles the positioning of the image maps? I'm on PHP Nuke 7.6, not 8.1, so there might be some oddity in the script code being used. I'm getting no javascript in the browser, so it doesn't appear that something isn't being initialised properly.

I've noticed in the imagemap.js code that when the updatePictureAndArea() function is called that the coords are being passed to the drawPolyon method without the minX and minY values being added to each coord. However, the initPaintArea() and dpl_mouse_click() functions do add minX and minY to the coords (in dpl_mouse_click the coords already have minX and minY included, those values are removed to create the actual imagemap coords for the imgxVals and imgyVals arrays to be stored with the image)

I use php5 too (notice in my original post I'm on PHP v5.1.6-0.dotdeb.2), Nuke 7.6 works fine. I haven't moved to a newer version of Nuke yet due to a mass of custom code that I'd need to move over, but I keep on top of security patches.

As to my latest post, it does appear that there is a problem in IE7 in strict mode that means that the map coords are not being updated correctly at the initPaintArea() step. This is not a Nuke issue, it looks like a Gallery + IE7 strict mode issue. The maps are being loaded, but the image offsets appear to not be calculated correctly. I'm testing a bit more, hopefully I'll find the fix and be able to post it. I've tested in Firefox 2 and the imagemaps are being loaded in the correct place - so there's a glitch in the imagemap.js file when dealing with IE7. I've added an alert to show the values of minX and minY in initPaintArea; on FF2 they are 184 and 497 for the pic I'm testing with, but in IE7 they are 5 and 5 - definitely a problem. It's odd, the FF2 maps also appear to be slightly off from where I defined them too, maybe 5 px in each direction.

I've been tinkering here with the js and can't solve it myself. As it is 50% of my users are on IE7, and another 10% ish still on IE6. If I find a solution I'll let you know.

Given that I'm using it embedded, instead I changed the existing line to

window.onload = initPaintArea;

This works in IE7, and doesn't require messing with the Nuke code that does all the body handling. Thanks for the help

I did find another bug in imagemap.js though, function dpl_mouse_click.

xPos += document[docEl].scrollTop;

should be

xPos += document[docEl].scrollLeft;

as otherwise when you scroll down the page, the points shift to the right. yPos is correctly adding scrollTop, so xPos needs scrollLeft.

Sorry, I fixed a couple of typos as I was posting and then also edited that 2nd to last post as you'd posted a reply before I'd posted my edits, so I thought I'd split them out in case you didn't notice them. Any particular reason why the forum posts for every edit? Especially for posting bugs and having to adjust typos when you notice you've typed something wrong, can't the forum be configured to only send a new post and not every edit?

While I'm still working on customising the imagemaps, I have a query - is there a quick way to disable alt text for images with an imagemap? Often the alt text popup in IE gets in the way, and I'd rather just have it removed for images that have an imagemap and only retain for it for those that don't.

Thanks, that works great.