There are MD5 hash decrypter tools.. dunno how well they will work with the IH4 cached files names as to your point other factors play into the filenaming for the cache..Quote:
Originally Posted by lat9
Printable View
There are MD5 hash decrypter tools.. dunno how well they will work with the IH4 cached files names as to your point other factors play into the filenaming for the cache..Quote:
Originally Posted by lat9
Nope..something you installed broke IH by removing it.. Reinstall IH..Quote:
Originally Posted by McGill
Basicically what i need to do is do a full migration from ZC to my SAP system so my website and instore / stock management / vehicle tracking and store (high street shop) sales all tie into together.
I have migrated everything and got everything working to gether fine appart from the additonal images as i cant see in the database the additonal images or a way to work out what image is what in the cahce folder etc.
ie database shows my product id1 is called x and costs x and has image x.jpg etc but the additonal image upload via ih4 is called y.jpg and and i see in the databse how ZC knows to pull up y.jpg as an additional image for product x id1.... has to be there somewhere.
Quote:
Originally Posted by mc12345678
Maybe it's hidden in the below message, but could you provide a link to a page where there are additional images to maybe see what you are talking about? Again, iH4 does nothing "special" tothe naming of additional image files that breaks the normal process of naming. If you can migrate a standard ZC that has addtional images, you can do so for one with IH4 installed...
The code in includes:modules/additional_images.php (or the overridden one for IH4) takes the information for the main product (coming from the database record for products_id=x) and identifies all of the images that are considered associated with the product. If you have had that or similar files modified to do something other than the base action, then may I suggest returning to the one that modified t for you or looking for someone else to support this effort.
If the main image was saved as y.jpg, then all additional images for that product will begin wth y and end with .jpg and have some middle name such as. _1, _2, etc for each additional image... If you need to capture in some sort of database the actual name of each additional image, then you need to translate/capture that through the use of the above file or a modified version of it... Regardless I think this has gotten to the point that it is not an issue associated with IH4 as IH4 does nothing beyond standard processng for additional images... Makes life easier, but in that regards doesn't modify the image handling of additional images.
Quote:
Originally Posted by kitcorsa
I have a question: Is it possible to have 2 sites using the same images with image handler when one of the site is placed in a subdomain? At this moment i am testing with 2 sites using the same database. The site in the sub domain is now using the images from the shop in the root. Thats ok, but i want the shop to use the images from de /bmz_cache folder from the shop in the root. Right now i defined the images folder in the configure file.
The reason i would like to do this is because the site in the sub domain is a mobile site. Using its own files but sharing the database with the shop in the root.
And, second question if it is possible where should i start?
I'm using zencart 1.5.4. and image handler downloaded from git_hub because i like the image names better.
You can't get the information about the additional images from the database. It is not stored in there. You are going to have to do some programming to search for the additional images ( same way as Zen does ) and export them that way.
I'd try updated versions of IH from git to solve the naming issues. The hashing thing makes finding them complex.
Quote:
Originally Posted by kitcorsa
If not mistaken it primarily revolves around the variable $ihConf['dir']['docroot'] set in includes/functions/extra_functions/functions_bmz_image_handler.phpQuote:
Originally Posted by karinvd
Though I believe there are some other areas where tests are performed against the existence of the image(s) which may not quite work out right without additional coding... But, many of the IH tests are performed and data is "written" with relationship to the docroot. Would suggest to also work "backwards" from where the generated URI is created for the image to see what if any other values need to be incorporated to "move" up a directory (elsewhere) in order to provide the bmz_cache related images as compared to the base URI address on the page, and if working with SSL, would need to also ensure that any links to the image(s) were of the same request type. In a way it may actually be easier/better to have all of the images hosted in this new sub-directory or whatever it is than the root. At least that way they would be directly accessible by digging deeper not coming back out... Either way seems like making it complicated... :)
Thank you @mc12345678 I did find the variable $ihConf['dir']['docroot'] but it is not enough to change it. Thanks for the idea to put all images in the subdiretory in stead of the root. . Thats something i dit not think of! I'll keep on trying :-)
Before I do a lot of digging can someone visit my site to see if this plugin is actually working? ATM I cannot use Chrome so I am being forced in to Windows Edge. The site is not working in edge. So if someone using Chrome visit this page and let me know if it is working. Thank you in advance.
Did you turn IH resize images to "yes" ? When looking in Chrome and FF, both give the default paths to the images.Quote:
Originally Posted by adb34