Magento2: Single Store Mode Not Working as it Should

[snoroozi]

Preconditions (*)

1. Magento 2.3
   2.

Steps to reproduce (*)

1. If store was previously in multi store mode and attribute values exist are still set at the store view level, they are still displayed on the frontend after switching to single store mode and filling out the description for example. If a store view had a different description it will still show on frontend.
   2.

Expected result (*)

1. In single store mode only the default view attribute values should be used for products, as there is no way except to switch modes and go clear a a store view value and then switch back to regular mode.
2. If switching to single store mode, only default view entries should be honored.

Actual result (*)

1. Out of date descriptions and values will show on frontend if merchant toggles to single store mode and forgets about old entries made at store view.
2. Since this is not accessible there needs to be clarity, if you are going to use the way you have it programmed now. "There is a value of the attribute at a store level, please confirm it will be cleared on save"

[m2-assistant[bot]]

Hi @snoroozi. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento-engcom-team give me 2.3-develop instance - upcoming 2.3.x release

For more details, please, review the Magento Contributor Assistant documentation.

@snoroozi do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [ ] yes
• [ ] no

[orlangur]

@snoroozi Single Store Mode works as expected, please read description near corresponding switch more carefully.

[snoroozi]

You guys are terrible about closing tickets. I take the time to report an obvious issue, and you act like apes. @orlangur

[snoroozi]

If it worked as expected, since I'm your user, then I would expect this. So it does not work as expected. It works as programmed, which is not well enough.

[orlangur]

@snoroozi please take a look on the message I'm referring to and then I can explain you what's wrong with your understanding.

[snoroozi]

@orlangur
This setting will not be taken into account if system has more than one
store view you mean?

My store ONLY HAS ONE STORE VIEW.

You might be missing the point. In the past I had multiple store views,
but all have since been deleted, and magento still serves the info saved at
the store view level. This is not correct behavior. The code should check
and use the default scope only if there is only one store.

On Mon, Apr 15, 2019 at 11:05 AM Vlad Veselov [e-mail]
wrote:

@snoroozi https://github.com/snoroozi please take a look on the message
I'm referring to and then I can explain you what's wrong with your
understanding.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/22344#issuecomment-483290277,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACQbJT2XwXyMjrG6pjH29m1_6-CH3iAnks5vhJVWgaJpZM4cvvPT
.

[orlangur]

Hm, I didn't expect values are not removed when you remove the store view. Please add steps regarding store view removal into description.

[maxxeh1]

I'd also like to add that even if you never had other store views, or you migrate from a Magento 1 then attribute values are saved on store views that Magento shouldn't care about. I don't believe the issue really lies in the fact that enabling single store mode should delete all store view values. I think the issue is that the admin panel clearly only pulls values from store id 0 when it's single store mode but the frontend doesn't. The frontend pulls from the lowest scope store value of it's current website if it's single store view for some reason.

This is something I've had to continuously deal with on my single store magentos since attribute values just save randomly at times and I have to go into the database to fix an issue a client shouldn't be having.

[snoroozi]

@maxxeh1 We are on the same page here. And I have also migrated from M1 last year and consistently face issues of wrong store scope attribute values displayed on frontend.

There also needs to be a way to 'reset' the values back to using default scope if merchant chooses.

At @orlangur steps for removal I can't say exactly as it's been over a year, but it was simply delete stores and websites from Magento admin panel.

[m2-assistant[bot]]

Hi @engcom-backlog-nazar. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 6. Add label Issue: Confirmed once verification is complete.

• [ ] 7. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

:white_check_mark: Confirmed by @engcom-backlog-nazar
Thank you for verifying the issue. Based on the provided information internal tickets MAGETWO-99359 were created

Issue Available: @engcom-backlog-nazar, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

[m2-assistant[bot]]

Hi @engcom-backlog-nazar. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[m2-assistant[bot]]

Hi @GovindaSharma. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[LuciferStrome]

dmcdindia1

[ghost]

+1

[arnoutvreugdenhil]

--------------- UPDATE --------------
In the end I deleted/consolidated everything and that helped.

Be very very very careful.
Make a backup. Use transactions.
Make sure to check if all records with store_id=1 also have a store_id=0 friend before deleting them.

These tables are probably the most important, but the category tables might be worth checking too. Some might be empty.

• catalog_product_entity_text
• catalog_product_entity_varchar
• catalog_product_entity_int
• catalog_product_entity_decimal
• catalog_product_entity_datetime

Check for differences:
note: the attribute ids are probably different in your store!
The md5 crap is to find tiny differences without showing a lot of data.

store1.value_id,
store0.entity_id,
store0.attribute_id,
eav_attribute.attribute_code,
productname.value as name,
LEFT( store0.value, 20) as value0,
LEFT( store1.value, 20) as value1,
LEFT( md5( store0.value ), 6) as sum0,
LEFT( md5( store1.value ), 6) as sum1

FROM catalog_product_entity_varchar as store0

JOIN catalog_product_entity_varchar as store1
ON store1.store_id = 1
AND store1.entity_id = store0.entity_id
AND store1.attribute_id = store0.attribute_id

JOIN catalog_product_entity as product
ON product.entity_id = store0.entity_id

JOIN catalog_product_entity_varchar as productname
ON productname.entity_id = product.entity_id
AND productname.attribute_id = 73
AND productname.store_id = 0

JOIN eav_attribute
ON eav_attribute.attribute_id = store0.attribute_id

WHERE store0.store_id = 0

HAVING sum0 != sum1
;

Check for store_id=1 without store_id=0 version:

store1.attribute_id,
store1.entity_id,
store1.value_id,
store0.value_id,
store1.value

FROM catalog_product_entity_varchar as store1

LEFT JOIN catalog_product_entity_varchar as store0
ON store0.store_id = 0
AND store0.entity_id = store1.entity_id
AND store0.attribute_id = store1.attribute_id

WHERE store1.store_id = 1
AND store0.value_id IS NULL

;

If there are:

UPDATE IGNORE catalog_product_entity_varchar
SET store_id = 0
WHERE store_id = 1;

Wrap it up:

DELETE FROM catalog_product_entity_varchar WHERE store_id = 1;

------------- END OF UPDATE---------------

@snoroozi Did you find a workaround for this?

Would deleting all eav properties with store_id > 0 work?
Maybe update nonexisting ones to store_id = 1 first...

Here's a rough mysql query to find the content that's published incorrectly in the shop.

store1.value_id,
store0.entity_id,
store0.attribute_id,
productname.value as name,
LEFT( store0.value, 20) as value0,
LEFT( store1.value, 20) as value1,
LEFT( md5( store0.value ), 6) as sum0,
LEFT( md5( store1.value ), 6) as sum1

FROM shop.catalog_product_entity_text as store0

JOIN shop.catalog_product_entity_text as store1
ON store1.store_id = 1
AND store1.entity_id = store0.entity_id
AND store1.attribute_id = store0.attribute_id

JOIN shop.catalog_product_entity as product
ON product.entity_id = store0.entity_id

JOIN shop.catalog_product_entity_varchar as productname
ON productname.entity_id = product.entity_id
AND productname.attribute_id = 73
AND productname.store_id = 0

WHERE store0.store_id = 0

HAVING sum0 != sum1
;

[nadroj467]

Did anyone get a fix for this? This issue has been driving me mad for months

[homecoded]

@arnoutvreugdenhil has done a good job and provided us with some mySQL queries to help us analyze the inconsistencies in the database that occurred when switching to single-store mode. In my DB I noticed that the most recent data in table catalog_product_entity_varchar was stored in scope_id "1", while the data in the frontend came from scope_id "0". With table catalog_product_entity_int it was the other way round.

In the end, after I have made a backup of the DB, I did the following:

WARNING! Do not run this directly on a live DB. Try on a test instance and validate! This may break your Magento shop.

# override values in store 0 with data from store 1 -> store 1 has newest updates
UPDATE catalog_product_entity_varchar as store0
INNER JOIN catalog_product_entity_varchar as store1
on store0.attribute_id = store1.attribute_id
and store0.entity_id = store1.entity_id
SET store0.value = store1.value;

# remove store 1 entries
DELETE FROM `catalog_product_entity_varchar` WHERE store_id=1;
DELETE FROM `catalog_product_entity_int` WHERE store_id=1;

This solved the issues on this particular project. It may not work for you, but it might give you additional hints on how to solve the issue.

[arnoutvreugdenhil]

@nadroj467 @homecoded

I found the cause for this in my particular case. This might prevent future occurence of this issue for you.

It was a CLI command that updates some product attributes.
Even if all your data in the database has store_id=0, an update through cli apparently defaults to store_id=1 and any update to a product added store_id=1 copies for the attributes.

I fixed it by adding \Magento\Store\Model\StoreManagerInterface to the constructor and calling $this->storeManager->setCurrentStore(0); on it.

[homecoded]

@arnoutvreugdenhil Interesting! Thanks for sharing.

Im my case it was silghtly different: We were doing initial product imports while in multi-store mode, and switched later to single-store mode. After the switch we did some last imports and then the customer took over and tried to edit everything in backend, which failed for some products. About a third of the 3000+ products were affected.

[LiamKarlMitchell]

Still a problem has been for 6 years? Even in Magento 1 it was an issue...
How can we fix it and keep only with store id 0 for both front end and back end?

Do I have to use /rest/all or /rest/default ?