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

[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?

[DivaVocals]

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?

No.. please re-review the readme for a detailed explanation of what those settings are really meant to do.. In short they have everything to do with setting the filetype of uploaded images..