19

I have implemented custom Magento module that loops trough data from external service and updates price, weight, name and some other product attributes in Magento multi-language, multi-store website.

My solution is pretty straight forward (inside my Model invoked by Cron every day), as following:

/* THIS IS CODE SNIPPET INSIDE FOREACH LOOP */
$storeId = (string)$jobConfig->store; //cron for each store
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

$extistingProduct = Mage::getModel('catalog/product')->loadByAttribute('sku', $sku);
$extistingProduct->setPrice($newPrice); //update price
//some code here dealing with Associated products of Configurable product probably not relevant
//...
$extistingProduct->setCanSaveConfigurableAttributes(true);
$extistingProduct->setCanSaveCustomOptions(true);

$extistingProduct->setConfigurableAttributesData($configurableAttributesData);
// This tells Magento to associate the given simple products to this configurable product..
$extistingProduct->setConfigurableProductsData($configurableProductsData);

$extistingProduct->setStoreId($storeId);

$extistingProduct->save();

I have this in cron running daily, separately for each Store. It usually works correctly, only changing the price of each product per Store, but sometimes a weird things happens (like once every 2 months) - all other attributes besides price get overwritten from Store X to current store $storeId. Meaning that all my English product description become German (for ex.) for all affected products.

I have no clue how could this happen, since every time I debug it is working correctly, only changing the price in current scope, which I explicitly set, but leaving all other product attributes intact. It seems like it loads all product data from Store X, sets price and then stores all those values to store which I set before saving product by calling $extistingProduct->setStoreId($storeId).

In situations when this happens, all attributes get overwritten from same Store (for example all English texts become German, but in other case all will become Spanish - they are all from one random Store).

Does anybody have a clue how could this possibly happen? What am I doing wrong?

Cœur
  • 37,241
  • 25
  • 195
  • 267
KoviNET
  • 717
  • 1
  • 7
  • 23
  • you can use this updateAttributes function like this $attributesData = array("price" => $data['price'], "special_price" => $data['special_price'], "special_from_date" => $data['special_fromdate'], "special_to_date" => $data['special_todate']); store wise Mage::getSingleton('catalog/product_action')->updateAttributes(array($productId), $attributesData, $storeId); – faizanbeg Apr 02 '16 at 13:49
  • I think this is just different notation for the same thing I am doing? I don't see how can this solve my problem. – KoviNET Apr 04 '16 at 06:46
  • Your code is too situational for us to fix like it is on your question right now. The problem could come from a lot of factor like where you define `$extistingProduct`. If you want some help, then pasting the full foreach loop, at least, would help. – β.εηοιτ.βε Apr 04 '16 at 10:18

3 Answers3

1

Yeah that whole "logic" is pretty nasty in Magento. Here is what you need to know:

When you load a product you load what is currently set as the scope, in your case the admin-scope which is the default. So what you are doing is loading from admin-scope and saving that into a store-front. So if a "random" language-change happens check what the default values of that product are, you might be surprised.

My advice:

  1. make sure you load each product in the same scope you want to store it in, so set the scope before you even load it
  2. remember that website/global attributes are overwritten each time you store the product
  3. Try to avoid the built-in load/save-methods and instead use other methods that write attributes directly and only for the desired scope

We have an extensive custom product import/update mechanism and in order for everything to work with load/save we first change and save the global values and then we load/save for each store-front changing store-front specific values.

greenone83
  • 558
  • 4
  • 12
0

I do the same behaviour as you daily, and I implemented a cron with magmi as L. Palaiokostas mentionned. It is working perfectly, I sync 200k products daily like that. The thing I did is make a temporary table where I gather all external data, and with magmi I do my request which compares magento's data to my temporary table. This gives me a delta which is updated or created automatically by magmi.

I was sceptic at the begining and spent several weeks on this, but it works since a year without troubles!

Hope this will help.

Nicolas D
  • 1,182
  • 18
  • 40
  • I have only 3k products and my update in this way takes about 30 - 40 minutes per store. By using Magento REST / SOAP API update process in even much slower and it's not even completely supported for configurable products. So it seem like Magmi is a good alternative, I will give it a try. – KoviNET Apr 08 '16 at 10:22
  • FYI It took me 16 hours if I remember well to upload a catalog of 100k new products separated in 7 stores. just tonight, my daily delta import took 14 min to resync all prices and product that had been changed from my external catalog, so it is quite quick according to the amount of distant data. At the begining I was using normal magento and it was crashing every night, it was horrible! Magmi was such a salvation in my project in fact :) – Nicolas D Apr 08 '16 at 12:48
-1

I had a similar problem and i couldn't find a way to get it right using Magento's native functionality. I end up using Magmi (Magmi's API to be more specific) to properly create/update my products.

P.S. I know this is not the "Magento's Way", but this was the only way i found after spending a lot of time researching. So i am posting this as an alternative solution.

L. Palaiokostas
  • 987
  • 6
  • 8
  • I was also considering Magmi but I have quite complex update system already coded with many specifics about configurable and bundle products. But since my solution is also getting slow I will give Magmi a try. – KoviNET Apr 05 '16 at 10:40
  • 1
    It may be "painful" to turn your implementation to a new one, compatible for magmi, but performance wise it totally worth it. Magmi is extremely faster on creating / updating products than the native Magento way. – L. Palaiokostas Apr 05 '16 at 20:50