Printable View
I don't use image handler, I'm afraid I would have to leave that to someone else to deal with.Quote:
Originally Posted by chadderuski
Pretty chuffed with this, now works for any standard zen cart set up with any type of image set up, can't ask for much more than that! ;-)
When I get time I'll tidy up all te code and zip it up into a
Image Swap with JQZoom Version 1.0 for ZC1.5.1
:clap::clap:
I just need to fix the disabled JavaScript bug and that's it - oh and some instructions..
Opps!
You reminded me of something: When java is turned off, the additional images show TWICE.
Sorry!
Yes that's the bug I need to fix. Should be easy to fixQuote:
Originally Posted by chadderuski
I did a test with IH4, and as expected it doesn't quite work out of the box. On my test site, the only one that work was the product that I have made _LRG and _MED images.
Now, a quick fix that doesn't seem to break IH4 is to just replace the additional_images.php and main_product_image.php files. It's a start... until we can find how to merge the two mods
Not used it so excuse my ignorance? What would the benefit of merging the mods? Doesn't image handler just do hover for large image? The only thing I thought it does in addition is the watermark stuff? Am I missing the point?
Is it because image handler does the hover thing on all product listing images too? If so what you just suggested is the fix. A merge would not be required.
This mod would deal with the product info page and those two files from image handler should just not be installed.
Image handler from what I saw used a completely different Inge selection logic and in my opinion like the standard zen cart image testing is slightly flawed.
This mod now deals fully with all image scenarios
Small
Small and medium
Small and large
Small medium and large
Sub ditectories
And all the above for both main image and additional image.
Zen cart out of the box doesn't
@Phil,
Great work. If you have an up to date version can you post it? Or is the one above the most up to date? I will try and have a look over the weekend.
What are the remaining issues?
I think if it does not play nice with Image handler then that is a major stumbling block. So will have a look at that.
The the javascript escaping?
And what else.
Nick, TBH I don't know exactly what image handler odes other than give a hover for larger image facility and a watermark facility?Quote:
Originally Posted by niccol
as per my last post, these files do not affect image handler, they simply replace the job of image handler on the product listing page. However in terms of the watermarking I don't know at what level that is done so maybe that feature would be removed if certain merging is not done.
That said, as I mentioned above the logic of testing for images existing on the server both on image handler and out of the box zencart was flawed as which I have fixed in the code in these zoom files.
regarding whats left to do. Don't worry about the script links, i'll look at sorting that, then as far as i'm concerned its good to go other than instructions for installation and configuration options.
The last zip I uploaded is the latest with the exception of the tpl_modules_main_product_image.php file amendment I have made a few posts back which now deals with keeping different size images aspect ratio.
If you give me a detailed run down on the purpose of image handler and why it's so important i'll have a think it there is any need to merge some files, other than that I think this is great standalone.
P.S - have a good read through the posts since you were last on, we have made some great improvements to ensure full compatibility with any type of zenner... :D
The core functionality of Imagehandler is that it creates scaled versions of the images. So, what you do is upload a large image ( in size not as a _LRG file) . What Zen would do then is server that image whenever requested. Which results in the big image being served even when a small image is needed. Which burns bandwidth.
So, what image handler does is create scaled versions of the images. So when the small version of image.jpg is required it creates it. Then it uses that small scaled image whenever required. So, it means that sites are much much faster and bandwidth is not burnt.
Most developers will put image handler on the site as the very first module they use. And most people should too, to be honest. There is a bit of a logic which says that this functionality should be rolled into the core of Zen ( like prestacart, magento, cs cart, open cart, wordpress ) but I am not going to get involved in that. So, alot of people would say that Zen is not complete without IH.
So, that is kind of why I think that you have to support it to make this a really good module as opposed to a functional one.
The thing about IH is that it creates the images when they are needed. Which can cause issues with javascript because the 'medium' version of a file may not actually exist until it is required. Javascript does not send a request the same way as html does so the image may not be created. Which means that the zoom just won't work.
The usual way to bypass that is to pre-load the images low down on the page. that way they are created before the zoom needs them. but as you know that in itself creates bandwidth issues.
IH has some other features - some of which are useful and some of which are not all that useful and the people managing it would probably ditch if they could.
- It creates lovely lovely hover effects. Most developers hate these but the public seem to like them
- It adds a better interface for uploading additional images
There are probably a few others that I am over-looking.
But the core functionality is scaling images to the right size before they are served.
I have gone on record as saying that I am not a huge fan of IH. ( Just because it is cumbersome for what it does ) I use my home grown alternative. But some kind of server side image management is pretty much a necessity for most users.
So somehow it actually creates an actual new image file?