Magento2: Product Repository saves attribute values for existing product always on "Default Store Level"

[itaymesh]

Preconditions

1. Magento 2.1.2
2. PHP 7
3. Mysql 5.6

Steps to reproduce

1. Create a CLI command to create/update a production
2. Execute the comment (new product)
3. Execute the comment (update product)

Expected result

1. New Product: values are saved on "All Store Views"
2. Update Product: values are saved on "All Store Views"

Actual result

1. New Product: values are saved on "All Store Views"
2. Update Product: values are saved on "Default Store View"

Seems like the product repository class overrides the product store id and always assign default store id

app/code/Magento/Catalog/Model/ProductRepository.php#L530

$productDataArray['store_id'] = (int)$this->storeManager->getStore()->getId();

The only way to work around this issue is by getting the existing product with explicit parameter:
$product = $this->_productRepository->get($sku, true, 0);

and use the deprecated save method of Magento\Framework\Model\AbstractModel class at line 629.

[mattcoz]

This is driving me crazy. Updating a product in the backend always saves attributes with store_id of 0 and then on the frontend it looks up attributes using store_id of 1. So the only way to update anything is to do so directly in the database. This is with single store mode enabled, which should mean that there should only be ONE store not two.

[leitot]

I have this issue as well. I fixed it with a hack but is something going to be done about this?

[p3mbo]

I can confirm that this is an issue for me too still. Magento 2.1.6

[mattcoz]

What kind of hack did you use? This is really a debilitating issue and the
developers don't seem to care at all.

• Matt

On Mar 27, 2017 2:24 PM, "leitot" [e-mail] wrote:

I have this issue as well. I fixed it with a hack but is something going
to be done about this?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/7720#issuecomment-289536701,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUf75koyoYhVYhjfucIs3xidcrCeJxHks5rp_uNgaJpZM4LHJ7x
.

[leitot]

I wrote a before plugin for the save() method for the type Magento\Catalog\Model\ResourceModel\Product. Inside beforeSave() I set the store ID correctly on the product (after the ProductRepository's save() method messes it up)

[mattcoz]

Thanks, I'll give that a shot. I have the same problem with the category
repository too.

• Matt

On May 22, 2017 9:03 PM, "leitot" [e-mail] wrote:

I wrote a before plugin for the save() method for the type
Magento\Catalog\Model\ResourceModel\Product. Inside beforeSave() I set the
store ID correctly on the product (after the ProductRepository's save()
method messes it up)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/7720#issuecomment-303269134,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUf75oBD3hoHTgjSLK6Qrr9hU7PmiZoks5r8j5bgaJpZM4LHJ7x
.

[cherreman]

I have this issue in CE 2.1.7.

The save method in the ProductRepository is incorrectly setting the store_id property on the product.

The fix is to check if the store_id is already set on the product, and if not, set it. Add the if-statement around the line below:

if (!isset($productDataArray['store_id'])) {
    $productDataArray['store_id'] = (int)$this->storeManager->getStore()->getId();
}

[magento-engcom-team]

@itaymesh, thank you for your report.
We've created internal ticket(s) MAGETWO-83254 to track progress on the issue.

[kanduvisla]

One could argue that this is not an issue but a feature: what Magento does: is when saving a product, it looks at the current store to determine where to save the attributes to. You could solve this by using emulation when using CLI:

/** @var \Magento\Store\Model\App\Emulation $this->emulation */
$this->emulation->startEnvironmentEmulation($product->getStoreId(), Area::AREA_ADMINHTML);
$this->productRepository->save($product);
$this->emulation->stopEnvironmentEmulation();

Wrapping your save()-method between these 2 lines also fixes the issue. However, I do agree that re-saving a products saves attributes for all stores and unchecks the 'Use Default Value' is unintended behavior so it would still classify as a bug.

[cherreman]

I'm not following the argument that this is a feature. The inner workings for saving a product are not intuitive and IMHO not correct: When I'm given the option of getting a product for a specific store, and I update that product, I would expect that a save operation would update that exact product (based on its store id).

If store emulation needs to be used, then the API would need to indicate this as well. Getting a product for a specific storeview via a parameter on the 'get' method should hence not be possible (which would be a pity).

[okorshenko]

Hi @itaymesh
we have a Pull Request for this issue. We are testing the solution right now.

[magento-engcom-team]

Hi @itaymesh. Thank you for your report.
The issue has been fixed in magento-engcom/magento2ce#967 by @p-bystritsky in 2.2-develop branch
Related commit(s):

• a2ae375499a807f06a677d2e7c5a7ed7e130b0b8
• 64a516128431f85b7ae623461117b5c9308fea05

The fix will be available with the upcoming 2.2.5 release.

[bpoiss]

I am on 2.2.2 and if I save a product from the backend the ProductRepository save method is not called at all. I see vendor/magento/module-catalog/Controller/Adminhtml/Product/Save.php is calling $product->save().

Am I missing something or how can this fix work for you @cherreman, @okorshenko?

[cherreman]

@bpoiss Our context is that we are importing products from an external system. We use the ProductRepository to save the products in the code of our import script.

[bpoiss]

@cherreman thanks for your response. Do you have any idea how this issue can be fixed also for saving products via backend?

[magento-seis10]

Still present on 2.2.6 EE adding new product from API using catalogProductRepository

[schmengler]

This fix was never ported to 2.3 - why?

[m2-assistant[bot]]

Hi @engcom-Charlie. 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.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.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. Add label Issue: Confirmed once verification is complete.

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

[magento-engcom-team]

:white_check_mark: Confirmed by @engcom-Charlie
Thank you for verifying the issue. Based on the provided information internal tickets MC-30488 were created

Issue Available: @engcom-Charlie, _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-Charlie. 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.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.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. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[magento-engcom-team]

Hi @itaymesh. Thank you for your report.
The issue has been fixed in magento/magento2#26470 by @engcom-Charlie in 2.4-develop branch
Related commit(s):

• 042df4153f29e6dfb18604ac0ca72c4a0671ef58
• a039ff41d4938d06e507778aaac4983e12ae8421
• 13af48ab3e53f9ec4d2d29dec28d39cffd7c9e3b
• a5d735597be47651535f1504d4e2a67377996a1c
• 8c8949db53c3eac5bf328889b72c0da01afc0b2b
• 2c155171b27da618df84c123c3aa9312f7ccd0bb
• 156b3c285baba8df7ec04853746fbf44e8ed6d83
• 347001fe941d4e2c3ce46926fa75d77f52037037
• 28b5d9d59803825e0bc9e340716cd269c7e26b6a
• a892a197f9a0a4b5f61af65ca0a71dca425caf7e
• 9b9d12351b679d72987d7f6799d07a1faa9cf216

The fix will be available with the upcoming 2.4.2 release.