It seems pretty hard to mitigate which image loads as main for products. Is there a way to force image pairing to use the real product image instead of the first chosen option? Changing params in fn_gather_additional_products_data() doesnt change the behavior of what happens for main (type M image).
I want to do this in grid lists so that customers see the original product image instead of first option combination. It seems pretty intense to get the image pairing to use something different than what is in DB schema.
It should always use the 'M' image for creating thumbnails for list pages unless there is a specific thumbnail that was uploaded.
The image management within cs-cart is severely outdated. Main-pairs were applicable when one uploaded a details and a thumbnail for every product. But since thumbs are auto-created, the whole image-pair concept is rather lame and overly complicates most image management activities.
Ah i see why its like that i guess, considering an old style CS-Cart. In addition to the unreachable, didnt check earlier, but im hinkering that the M image is set at options combo save. Its already in the DB with relations to some entity right?
Its like the last few tasks have ran into overbuilt monolithic stuff like this. Its one thing to shim/hack/hardcode something in, but its not correct ya know?
If anyone has any tips to eloquently lasso down the image pairing to make it a bit more flexible, please share :) Ill do the same
image pairs are set for many images that relate to products or product objects (like shipping, payments, etc.).
Alternate images (A) also have image_pairs. though most simply use the 'detailed' image and the 'image' (icon) is now mostly ignored other than for compatibility purposes.
To answer your last question; Rewrite it and have Main and Alternate imagery and make all thumbnails dynamically sized from their parent image. A compatibility routine for fn_get_image_pairs() would help with bridging the gap along with how downloaded images are handled (it's unique to cs-cart and could be made much simpler).