Problem with Product Images

[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...

[lat9]

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.

[dbltoe]

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.

[dbltoe]

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.

[dbltoe]

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.

[dbltoe]

An even better representation of the probblem is at https://russianradiantsa.com/index.p...oducts_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.

[DrByte]

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.

[dbltoe]

ABSOLUTELY PERFECT!

Another store saved.

[DrByte]

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

[swguy]

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