Problem with Product Images

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

[mc12345678]

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

Would think should look to provide update support to assist in identifying this new change to those trying to do an update, some form of database check when doing a database upgrade, to then provide a report of some type. Would suggest offering moving the image(s), but that falsely assumes they are on the server when running the database upgrade. Or perhaps incorporating some sort of image management tool into the zc_plugins directory so that a user that has been struck by this change might more easily address it directly.

[mc12345678]

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.

I don't know why import of all product to even a single picture subdirectory (already going to one single directory why not another) would increase the workload by any amount. It's a one time change to the import code to prefix the image filename if not present.

But, no worries, there is a code change with an additional database switch to be considered. Why it would need to be in a database setting requiring a full version change beats me, since there is a hidden away set of store settings file that can further be abused right now: includes/extra_datafiles/dist-site_specific_overrides.php

That is, after you copy and rename the file to site_specific_overrides.php, then also make sure that you review what will be affected by the setting(s) chosen to be sure your selection won't out right break your store.