If that is the case (that the configuration_group_id of 0 got removed) then there are likely other problems as there are a few ZC values (if I remember correctly there are three keys) that have historically defaulted to configuration_group_id of 0.
Printable View
You were right - I did find config settings with group id of 0 - dated a month after the upgrade. So the Version was not in the database any longer. I have to say that I don't like this. I wasn't aware of it and in a clean up effort I removed all 0 group ids from one site - a couple of years ago. A number of settings had gone in incorrectly and it had to be fixed. What other set the group id as 0 deliberately? The other three settings I found were from one of the edit orders mod. Sometimes what I learn after years of working with zen cart just astounds me!
Oh, and thanks, guys!
Check the ZC install sql. There are three options set with the gID of zero for ZC version 1.5.1, none were assigned in ZC version 1.5.3 or 1.5.4. There are several posts in the forum about it, unfortunately I haven't gone through to find them.
But I did scavenge a couple ZC installs to find the following. I don't have ZC 1.5.2 installed anywhere and typically disregard most things specifically related to it as it wasn't considered a production version.
In 1.5.1:
First:
Title: Product option type Select
Description: The number representing the Select type of product option.
Value: 0
Key: PRODUCTS_OPTIONS_TYPE_SELECT
Second:
Title: Upload prefix
Description: Prefix used to differentiate between upload options and other options
Value: upload_
Key: UPLOAD_PREFIX
Third:
Title: Text prefix
Description: Prefix used to differentiate between text option values and other option values
Value: txt_
Key: TEXT_PREFIX
These got moved into gID=6 in ZC 1.5.3 and beyond... So that problem shouldn't exist in the future (accidental erasure of gID=0 values affecting base ZC functionality).
As noted by mc12345678 and elsewhere on the forums, some third party modules as part of their install or uninstall were deleting all entries in gid=0 when the module was not previously installed.
These three I know were there for sure (would have to look to see about others). These directly relate to the handling and display of certain attribute types.
The problem was widespread enough to warrant adding code to Edit Orders 4.1.4 to handle the situation (when those three configuration options were missing it broke Edit Orders as Edit Orders works with and displays attributes). If these configuration options are missing from the database (not found anywhere in the configuration; the exact grouping "gid=x" does not matter), Edit Orders 4.1.4 will correct the problem by adding them back as configuration options.Quote:
...I wasn't aware of it and in a clean up effort I removed all 0 group ids from one site - a couple of years ago. A number of settings had gone in incorrectly and it had to be fixed. ... The other three settings I found were from one of the edit orders mod. ...
Good to know!
Hello. I recently installed IH on a fairly new 1.5.4 install. When I try to add images, I get this error:
Error!
Unable to determine the page link!
Function used:
zen_href_link('', '', 'NONSSL')
I found a few mentions of this in this thread, but no definite solutions. It was mentioned that improper filenames could lead to this. I renamed 3 images to ggg, hhh and kkk.jpg. So I don't think it has to do with improper filenames for my situation.
Anyone have any additional info on this error? Thank you.
Another common reason is incorrectly uploading images in the IH4 admin manager.. Usually because someone has tried to upload a large or small of medium image without uploading a DEFAULT image as you are supposed to do.. (and yeah this too has been posted, and I believe it might be included int he IH4 docs now too)
You will need to take us through in DETAILED step by step exactly what you were doing when you got this error.. And to be clear, when I say DETAILED, I mean tell me exactly what links or buttons you clicked, etc.. DON'T summarize it..
I just got past that error now. I deleted the main image and then uploaded all 3 new ones again, with IG4, without error.
But now I'm back to my original problem/question that led me to install IH a 2nd time. In the readme, in the section 'Prepare Your Site for Growth'. It says we can organize our images in folders. But I don't see how? The only way to add images is to upload from computer and it doesn't allow/ask what folder to put it in? If I upload through FTP, I can't link to the image on the server from IH. Is this the way IH works? Or is my install missing something?
Installed Image handler followed directions (which were fantastic especially for someone not so code smart)
Only 1 of the images has the hover effect and that same image is the only one that will show the watermark, on the website.
In the admin side all photos were showing watermark. I thought maybe a corrupt file so reloaded and still same issue. Then uninstalled and reloaded. Still same problem and even stranger same photo. Any advise would be so very appreciated.
mysticwytchescloset.com
Server Host: just91.justhost.com
Server OS: Linux 3.12.35.1418868052
Database: MySQL 5.5.41-37.0-log
HTTP Server: Apache
PHP Version: 5.4.34
Zen Cart 1.5.4 (New Installation)
Added installs:
Want Button Configuration, Facebook Open Graph Configuration, Facebook eCommerce Browser, Pinterest Pin It Button Configuration, Facebook Like Button Configuration, Easy Populate 4.
Nothing in error or debug log related to this website or database since the 17th of Feb
Thank you
ZC154
IH4 just stopped working??
Everything was working fine and now I can't get into IH, just get a message that says "No Image Handler information found"
In addition, can IH4 be re-installed without uninstalling? If IH4 is uninstalled and re-installed does that mean I would loose all my current product images?
Version in Zen Cart plugins section has NOT been updated to work with v1.5.4. Search the thread for the beta version in Github.. Still waiting for feedback from testers before releasing..
IH4 doesn't do anything to the original image files.. (which is clearly stated in the readme file..)
Hello DivaVocals,
Thank you very much for you image handler plugin, I have a minor question which I'm hopeing doesnt lead to an issue.
I have a clean build of zen cart 1.5.4 and the Winchester Black responsive template installed from this site.
I read your thread which mentions you have a beta build of IH for testing purposes only that supports ZC1.5.4, namely image handler v4.3.4 from your github repository.
Well I visited your github repo and downloaded v.4.3.2 by mistake as I forgot to change the default branch drop down tab from the default of master to the correct version of 4.3.4.
So I installed v4.3.2 by mistake, logged into admin and noticed nothing was being displayed at top of admin to say it had installed correctly which is when I retraced my steps and found out I installed the incorrect version. I then went to admin/tools/image handler4/•Uninstall Image Handler. (Please backup your site and database first) and it uninstalled everything fine.
I then uploaded correct version 4.3.4, logged into admin and received the message at the top that all the files have installed correctly. I've tested it and all appears to be working fine except when I look under admin/tools/image handler4, it says the version number 4.3.2 instead of v4.3.4.
Not sure if that's a mistake from my messup or just simply you havent updated the version number in the beta?
Thank you very much for your help.
Nathan
Unfortunately upon further inspection it does look like I've screwed something up as I'm no longer seeing the images under image handler, was previously. Have tried your uninstall script again and reupped 4.3.4. Still no luck, if you have any ideas would be extremely appreciated or worse comes to worse I'll restore the backup of the test site.
Thanks again.Attachment 15044
Was thinking that rather than wasting time trying to dissect, just restored and installed IH 4.3.4.
All working fine, thanks again for the plugin.
I am using Zencart 1.5.4 with Image Handler 4. I am designing a new website. When I started out I had a "default" image which would appear whenever I didn't have an individual image for a product (let's call it xlogo.jpg) I deleted xlogo.jpg, thinking it would just delete from one product but it deleted it from being the default placeholder image. How can I make xlogo.jpg my default image for my products again?
Also, I wanted to eleminate the extra product images which appear under the main product image when you click on the view product button. Would I go into the admin area--->configuration-->images--->product info no. of additional images per row and set that number to 0 from the default of 3?
Thanks. I appreciate your help.
Hi,
I'm running zen cart 1.5.4 and from reading through some earlier posts on this thread have found out that the correct version of image handler can be found on GitHub which is a beta version.
I am confused though as to which version to download because when choosing the version under 'brach' it shows the following;
branch: 'Master' - Updated for Zen Cart v1.5.4
branch: v4.3.4 - Update for v1.5.2 compatibility
Please can you clarify which is correct for the new zen cart 1.5.4 as from reading some posts it seems to be the v4.3.4 but looking at the GitHub site it is pointing towards the 'Master' version?
Thanks,
Mike
OK, I am running ZenCart 1.5.4. and would like to make an image the default image for all of the products in my cart which do not have a different image designated. Like a placeholder. This is about Image Maker specifically. How would you do it? If it's not possible, then please let me know. I have read the help section which came with it but this issue doesn't seem to be in there.
OK, thanks for clarifying.
Works perfect with latest version of zen. Only one confusion. IH4 does not show additional images with Previous and Next buttons, it only shows every additional image in popup windows, why so? It seems to be big mess.
Hi Guys, I'm running ZenCart v.1.5.1 with v.4.3.2 of Image Handler installed (everything is running smoothly) and I was wondering whether it's possible to implement a simple image swap that would work with IH. The image swap would only have to reveal (for example) one front angle image and one side angle image on mouseover (similar to what Aspinal of London has implemented on its website)? Usually, this is a relatively straight forward process (for example image1.jpg is replaced with image2.jpg on mouseover and image1.jpg is placed back when the mouse stops hovering). I've been trying to figure out whether a similar method could be used with IH, but I'm beginning to think that such as system is not possible due to the way IH handles and names images. So I was wondering whethere any possible alternatives might be possible (without basically having to rewrite large portions of IH)?
Your swapping module would have to be written in a way that it works with IH4.. This is not directly related to IH4 support, so I don't have an answer.. If this is a module you are using perhaps asking on their support thread would yield you a specific answer.. Or if you have code you are trying to use, you might be better served asking this question in a separate thread on the forum..
Hi DivaVocals, thanks for the response. I'm not using any image swapping modules at the moment. I don't think any 'out of the box' solutions work (or at least I haven't found them yet). Right now my biggest problem is that I don't really know where to begin. Since the images are cached you end up with image names such as "071d16fadbb5599266a0e5da558f3dc0.image.300x300.jpg" placed in in different folders such as bmz_cache/0/, bmz_cache/1/, bmz_cache/2/, etc.) So I don't know of any method that would allow me to 'capture' the secondary image (in part because I don't know what it's named). I think I'll ask in a separate thread to see if anyone can give me any pointers.
And you might want to start using the yet unreleased version of IH4 on my Github repo (search this thread for Github to find the post with the link).. no BIG changes except one.. IH4 will not name images without the MD5 hash obscuring of the image names.. Instead the image names are based on the original image name and the image dimensions..
Great, thanks!
Besides all that, it seems the swap process needs something known to swap with, the file naming/renaming occurs through program code, it really doesn't matter if the md5 hash or something else is used, if the same method of identifying the file is used consistently (with consideration of an image_handler involved) then this can be accomplished as well.
REALLY late in the game, but I thought that overall the md5 hash up to the renaming of the file itself made for a better directory structure/breakdown for having multiple images on a server, but I also haven't performed any serious analysis into the issue :(, so will continue with the good naming practices already employed. My "thought" was based on the expectation that such an analysis was performed upon implementation not just an implementation for some other reason potentially superfluous.
Ya lost me with that last part, but let me say this.. I have always thought that the MD5 hash made identification of images in the bmz_cache impossible.. It was virtually impossible to link anything with it's source image.. Also why why NOT give the cached images INTELLIGENT HUMAN SOUNDING names.. After all HUMANS need images names they can understand.. the machines don't care..
So it seemed to me that the md5 hash did two things. One it placed the image in a "wide" directory structure that would more than likely not result in two images having the same foldername (that's part of a hash' goal. But the second thing that I and. Many others don't agree with is that it renamed the file itself... So instead of shoes_205x205, it would be some mess of information pertinent to the "hash" and then the size... (That "mess" could have been one more directory path more with the actual filename left at the end, but that was not how it was implemented. I totally agree that the image itself should/could be provided in a sensical format (original filename plus perhaps some size indication). Further it would seem that the hash function would provide basically one unique directory path to the image and while not something sensical to us normal readers, wouldn't cause a problem with computer search tools.
Call it a balance between the two, again assuming that the hash provided a benefit beyond some computer science programmer showing that the possibility of applying a hash to a file structure. Beyond that, if the hash actually harmed the use of images (again I'm thinking of the filename remaining intact) for things of the internet, then let it be gone. But seems that there was a reason to employ it, one that may not be known any longer or perhaps is not as important as once thought.
The only reason a HASH would ever be needed would be if one wanted a "quick, but not perfect" COMPARE to see if one image was a copy of another image (to save on storage space). Only relevant if on a cheap host w/ limited space AND the end user was silly and uploaded multiple copies of the same image with different names or uploaded the same image to multiple different paths. Both can be avoided when necessary.
If I remember correctly (it has been a long time since I've looked at the Image Handler code), the hash was used to provide a unique name based on ONLY the path and dimensions. This is the old way image "caches" were handled in the past (computers don't care if the image name is not user friendly and the hash saves a small amount of space in the file names). As space is not a high premium anymore, newer systems simply use a unique path and the image dimensions (retains contextual information about the image in human readable format). I for one was very happy to see someone update the behavior! The more user friendly an image name is (especially for searchable images), the better IMHO.
NOTE: If one wanted, additional management and handling for images could be added. Adding new behavior and features would probably involve a new database table for images along with some refactoring of the existing Zen Cart database tables. A hash of the file contents (not name or dimensions) could be used as a "quick" compare. This is not a small undertaking and probably not worth the effort at this time. Saving a little physical space at the application level is a dying concern these days, especially with the advent of newer filesystems supporting automatic deduplication.
Currently images are all stored at the filesystem level (with unique paths - enforced by the filesystem). The product data simply references the relative path to the images and Image Handler reads this and returns the path to the corresponding Image Handler "optimized" image (creating the image if needed in bmz_cache. This behavior matches the behavior of other CMS systems such as WordPress.
Sorry haven't highlighted the pertinent part, but overall there's the explanation of why the hash function was used and why it is no longer necessary. I presumed (incorrectly) that the hash covered far less information than described. BE GONE hash filename! :) May it rest in peace having fulfilled the need that previously existed.
Thanks lhungil.
Let me give an even simper answer.. I didn't CARE if there was some "perceived" benefit to the MD5 hash naming used..:laugh: (and I suspect that one of the other reasons had to do with obscuring and protecting images from image thieves as well)
In any case, it's use has LONG made the images in the bmz_cache unusable for many since you couldn't match the names of the images in the cache to their original "parent" images.. So unless someone can give me a COMPELLING reason why NOT to make the change to more usable image names, I am okay that this change is an improvement for the better.. (in other words, I have NO PLANS to remove it..) and by compelling I do mean something other than providing some small means to "idiot proof" file naming for site admins.. I am not going to try and idiot proof file naming in IH4.. Folks who use poor file naming practices have historically always had issues with IH4 anyway.. The answer to that behavior is to STOP using poor file naming practices.. :laugh:
I will be submitting the updated IH4 this week..
Image handler is installed on this website. I know it is and installed correctly. GD 2.3.11 is installed and enabled.
But it's not creating new images.
I'm so used to this working right out of the box that I'm now just confused.
I checked folder permissions. Can gd show up in the phpinfo but not work? Never seen it do that but this server is so locked down with mod security and its firewall that things just aren't normal.
Thing is and part of my point a couple of posts back is that both could be used: the hash to do it's original task and the filename be left alone at the end to match or as is currently suggested approximate the original "parent" image. That is if the only goal was to provide an imahe name that could be matched to it's original "parent". However, the direction chosen has been to eliminate the hash portion entirely, which was why I asked what the goal of the hash was to ensure that other reasons for it being used weren't ignored.
Regardless McLovin will still need to take into account how the filename is named with consideration of the image size as I recall the sample names provided indicate that the image size becomes part of the filename like it does currently in the hash included version. So a similar problem in that regards still exists: what filename to use to swap an additional image with the primary image... And I would think the same solution would apply to use the name generated through the image_handler for the two images being swapped.
I understood your original point.. so here's the answer.. I don't know what the logic was behind Tim's original choice to use an MD5 hash to name the files.. He doesn't say in ANY of the original docs on his site (most of which have been incorporated into the current IH4 readme file..) So to err on the side of caution, I didn't rush to release this version when the change was made.. I wanted to see if there was anything that I hadn't considered that might "crop" up as a result of the change..
Since I've changed it and have it running in this form on a few places now (including my own site) I cannot see that the change has been detrimental.. So yep.. I stand by my original POV on this.. Folks have been asking about better file names from IH4 for YEARS.. A fellow Zenner generously provided the changes needed to do this, I've "beta tested" it for going on close to a year now.. I'm satisfied that this is the right direction.. I can't see where anyone is really gonna say "Gosh I miss the old obscure file names in IH4, can you bring those back?".. No one who's downloaded this version has said this either, nor have they raised any other concerns/issues.. So I'm comfortable submitting this new version..
Very interesting. Unfortunately, it seems that as it currently stands, any workable modification to this version of IH which would allow an image swap is well beyond my programming skills. (I've always been a bad programmer. I tend to take bits and pieces of different programs and put them together. That's why I end up with Frankenstein programs). But I think that with the new modification to IH (some form of human traceable naming convention) it might be possible. I'm very curious about the new version of IH.
I have IH4 installed on 2 systems, both are zc154 all zc files are identical.(checked with wimerge). System1 is my test box (local) and the second is a live site.
IH4 functions properly on the local however on the live site it doesn't. When it's off all images work as they should, however when it's on they don't show in Admin>tools>IH4,
I also loose them for the Online catalog categories.
In the "specials" side box the image is gone but on mouseover it pops up.
They do write to the bmz_cache folder ie: "10-255.jpg.image.50x33.jpg"
In the error logs I am finding: File does not exist: /home/xxxxx/public_html/x (looks like something isn't being directed to the correct directory)
File does not exist: /home/xxxx/public_html/x, referer: http://www.xxxx.com/myadminfoldernam..._category_id=3
Since both systems have the same files etc this would kind of eliminate any interference. The only difference would be the configuration settings but since the images work without IH4 the configuration would be correct ???
I've been working on this for a couple days now and give up trying to figure it on my own- hopefully someone has seen his before :-))
Thanks
Haven't specifically seen it, but seems like it might be file/folder permissions on the bmz_cache directory.
I found it- I realized I don't use htaccess on local so I checked that on the live site.
From ages ago I had entered a 301 for the bmz_cache, evidently I had seen numerous requests for it so I just gave it a 301 over to the base :-))
What a relief to find that old line in there, my hair is already starting to grow back :-))
Then I suggest that you download it from Github, install it and end the mystery.. Because I don't know if I'll be able to submit it this week as I stated earlier.. Not entirely sure why you think you HAVE to get it from the Zen Cart downloads.. I don't have ANYTHING new to add/remove with regards to the IH4 version in my Github repo..
ZC 1.5.4 fresh install - under construction
Template: Winchester responsive
Plugins:
IH4
Easy Populate (not used at this stage)
Cross sell advanced
Standard options added to product
Attributes
Issue - IH stopped working either after CS added or attributes.
Have stopped building the site
Hi everybody,
I have upgraded my old 1.3.7 to 1.5.4 and installed the latest IH4. The problem is that it is not resizing images, but shows huge size originally uploaded images on hover. When I go to admin->tools-image handler, I can see default, medium and large size images of the same size, e.g. 1100x1038. When hovering, it renders the same huge size, though settings for "IH Large Images" are 750x500.
What am I missing here?
Thanks
Well the screenshot says "No Image Handler Found". Something you installed has an errant SQL install script which removed the IH4 version info from the configuration table.. So try un-installing (by clicking the UNINSTALL link) and reinstalling (by clicking the INSTALL link). If that doesn't work, then try uploading the files again and see if the install kicks off..
Dunno..
what's missing to get help is:
- a link to the product where the issue exists to see the issue
- the other modules you installed
- where you got the IH4 version you are using
If it's the beta version on Github, there's NO SUPPORT for it until it is officially submitted (which hasn't happened yet as I'm waiting for feedback from some latecomer beta testers..) IH4 works if installed correctly.. So try un-installing (by clicking the UNINSTALL link) and reinstalling (by clicking the INSTALL link). If that doesn't work, then try uploading the files again and see if the install kicks off..
Also suggest that you re-read the readme file.. in particular the parts about the image hover feature.. (hint: check your settings)
Otherwise you will need to post the information we ALWAYS ask people to post when asking for help
- link to page with the issue -- we are volunteers so don't make us hunt through your whole site to find the issue
- image settings
- other modules installed
- etc.. (see page 1 of the support thread for tips on what we need when you need help)
I'm rebuilding my zc 1.3.9h livesite from scratch on zc1.54. test site, with new template but imported existing database. I've installed IH4 on test site and all appears well thus far.
Can/should I copy the bmz_cache from old site to new?
Thank you.
Can, but shouldn't. The files in the bmz_cache are auto generated if they don't previously exist. There is no value added in copying the files (or folders) over. Also, depending on where you obtained a copy to use with 1.5.4 (ie if obtained from the link in this thread to github) then the currently existing bmz_cache directories and filenames will be "wrong" anyways.
I've got a client that's got slews of images (and a newly-converted store that's using IH-4). Has anyone developed a script to run through the current products' definitions and mass-convert all if the images in one-swell-foop? The image conversion is currently adversely affecting the store's page-load times.
Could always run a "spider" such as "Link Checker" against the website during non-peak hours (and configure to delay a bit between requests). Not ideal, but would solve the issue without requiring much "touch time" (or creating a script).Quote:
... Has anyone developed a script to run through the current products' definitions and mass-convert all if the images in one-swell-foop? ...
Yes, some of the images are quite large; I'm seeing something on the order of 1-second per conversion and the site displays 9 Specials and 9 Featured products on the main page.
Thanks, lhungil, I'll look into that Link Checker.
the GD binaries actually do the "heavy lifting" in IH4. Perhaps this issue is a symptom of a server configuration limit which will terminate processing before the GD binaries can finish the image processing. Now this could be a simple server configuration change to increase memory limits so that GD can finish processing your images, but the MOST likely cause is that your original images are too large to begin with and your host's servers limits will ALWAYS stop the GD processing..
I want to move the extra images from the bottom of the page to under the main product image or to the side of the main product image. Now how would I go about doing that or if it is possible?
here is a link to the page:
LHAL Sportscards & Collectibles
Any help would be greatly appreciated.
Regards,
Les McDonald
Just installed the latest IH for 1.5.4 with no problems and works perfectly just as intended.
I have an issue and I don't really know how to articulate what the problem is.
Some of my images will appear in Image Handler 4, and some of them will not. With the ones that will not, it appears from looking at html source that the module just stops building code to show the images mid-stream. It happens with some newer files that my warehouse coordinator has loaded up. I have checked the file locations and everything is correct. I am not sure if the files are being saved to BMZ_CACHE or not.
Any insight would help. Thank you in advance.
You are going to have to give us more information about the newer images that aren't loading.. (format, file size, error logs that you may be seeing, file naming samples, etc) Otherwise we'd all have to GUESS what the issue is. Guessing without information isn't generally a helpful exercise..
and as I have stated (JUST RECENTLY in fact -- see the last few pages of this support thread..)
So without more information, the community can't help you with an issue that isn't widely reported..Quote:
the GD binaries actually do the "heavy lifting" in IH4. Perhaps this issue is a symptom of a server configuration limit which will terminate processing before the GD binaries can finish the image processing. Now this could be a simple server configuration change to increase memory limits so that GD can finish processing your images, but the MOST likely cause is that your original images are too large to begin with and your host's servers limits will ALWAYS stop the GD processing..
And surprisingly not commented for request is the site on which this issue is occuring (preferably specific links of where this seems to be working properly and where not). That alone could reveal a wealth of information.
A wealth of information, yes, however, a wealth of information I cannot disclose on a public forum without earning myself a trip to my company's information security office for a lecture on releasing proprietary business information on an open forum.
I am trying to run down all of the information above for you all without breaching my obligation to my employer.
However, with that said, you both have started me down a path that I may be able to resolve shortly as soon as I take a look at the images. I suspect that the photos may be too large to process.
The site is http://www.iemssupply.org/zencart.
Yup, that was it. It's been a little over two years from when I did the original work on the site, so I totally spaced the limitations of the software. Thanks!
This wasn't my post, but - I installed IH4 4.3.2 on my zc 1.5.4 test site on Apr 16th and everything appears to be working correctly. I had compared this to the github version I found via forum (maybe wrong version?)with winmerge and only differences I found were in the title version notations at the top of each file. By 'working correctly' I mean adding and resizing new product images, additional images. Photos already existing are displayed in the right places but the image sizes aren't created unless I delete and re-add the photo which I didn't consider onerous. My test site is a rebuilt of my live zc 1.3.9 site which uses IH3.
Have I missed something about IH4.3.2 that I should be installing Github version?
Update to the IH4 Github repo this morning (and I am sooooooooo glad I hesitated/lagged on uploading this version.. cause this is a pretty BIG bug :ohmy:).
Click the link to read the boring details of the Duplicate image bugfix for the new file naming convention. Once again a big thanks goes to balihr for coming to the rescue with the quick fix..
I do need folks to test this who have more than one layer of image folders to test this to be REALLY sure that this bug is squashed, and once I am satisfied that it has been tested, THEN I will finally submit this version to the downloads.. Again this is still considered a BETA version though I do have it installed on my own site and several live client installs (which is how this bug was discovered)..
I have added this plugin to my v1.5.4 and works with it. One question; Background colour - does accept the HTML/CSS version 5 coding? E.G instead of 255:255:255 type white.
Also the main image does not zoom. Any ideas please
Doubtful considering that this processing (and therefore format) is required by the GD library..
Nope.. I've always stated honestly I have NO IDEA how to add the required code to support this.. The state of zooming on the main image is covered in the readme.. This has functionality NEVER been a part of IH4, and unless and until someone contributes the code needed to properly support it without breaking lightbox compatibility, it's not been on the radar for quite sometime..
To be honest after I post the first question I thought it was a stupid question, it is direct coding to the web page. :censored:
About zooming the main image, I have installed 'Product Image Zoom' which was working. Now after installing this plugin it does not. So if I can work out how to get both plugin's working together that would be fantastic. Will be back hopefully with good news. :D
I have what is probably an extremely stupid question and not necessarily related specifically to Image Handler (which I LOVE; thanks for all the effort put into this amazing plugin). I have watermarks set for medium and large images. Everything works as it should, but the image is too dark. I have changed all three images repeatedly to the point where they're barely visible but they haven't gotten lighter on my site. I've even changed the image entirely just to make sure I wasn't being REALLY idiotic an changing the wrong image. The image changed but it too was too dark. Am I missing something in the actual IM4 settings? I didn't think it handled watermark opacity.
Further to my last post (1389) here is the code that product image zoom uses to 'zoom' on the main imageHowever I do not know where to put it and cannot work out how to connect it to this plugin. In product image zoom, it is loaded to; includes/template/mytemplate/auto_loadersCode:$loaders[] = array('conditions' => array('pages' => array('product_info')),
'jscript_files' => array(
'jquery/jquery-1.10.2.min.js' => 1,
'jquery/jquery.elevateZoom-3.0.8.min.js' => 2,
'jquery/jquery_product_image_zoom.js' => 12
)
);
I have half a dozen images loaded for a product and they work nicely. But I have decided I want to reorder the images so that a different image is the main image. Is that possible with image handler or do I have to delete them all and start over?
Thanks,
Christy
G'day,
We have one CMS being used for the main part of our web site (https://www.scubadoctor.com.au) and Zen Cart for the online shop (https://www.scubadoctor.com.au/diveshop/).
Within the other CMS I have a PHP script that highlights five randomly chosen Specials on each page in the left column. Currently this script gets the main image for each product from Zen Cart and displays it small. So worst case we are loading five 1000 x 1000 images on each page to show them as thumbnails. That is a waste of bandwidth and slows up page loading just a bit.
How would I be able to find out what the Image Handler cached small filename is for a given product, or product file image?
With some code to do this we'd be able to improve web site efficiency.
Best regards, Lloyd Borrett.
I upgraded to Zen Cart Version 1.5.4 a few months ago. I am using Image Handler 4.3.2, which I was using with the older version of Zen Cart, and it worked great. When I did the upgrade, everything was working correctly with the Alysa Rounded template. This week I upgraded to a responsive template, Avonlee Contempo Responsive. I went to upload images with Image Handler 4, and everything worked as it always does. However, when I went to the product, it only shows the main image and not the others I added. I'm not sure why the additional images are no longer showing. I went through the troubleshooting checklist at the top of this thread, but I didn't see any issues when I checked everything. I loaded up the old Alysa Rounded template, and it works. Does anyone have any idea what I could be doing wrong? Does this mean I need to ask the creator of the template for Avonlee Contempo Responsive? Please let me know your thoughts and thanks!
Prossibly.. but the MOST likely answer is that you have missed merging an override file that has IH4 required changes into your new template.. I would do a comparison with template overrides from your old template to see what you didn't bring over to your new template..
Had similar experience. In my case I installed the IH2 includes/modules/additional_images instead of merging it with my includes/modules/my responsive template/additional_images. Merging with the latter also kept the colorbox functioning properly (which has been merged with orginal file as part of the template).This was instructed in the MISC tab of IH readme but I misread and put the IH fi;e in modules/ instead of moduls/my template/
Can someone tell me the DB tables the IH uses please, Im currently trying to intergrate my ZC store into my SAP system and would also like the aditional images to populate from my database, I can't seem to figger out how IH knows the connection for the item id number and the original file names of the aditional images stored on the server.
Thanks
May not have made as much sense then as it will shortly, but it has been stated multiple times that IH effectively uses the same image information as the default ZC store, so it uses the products table with the products_image information... All "additional images" are named in the applicable images/PATH folder as relates to the way ZC processes/handles images... So to get your additional images really should be looking at additional_images.php related code, not so much IH as far as obtaining the path(es) to the original file(s)... (the modified version as made available by IH, that's a different story and somewhat depends on the version being used, etc...)
I understand how the ZC additonal images works ie productone_1 productone_2 etc but that uses the images names to reference the images to the products, the way my site is we have additional images added via IH4 which have a totally different and unrelated name for example, we might have a ford focus for sale with the photo focus_1.jpg but also have a photo of a technical spec (generic to all model cars) also added with the name techspec.jpg, so in normal terms ZC wouldn't make the connection... but IH4 does.
I was assuming that IH4 had a table in the DB somewhere that had additonal images defined, ie ID1, techspc.jpg, techford1.jpg etc am i assuming wrong and it is not possible for me to find the defining link between the product id and the additonal image file names?
I haven't checked out the github version to see if/how it assgns additional image names differently than it did in the past, but through the versions previously, such a differently named file would be saved with the nme of the original file and either the automatic extension, or the one of choice to still provide additionl image generation.
If you are using the github version and it offers such new naming convention then for the moment I'm stepping out on the discussion.