Problem with Product Images

russianradiantsaDOTcom
ZC 1.5.8a
PHP 7.4.33
bootstrap 3.6.4
OPC
EO
DBIO
Options' Stock Manager

All mods are current from forum Plugins not Github

Don't think this is a boostrap problem but bootstrap and MagicThumb are not doing well together. I have removed MagicThumb for now.

This site if fed by an Excel file from the manufacture with generally four to five images of each product. The original is in the format XXXX####.jpg where XXXX is the product code and #### is the model number. The additional images are in the format XXXX####_L.jpg where L is a through c or d depending on whether there are four or five total images.

Zen Cart has no problem with properly labeling and showing the images as set witht the original as the main images and the underscores as additionals with their L in alphabetical order as expected.

The problem lies in that Zen Cart is overzealous in trying to select images for a product.

If you go to the site and search for 11, you will be shown eight items with 11 in the model number.

Clicking on the first available, results in the product page for STTK110. HOWEVER, the first set of additional images for the item are for STTK1100. It also shows images for 1101 thru 1109.

The selection is basing the results on 110 being anywhere in the image's filename. Since it is NOT showing images for 1110, we can assume (I know) that it looks at the images from the front of the image name until the first character/number does not match.

That is reinforced by the fact that, when selecting the second choice of STK1100, it results in a proper product listing of only the images matching sttk1100.jpg or sttk1100_L.jpg.

I have not experienced this before as we have been using responsive_classic with MagicThumb (a commercial image handler). It's selection proces works with responsive_classic but not with bootstrap.

I am hoping to find a way to modify the selection process to more correctly select images for a product. With over 2,000 products in a feed, it is impossible to try to manipulate image naming so that products starting with 11, 12, 13, 14, 15, 16, 17, 18, 19, and 20 would not show images not related to them.

Is it a simplle matter of having the search only look for a strict match from the filename beginning to the . or _?

Is there a change to the #image_modal that could accomplish this or is in the main zen_image? Perhaps a change in the includes/functions/htim_output.com?

Suggestions?

Have you flipped this particular site to responsive classic to see the behavior?

I suspect if you actually flip this site to responsive classic you will see the same behavior, as I found testing.
Additionally I found that if I move the images from the main images folder into an images/sub-folder then the rules for naming are stricter (base image name + the underscore for the match) and the problem goes away....

Thanks for checking. Sorry I did not mention that I had dropped to RC with the same results. That's why I pulled the thread out of bootstrap.

I can easily move images and do a mass change to the database but, I think it would be beneficial to all if I can come up with the correct sanitation for the images directory.

If you can point me in the direction of each, I'll work it out.

well, includes/modules/additional_images.php
and for the bootstrap template
includes/modules/bootstrap/bootstrap_additional_images.php

Though I think it may be on purpose that it is setup this way, looser matching in the main images folder and stricter in a sub-folder... the why I have no idea about.

staring at this https://docs.zen-cart.com/user/images/image_filename_conventions/ made me test it.
Changing it at this point is likely to break additional images on older sites that have done their naming in a particular way.
I have no idea what your import process is but with 2009 products with ~5 images each there is somewhere between 9-11K images in the main images folder... ackk, I hate that as it is only likely to grow. I would look to figure out in the import process a way to segregate the images into sub-folder, most likely based alphanumerically based on first letter/number, basically the way bmz cache is broken down

I've run into this before on a smaller scale.

I think this could just as easily happen with 100 images and have had to "massage" image names before.

The time it would take me to manipulate all the spreadsheets being input to POSM is just not cost effective.

I think I'll start a github discussion to see if we can't geet this fixed for the general populace as well.

barco57:

well, includes/modules/additional_images.php
and for the bootstrap template
includes/modules/bootstrap/bootstrap_additional_images.php

Though I think it may be on purpose that it is setup this way, looser matching in the main images folder and stricter in a sub-folder... the why I have no idea about.

staring at this https://docs.zen-cart.com/user/images/image_filename_conventions/ made me test it.
Changing it at this point is likely to break additional images on older sites that have done their naming in a particular way.
I have no idea what your import process is but with 2009 products with ~5 images each there is somewhere between 9-11K images in the main images folder... ackk, I hate that as it is only likely to grow. I would look to figure out in the import process a way to segregate the images into sub-folder, most likely based alphanumerically based on first letter/number, basically the way bmz cache is broken down

dbltoe:

I've run into this before on a smaller scale.

I think this could just as easily happen with 100 images and have had to "massage" image names before.

The time it would take me to manipulate all the spreadsheets being input to POSM is just not cost effective.

I think I'll start a github discussion to see if we can't geet this fixed for the general populace as well.

First, I'm guessing that you're talking about DbIo, not POSM. Second, that alternate-additional-images' matching convention has been around since zc138a (and probably earlier), so I'm not sure what you're looking to geet (sic) fixed.

Like @barco57 indicated in the provided link, users need to RTM.

geet (Grammarly quit working on the forum.):(

Yes, in realizing I left Products off POSM, I used it rather than DBIO in the text.:blush:

I'm very familiar with the page both barco57 and you point out as I make sure it's part of a starter email sent to customers.

Yet, look at https://docs.zen-cart.com/user/images/image_filename_conventions/#additional-information and the example using fred.jpg.

If the search for additional images was set to match all up to an underscore or ".", only options 2, 3, and 4 would be selected for fred.jpg. Espeically if the following paragraph (advising the use of the underscore) is followed.

I feel that it's not right to go beyond an underscore or period in a filename when pulling images and just the fact that it has been that way since I came to Zen Cart doesn't mean it can't be modernized.

If the main file is fred.xxx, the system would look for fred_. If the main image were freddy.xxx, the system would look for freddy_. One could go further and have fred-1.xxx, fred-2.xxx, etc where each could have their own additional images as the system is (again) matching all until the file extension.

Granted, I'm biased towards change but didn't we make it through the language changes in 1.5.8a? Seems that was pretty major. How many mods are now reporting to be not compatible with pre 1.5.8?

I'm not able to test whether seaching only for the filename up the period as I'm not sure where it is done.

Perhaps if the code doing this is pointed out, it can be modified it for a particular site's use.

I did a quick test on my site, (Image Handler in use) using imagename.jpg as the main image.

/images/subdirectory/imagename.jpg : loaded, correct
/images/subdirectory/imagename_1.jpg: loaded, correct
/images/subdirectory/imagename00.jpg: NOT loaded, correct

/images/imagename.jpg : loaded, correct
/images/imagename_1.jpg: loaded, correct
/images/imagename00.jpg: loaded, NOT CORRECT

So, looks like a bug to me.

Never spotted this as I have always used subdirectories.

torvista:

I did a quick test on my site, (Image Handler in use) using imagename.jpg as the main image.

/images/subdirectory/imagename.jpg : loaded, correct
/images/subdirectory/imagename_1.jpg: loaded, correct
/images/subdirectory/imagename00.jpg: NOT loaded, correct

/images/imagename.jpg : loaded, correct
/images/imagename_1.jpg: loaded, correct
/images/imagename00.jpg: loaded, NOT CORRECT

So, looks like a bug to me.

Never spotted this as I have always used subdirectories.

I beg to differ on the "correctness" of the highlighted image name. From the docs (https://docs.zen-cart.com/user/images/image_filename_conventions/#additional-information):

Original Image: fred.jpg

All of these are considered additional images because they contain the base image name:

/images/fredabc.jpg
/images/fred_73b2.jpg
/images/fred_01.jpg
/images/fred_02.jpg
/images/freddy.jpg
/images/fredrick.jpg

ok, I'll sit corrected.

The inconsistency depending on location seems incorrect, and the allowing-anything-after-the-basename is a hole which has lead to this thread.

For me, the big picture is the core image-handling process seems very unwieldly for 2024...

torvista:

ok, I'll sit corrected.

The inconsistency depending on location seems incorrect, and the allowing-anything-after-the-basename is a hole which has lead to this thread.

For me, the big picture is the core image-handling process seems very unwieldly for 2024...

I agree that it's inconsistent, but making that change would result in sites that "followed the rules" for years having to go back and rename any additional images for images present in the root /images directory.

How about providing a switch somewhat similar to the option of 0 vs 3 in columns for bootstrap?

I feel this was wrong from the start and that fact is not a very good reason for continuing.

Still trying to find code and fix.

What is so frustrating to figure out is that any product found by searching 11 has the "problem".

Any product found by searching for 01 does not.:dontgetit

Revisiting this as I think there may be an inherent bug somewhere in the system.

Let me know where my thinking is incorrect.

ncludes/modules/main_product_image.php uses lines 19 - 22 to strip the extension from the products image.

$products_image_extension = '.' . pathinfo($products_image, PATHINFO_EXTENSION);$products_image_base = str_replace($products_image_extension, '', $products_image);
$products_image_medium = $products_image_base . IMAGE_SUFFIX_MEDIUM . $products_image_extension;
$products_image_large = $products_image_base . IMAGE_SUFFIX_LARGE . $products_image_extension;

Therefore, xxxx111.jpg, xxxx112.jpg, and xxxx113.jpg should be passed to the system as xxxx111, xxxx112, and xxxx113 removing the (.) along with the file extension.

Then we move the to the product listing page and the additional images (in my case, xxxx111_a thru xxxx111_d)

The same thing is done to provide a base for additional images in includes/modules/additional_images.php.

What appears to be happening somewhere along the way is that the $poducts_image_base is being truncated to the first six characters after the extension is removed as the duplicate additional images only occur in products that have a match of the first six characters in the image filename.

I can find no where in the additional images file that this is happening but perhaps it is happening elsewhere.

An even better representation of the probblem is at https://russianradiantsa.com/index.php?main_page=product_info&cPath=63&products_id=1309.

One item picking up ten images instead of just the one matching the product's image filename.

Doing a workaround with DBIO means hours of work on each weekly input.

This is one of those things that would send someone to S h o p i f y.

Demo data, product 34 "Bug's Life Multipack":

In the database, the image filename is:"dvd/a_bugs_life.gif"

main: "dvd/a_bugs_life.gif"
0 => "dvd/a_bugs_life_00.gif"
1 => "dvd/a_bugs_life_01.gif"
2 => "dvd/a_bugs_life_02.gif"
3 => "dvd/a_bugs_life_03.gif"
4 => "dvd/a_bugs_life_04.gif"
5 => "dvd/a_bugs_life_05.gif"
6 => "dvd/a_bugs_life_06.gif"
7 => "dvd/a_bugs_life_07.gif"
8 => "dvd/a_bugs_life_08.gif"
9 => "dvd/a_bugs_life_09.gif"

If I rename the "_09" to "09", the image disappears.
Outcome: The "_" is enforced when in the subdirectory.



If I move those files up from /images/dvd to just /images/ and update the database to "a_bugs_life.gif" (and clear the cache), then it finds all the same images:

Main: "a_bugs_life.gif"
0 => "a_bugs_life_00.gif"
1 => "a_bugs_life_01.gif"
2 => "a_bugs_life_02.gif"
3 => "a_bugs_life_03.gif"
4 => "a_bugs_life_04.gif"
5 => "a_bugs_life_05.gif"
6 => "a_bugs_life_06.gif"
7 => "a_bugs_life_07.gif"
8 => "a_bugs_life_08.gif"
9 => "a_bugs_life_09.gif"

HOWEVER, if I rename the "_09.gif" to "09.gif", the image IS included in the list: "a_bugs_life09.gif" (and is actually at the top of the "additionals" list)
Outcome: The "_" suffix matching is NOT enforced when in the "main /images/ directory".


TO MAKE IT FORCE THE EXPECTATION OF AN UNDERSCORE AFTER THE "BASE" IMAGE NAME, you have to make the following change to /includes/modules/additional_images.php:

    // if in a subdirectory
    if (strrpos($products_image, '/')) {
        $products_image_match = substr($products_image, strrpos($products_image, '/')+1);
        //echo 'TEST 1: I match ' . $products_image_match . ' - ' . $file . ' -  base ' . $products_image_base . '<br>';
        $products_image_match = str_replace($products_image_extension, '', $products_image_match) . '_';
        $products_image_base = $products_image_match;
    }
// force the use of a '_' suffix when detecting additional images NOT in a subdirectory    
    $products_image_base .= '_';
    if (substr($products_image_base, -2) === '__') {
        $products_image_base = substr($products_image_base, 0, -1);
    }


    $products_image_directory = str_replace($products_image, '', substr($products_image, strrpos($products_image, '/')));
    if ($products_image_directory != '') {
        $products_image_directory = DIR_WS_IMAGES . str_replace($products_image_directory, '', $products_image) . "/";
    } else {
        $products_image_directory = DIR_WS_IMAGES;
    }

Tested in v2.0.0 with BS4 v3.7.0 template. This section of this file is the same in v1.5.8 as in v2.0.0.

ABSOLUTELY PERFECT!

Another store saved.

Great!
I'll explore making it a configurable setting in v2.1.0

Added to the docs. Great job team! A very subtle and tricky situation now resolved.