Image swatch broken when EAV cache enabled after upgrade to 2.1.7

[dawhoo]

Nexcess VPS SIP 300 - PHP 7.0.17 - SQL: Percona Server: 5.6.35-81.0 - Percona Server (GPL), Release 81.0, Revision c96c427 - magento-unmask: 022 permissions 755/644

Upgrade from 2.1.5 via composer. The usual: upgrade/flush/reindex/mode/compile/deploy which has been tried multiple times with different modules enabled/disabled and narrowed down to the single element - I think.

After upgrade, only the first 'hit' page will show image swatches when all cache modes are enabled.

When "Flush Magento Cache" is used, the next page (product, category, or search) will show the swatch product images. All subsequent pages do not show product image swatches. Those colors with defined colors in Admin via hex code will show, but no product images as swatches.

Swatches without a hex will show a blank image. Investigating code shows no image is being inserted into the div.

If "EAV types and attributes" cache is disabled via backend admin, then all the swatches work as expected. Enable the cache for EAV types and attributes and only the first "hit' page will load the swatches properly.

After many hours searching, I've yet to find the 'fix' for the issue and maybe it's only related to the environment.

[southerncomputer]

Try without redis active.

[erfanimani]

Same issue here. Not using Redis.

After clearing cache, the first pagehit shows product level swatch image as expected - second pagehit reverts back to attribute level hex codes. Doesn't matter whether you're on product page or category page.

Sounds like product level swatch images aren't cached properly.

[dawhoo]

Same here, no Redis or memcache.

erfanimani, could you try and disable cache on your EAV in System>Cache Mangement and if that makes a difference for you? With the EAV cache disabled, the swatches work on all pages for me. Just wondering if maybe we have the same issue or similar issue. Thank you.

[erfanimani]

Yeah, disabling EAV cache (and page cache) worked for me. Product page worked instantly after disabling. For the category page I had to reindex before it worked. Seems index is also using bad cached EAV swatch data..

[erfanimani]

@dawhoo This issue might very well have been solved on the develop branch.. I can test this week. I'm using 2.1.7 at the moment.

[dawhoo]

I've also noticed the divs get a different class

<div class="swatch-option image" option-type="2" for the swatches with images that work.

and

< div class="swatch-option" option-type="3" when the swatches don't work.

Looking into the EAV types and attributes, I checked into the database and noticed, in eav_attribute_option_swatch under "type" there are 3 options, 0 - text, 1 - visual color, 2 - visual image.

The 0 fields have text sizes under value, 1 fields have hex code colors, a few 2 fields have images upload to the swatch istelf. And there's there's a lot of 3 with NULL values.

It's as if the EAV cache turns off the "Use Product Image Fallback" in the attribute settings. Because even the items with div option 3, turn back to div option 2, when the EAV cache is disabled of the cache is flushed.

[dawhoo]

@erfanimani I just moved to 2.1.7 as well. I'm very new here, do you know where this development branch is and does it mention/show split file changes?

[erfanimani]

@dawhoo Dev branch is here: https://github.com/magento/magento2/tree/develop (I think it's the default branch of the project).

I think you can just clone the repo and run it. To see changes, you can do a Git diff as per normal. (2.1.7 release is either tagged or a branch).

[DJ0815]

I have the same problem on 2.1.6, and i am using no redis or varnish cache

[lexwet]

Same issue after update 2.1.6 to 2.1.7. [no redis, no memcache, no varnish]

[maurice-j]

same issue after update from 2.1.5 to 2.1.7 EAV cache disable fix works. My SQL 5.7.18 & PHP 5.6.30

[dawhoo]

Colors in the DB eav_attribute_option_swatch are all set to site_id=0 with NULL or hex color

Sizes in the DB eeav_attribute_option_swatch are all set to site_id=1 or 2

Color is the DB eav_attribute_label only shows store_id=1 or 2

Color and Size in DB eav_attribute_option_value have store_id=0 or 1 or 3

permissions on all pub folders 02775 and files 02664 with and unmask of 002

Don't know if that has any bearing on the issue, just wanted to put as much information as can

[hostep]

I'm not entirely sure if this is the same, but there was a bug introduced in Magento 2.1.6 and it still exists in 2.1.7 where the cache of the attribute options can contain wrong data if you use multiple storeviews. This was fixed in https://github.com/magento/magento2/pull/9704 But I have the feeling this is probably not 100% exactly the same bug, although it also involves caches and attribute options...

It would be great if someone could create a bugreport using a clean Magento installation with the steps about how to reproduce this bug. You can use the template Magento provides: https://raw.githubusercontent.com/magento/magento2/develop/ISSUE_TEMPLATE.md

In that way this issue might get picked up faster then without steps about how to reproduce this on a clean Magento installation.

[dawhoo]

@hostep I tried the file mentioned #9704 but it didn't seem to fix the issue for me, however, I may need to upgrade/compile/deploy before I can say that for certain.

Uploaded the new file. Made an error copying it. Flushed Cache and only home page would load and nothing else. Realized my mistake and uploaded the correct file from #9704 Flushed Cache, enabled EAV cache, Flushed Cache and Image Cache and JS/CSS Cache. Reloaded page - swatches all showed up. Navigated to next page and blank swatches or swatches loaded with the hex colors.

I'll try again this evening with a full upgrade/compile/deploy and see if that makes a difference.

[erfanimani]

I just tested on the latest develop branch and I can't replicate the bug any more. I don't fully understand Magento's branching/release model, but I'm pretty certain that it has already been fixed and will make its way into 2.2.

[erfanimani]

To clarify, current development branch is 2.2.0-dev. Can't replicate issue, so fixed in 2.2.0.

[hostep]

@dawhoo: ok, I had the feeling this was another bug, so https://github.com/magento/magento2/pull/9704 most likely won't fix it.

It would still be great if someone could test this on a clean Magento 2.1.7 project to see if the bug still applies and isn't caused by some 3rd party module or theme.

@erfanimani: last weekend I also had to find a commit for a bug which was fixed on develop but not on the 2.1 branch, and I used git bisect to find the commit which fixed it. It is a lot of work though, you first have to find a commit where it is broken on the develop branch, and then a commit where it works and then let git bisect do its work. It also involves initializing the database and populating it with test data again and again and again, so this takes many many hours to find the commit. But once the commit where the problem is fixed is found, then it is just a matter of trying to backport that commit to the 2.1-develop branch and then it will be included in one of the next minor 2.1.x releases.

[veloraven]

@dawhoo thank you for your feedback. Please, format this issue according to the Issue reporting guidelines: with steps to reproduce, actual result and expected result. As it is much easier to understand and reproduce the problem when the isssue is well-formatted.

[IlnitskiyArtem]

@dawhoo Thanks for reporting this issue. I cannot reproduce this issue. Please add more details to your description of the steps you followed when identifying this issue. Screenshots or logs would be helpful, too.

[nuovecode]

Same problem for me.

1. Magento CE 2.1.7.
2. Custom attribute so configured:

Catalog Input type for Store Owner: Visual Swatch Values Required: Yes Update preview image: Yes Use Product Image for Swatch if Possible: Yes

Step to reproduce:

1. Disable all cache type.
2. Go in category page and product page. Everything works well: you can see the swatches thumbnails.
3. Enable only EAV types and attributes cache
4. Go in category page, and you can still see the thumbnails.
5. Go in product page and there is no thumnail. The attribute option-tooltip-thumb of the dom element is empty.
6. If you visit the product page before the category page you see the thumbnails only in product page.

[SamEgorov]

@veloraven Here are steps to reproduce: Magento 2.1.7.

1. Create product attribute with type Visual Swatch. The attribute must have the following settings: Scope: Global Catalog Input type for Store Owner: Visual Swatch Update preview image: Yes Use Product Image for Swatch if Possible: Yes
2. Create a few options for the attribute - select some hex color for each option.
3. Create configurable product and create child simple products with super attribute from the step 1.
4. Select option for the attribute for each simple product.
5. Upload image for each simple product. Make sure that all uploaded images have flag 'Swatch'
6. In admin panel go to System > Tools > Cache Management. Enable all types of cache. Press 'Flush Cache Storage' and 'Flush Magento Cache' button.
7. Now on PDP for configurable product for the swatch attribute in options will be displayed images instead colors from the attribute options.
8. Open the swatch attribute in admin panel and change hex for some option(s). Save attribute.
9. Now we need to refresh cache by one of two ways: a. In admin panel go to System > Tools > Cache Management and select all types, select action 'Refresh' from dropdown menu above the grid. Press 'Submit' button. b. Execute CLI command in the root of magento folder: "php bin/magento cache:flush"
10. In both cases after step 9 we will see that now on PDP for the visual swatch attribute options will be displayed colors instead product images.

[rhoerr]

As far as I can tell this is fixed in 2.1.8. I can reproduce it on 2.1.7 + sample data just after changing the 'color' attr to use product image for swatch. I cannot reproduce it on 2.1.8 following the same process. Unknown what change(s) actually resolved it.

[magento-engcom-team]

Thank you @rhoerr for the testing. Closing this issue