Attribute image replaces main product image on select [Support Thread]

[ideasgirl]

Hey MC, I think I catch a bug.

Everything was working fine until today 2 items had the alternative color "1st" in the options list. The main picture will change to the LAST option of the list (even if is not the default). I thought that uploading the image for that option will fix the issue (since customer is not uploading picture for the attribute if the option is the main image); but that didn't fix it.

I also tried using the "default" button for the attribute, and doesn't work neither.

I can sen you by PM the links for you to take a look.

[mc12345678]

Hey MC, I think I catch a bug.

Everything was working fine until today 2 items had the alternative color "1st" in the options list. The main picture will change to the LAST option of the list (even if is not the default). I thought that uploading the image for that option will fix the issue (since customer is not uploading picture for the attribute if the option is the main image); but that didn't fix it.

I also tried using the "default" button for the attribute, and doesn't work neither.

I can sen you by PM the links for you to take a look.

Please do.

[mc12345678]

If I understand correctly (not yet having received the link(s)), there are two or more attributes (option names), each has at least one option value that has an attribute image. When chosen or set, the image for the last option name is what is presented?

Or is it option 2, where the image of the last available selection is the one presented? (ie. 2 or more option names and it is the last option value out of all of the option names that shows the replaced image.)

Again, I expect to understand better once the link(s) received, but helps to identify the issue if a little more clarity can be provided. :)

[mc12345678]

Okay, I have some answers now.

Basic description is a single option name, multiple option values.

Now, for the "fun" part...

When page is loaded and ALLLLLL javascript has completed, each of the option values have been selected and Attribute Image Swap has attempted to resolve the image for each such selection. The source of this event is one of many javascript operations that execute onload. Additionally, there are three versions of jquery loaded, there are html validation errors, and I am not sure which type of viewer is used to make the image larger, but it does not look like the colorbox version available for download from the plugins, also it is using an older javascript version of the colorbox javascript. I imagine it is something to do with whatever javascript compression/loader is being used, but there is something that seems to systematically select each of the attribute options. With so many scripts involved and such a long load time for the entire page (144.95 seconds to load 4,397.91 KB with 116 requests) then on a page reload: 98 requests 5,164.76 KB, 91.30 seconds.

Ohhh.. And might suggest using the latest version of the plugin. The version installed/edited does not include the use of the ZC zcJS javascript variable (even if that variable is not present), which means that the issue(s) identified, corrected, and associated with the previous version remain.

[ideasgirl]

Correct. There is 1 option name, few options value; and the last option value is the presented.

Or is it option 2, where the image of the last available selection is the one presented? (ie. 2 or more option names and it is the last option value out of all of the option names that shows the replaced image.)

How should I know which one to eliminate?

Additionally, there are three versions of jquery loaded, ...

Lightbox is the viewer for larger image (and IH4 ins installed). I will check the colorbox scripts and versions.

... there are html validation errors, and I am not sure which type of viewer is used to make the image larger, but it does not look like the colorbox version available for download from the plugins, also it is using an older javascript version of the colorbox javascript.

Correct. That was my thought at the beginning, but since it changes the image AFTER all the loading it threw me off.

I imagine it is something to do with whatever javascript compression/loader is being used, but there is something that seems to systematically select each of the attribute options.

I will see if programmer that created template and did the integration of the plugin will do that.

Ohhh.. And might suggest using the latest version of the plugin. The version installed/edited does not include the use of the ZC zcJS javascript variable (even if that variable is not present), which means that the issue(s) identified, corrected, and associated with the previous version remain.

[mc12345678]

Sorry, on a mobile device making "part" answers time consuming:

Correct. There is 1 option name, few options value; and the last option value is the presented.


How should I know which one to eliminate?


Lightbox is the viewer for larger image (and IH4 ins installed). I will check the colorbox scripts and versions.


Correct. That was my thought at the beginning, but since it changes the image AFTER all the loading it threw me off.


I will see if programmer that created template and did the integration of the plugin will do that.

Generally speaking, there should only be the latest version needed to support operation installed... but, there are "tools" that make it possible for multiple versions which it appears to be the case, though 1.4.4 I think it was, is significantly old and whatever is requiring that should be updated or abandoned (in my opinion).

As to lightbox, if discussing the version that is available for download (which it looks like it is), there is software upon which it depends (slimbox) that has been abandoned and not being updated at least as of a few years ago. Colorbox and it's foundation continue to be supported.

Regarding the last two items, if memory serves (and based on the change notes for the most recent version), the problem seen (last option value of an option name always becoming active on initial load) was a reason for the most recent version being published. As other issues were corrected (js error on initial page load that did not have the product in the cart), the code was seeking through all checkbox and radio selections to land or ultimately go with the last one. This was corrected in the ais_init() function around line 176 where a check was performed to see if the selection had been checked before attempting to execute the associated onclick action. At least adding that if around the area would resolve the described issue, but would suggest a full update instead of just that line change. Update is to simply replace the files and as necessary incorporate any modifications that may have been made. Based on the visible javascript code, version 1.5.7 is installed with v1.5.8 released a few weeks ago (5 days after the version currently installed) that corrected the identified issue.

[ideasgirl]

Thank you very much MC I managed to update those jscripts and upgrade the module and that not only made the trick it also made the loading time much faster.

[mc12345678]

Thank you very much MC I managed to update those jscripts and upgrade the module and that not only made the trick it also made the loading time much faster.

Glad that it all worked for the better. :)

[soxophoneplayer]

zc 1.5.5f new install test site; clone of responsive_classic template, IH5, newest Colorbox, newest SbyA, newest Attrib Image Swap

I'm playing with this Attrib Image Swap version July 2017 on test site. In Beyond Compare I'm looking at a difference I don't know how to merge in includes/modules/YOUR_TEMPLATE/attributes.php

In the Image Swap Version, around line #188:

 $products_options_array[sizeof($products_options_array)-1]['text'] .= $products_options_display_price;

                  // collect weight information if it exists
                  if (($flag_show_weight_attrib_for_this_prod_type=='1' and $products_options->fields['products_attributes_weight'] != '0')) {
                    $products_options_display_weight = ATTRIBUTES_WEIGHT_DELIMITER_PREFIX . $products_options->fields['products_attributes_weight_prefix'] . round($products_options->fields['products_attributes_weight'],2) . TEXT_PRODUCT_WEIGHT_UNIT . ATTRIBUTES_WEIGHT_DELIMITER_SUFFIX;
                    $products_options_array[sizeof($products_options_array)-1]['text'] .= $products_options_display_weight;

In the same file I previously merged with Stock by Attributes, the same lines are:

 $products_options_array[count($products_options_array)-1]['text'] .= $products_options_display_price;

                  // collect weight information if it exists
                  if (($flag_show_weight_attrib_for_this_prod_type=='1' and $products_options->fields['products_attributes_weight'] != '0')) {
                    $products_options_display_weight = ATTRIBUTES_WEIGHT_DELIMITER_PREFIX . $products_options->fields['products_attributes_weight_prefix'] . round($products_options->fields['products_attributes_weight'],2) . TEXT_PRODUCT_WEIGHT_UNIT . ATTRIBUTES_WEIGHT_DELIMITER_SUFFIX;
                    $products_options_array[count($products_options_array)-1]['text'] .= $products_options_display_weight;
                  } else {

Which should I use?

Thanks!

[mc12345678]

At this very moment, it does not matter which. There has been some discussion by the php powers that be that sizeof (alias to count) will go away in future php versions. It was thought (and at one point voted) to be removed in php 7.2, but as of yet has not.

That said, I would suggest that count be used if either of them are to be used. Again it mostly likely is a non-issue either way, but certainly makes it easier to be consistent.