Image Handler 4 (for v1.5.x) Support Thread

[mc12345678]

Diva & et al,

Having a problem with 2 of 3 pics uploaded and IH4 handling them.
ZC 1.5.0 installed, Light Box and IH4 are the image handlers.

Web page having difficulties is:
http://www.pugsugottasave.org/shop/D...ly-and-Growler

When clicking on the current main image to view the larger image, light box can't seem to pull up the photo, the first additional image (at the bottom of the screen) does not display when hovered on, but the second additional image does. Also, can see that a bmz_cache record does not show when hovering over the first additional, but does when looking at the second additional image.

Just realized that also I have CEON URI rewrite installed, neither the images nor bmz_cache directories are currently bypassed by the .htaccess file. Um, things I have tried have been to swap the sequence of pictures, but it is always the photo that is currently last that will work while the others will not. I have also tried using microsoft paint to open and resave the files as JPG files to see if there was some background code that is affecting the presentation of the pictures. So, if I put the picture that is currently the last photo as the first, I can click on the photo and it will show as large in the light box, but neither of the other two will show at all (on hover or click). I have also tried renaming the files prior to upload and as part of first assignment.

If you goto http://www.pugsugottasave.org/shop/Donation and look through to Holly and Growler and hover over the image you will see the same issue described about hover not presenting the photo. I do not seem to have this on any other photos.

What other info might be of benefit? I don't have any error logs on the issue as shown through the Display Debug logs addin. I have also only assigned a maximum dimension for the width of my large photos. Didn't try assigning only a maximum height yet. (Previously had both max width and height assigned.)

[mc12345678]

Nevermind, I finally figured it out.

In my .htaccess I had allow and deny rules that escaped extensions of jpg, gif, png, etc...; however, they did not escape JPG, GIF, PNG, ETC...

As a result, although one of the files was able to "make it through", the others that for whatever reason do not show up as being in the bmz_cache directory, and were in fact in the images directory were not being presented forward from the server.

Problem fixed... Whew. Didn't think it was directly related to the programming, but wasn't sure what oddity was being introduced to prevent Image Handler from doing its thing. Still not sure why the files don't show up as being from the bmz_cache directory, but really more concerned about all of these great addons working for our visitor(s).

[DrByte]

Hopefully you're working towards converting your images to use lowercase names, since that's the contemporary approach these days.

[DivaVocals]

Hopefully you're working towards converting your images to use lowercase names, since that's the contemporary approach these days.

**nods in agreement** and there's a ton of free programs out there that can handle bulk image renaming in short order..

[mc12345678]

Yeah, as a result I went into my products database to see how many had the all uppercase extension. (From whence this came I don't know.) Don't have too many and was considering using a RegEx expression with a SQL query to replace it, but almost seems like it would take me longer to "remember" how to construct the two attributes than it would be for me to manually modify them. Fortunately our store isn't large; however, I do need to figure out how to not have this happen again after I have fixed them and then restore the .htaccess file to only address lower case extensions.

[mc12345678]

Yeah, as a result I went into my products database to see how many had the all uppercase extension. (From whence this came I don't know.) Don't have too many and was considering using a RegEx expression with a SQL query to replace it, but almost seems like it would take me longer to "remember" how to construct the two attributes than it would be for me to manually modify them. Fortunately our store isn't large; however, I do need to figure out how to not have this happen again after I have fixed them and then restore the .htaccess file to only address lower case extensions.

Yup, definitely faster to manually modify in this case. Wondering if the capitalization comes from when I uploaded a photo from my cell phone. :/

I know that I had tried renaming the files to .jpeg, but of course that was one of the options in my htaccess file either, so all around in that case was not going to work then. Didn't try lowercase jpg when I was uploading and revising yesterday. Gotta keep all things working together and oh yeah, adopt and stay with standard rules. :)

[mc12345678]

Going back and looking at my configuration->images settings, had (purposefully at the time) settings for small, medium, and large extensions set as no change.

Do I understand the help file correctly that if I had set those to any of the three values that upon upload of a file with the incorrectly all capitalized extension all will be "okay"? Or am I too wishful?