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

Quote:

---

Originally Posted by 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. :)

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?

Quote:

---

Originally Posted by 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?

---

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..

I have a question. I LOVE IH. I use it with about 900 products. It's a HUGE time-saver.

I have it installed on a custom template, and I would like to switch templates. IH is of course installed under the template I'm currently using. If I were to switch templates, I would need to re-install IH on the new template, correct? Would it recognize the images already on my server (as they were created with IH)? Would thumbnails, etc. be lost?

Quote:

---

Originally Posted by meljen

I have a question. I LOVE IH. I use it with about 900 products. It's a HUGE time-saver.

I have it installed on a custom template, and I would like to switch templates. IH is of course installed under the template I'm currently using. If I were to switch templates, I would need to re-install IH on the new template, correct?

---

In effect, yes it would need to be incorporated into your new template (See the readme).

Quote:

---

Originally Posted by meljen

Would it recognize the images already on my server (as they were created with IH)?

---

Absolutely should. (See the readme)

Quote:

---

Originally Posted by meljen

Would thumbnails, etc. be lost?

---

Anything that is/was generated by IH will not be lost, now if your "custom template" does something special outside of what IH handles/provides then that is outside the scope of this thread. But again, see the readme.
I would advise that you test your new template on a "offline" store before making the change. Don't want to lose business because of something that might be wrong in your new template. I will say it is somewhat exciting to make a switch like that and see that it works, while being concerned that it might not. A sort of stage fright.

We have been informed of a minor XSS flaw that exists within the IH4 code for v1.5.x

Mitigation for the flaw has been posted to the IH4 code in the plugins. Please go to the plugins page to download and update your store..

thanks to PaulM for notifying us about the flaw.

Mozilla doesn't like the unbalanced tree being generated via: document.write(); in imagehover.js. This:

document.write('<div id="trailimageid">');
document.write('</div>');

Should be this:

document.write('<div id="trailimageid"></div>');

Is there a reason for breaking it out into two statements?

Quote:

---

Originally Posted by mrbojangles

Mozilla doesn't like the unbalanced tree being generated via: document.write(); in imagehover.js.

---

Can you explain how you came to that conclusion? What were the symptoms that caused you to investigate? What were the findings that brought you to the conclusion you posted?

Quote:

---

Originally Posted by DrByte

Can you explain how you came to that conclusion? What were the symptoms that caused you to investigate? What were the findings that brought you to the conclusion you posted?

---

Mozilla gave warning in console. I did not notice behavior which would indicate a problem, but Mozilla does not recommend it as it can potentially cause unwanted behavior.

Quote:

---

Originally Posted by mrbojangles

Mozilla doesn't like the unbalanced tree being generated via: document.write(); in imagehover.js. This:

document.write('<div id="trailimageid">');
document.write('</div>');

Should be this:

document.write('<div id="trailimageid"></div>');

Is there a reason for breaking it out into two statements?

---

Quote:

---

Originally Posted by mrbojangles

Mozilla gave warning in console. I did not notice behavior which would indicate a problem, but Mozilla does not recommend it as it can potentially cause unwanted behavior.

---

Thanks for clarifying.

They might have been split up just as a matter of inheritance from previous versions of the plugin.

No reason not to close them up, besides it'll run faster as one statement anyway.