Christopher Shennan’s Blog

Another day… another magento problem!

I was asked to look into a problem with an automated stock level update script not updating the stock levels.  This update script was using the Magento API and on the face of things everything looked ok as the script ran without any errors, the product prices got updated but the stock levels never changed.

After a bit of investigating I found the problem was caused by an incorrect usage of the Magento API and the original update statement was similar to:-

$proxy->call($sessionId, 'product.update',
	array('PRD0001', 
		array(
			'price'=>12.50, 
			'qty'=>12, 
			'is_in_stock'=>1, 
			'discontinued'=>0
		)
	)
);

However, the update of the is_in_stock and qty fields is not done against the product (via product.update) but against the product inventory (via product_stock.update) so this code had to be updated to the following:-
continue reading…

A few weeks ago the company I work for was changing the server that several client sites are hosted on and this included a website built up using the eCommerce package magento.  All of the migrations went ahead without any problems with the exception of this magento site and it had a couple of us stumped for quite a while.

Process

We followed the basic plan for the migration:-

• Copy magento files up to the new server
• Backup the database on the old server and restore on the new server and set the MySQL user
• Update the “web/unsecure/base_url” and “web/secure/base_url” keys within the core_config_data

This seems to work well for almost everyone we found asking for migration help on the forums but did not work for us.  We even tried updating the /downloader/pear/pear.ini to ensure any additional modules downloaded via Magento Connect would install properly (I have since found out you can simply delete the pear.ini and Magento Connect will rebuild it with the correct paths!)
continue reading…