In case you need a quick fix, all you need is to open the “app\code\core\Mage\Core\Model\Session\Abstract.php” file and around line 72 change “protected $_skipSessionIdFlag = true;” to “protected $_skipSessionIdFlag = false;“.

Surely this is a modified core file so for more general fix you can make yourself an extension that does the same. In such case you would most likely override method “setSkipSessionIdFlag($flag)” in the same file.

Or you can play with .htaccess file in order to try and solve the issue.

Cheers.

To see if you are on the right track, first thing you can do is to set something like “return ‘test’;” right on top of the method body. From there on you go line by line below until you reach the line that broke the response and caused the “Failed to parse response” messages.

In my case this was a completely innocent line of code that broke it, line 277 “$model = Mage::getModel($modelName);”. Notice that although inside the try-catch block, it still broke as this error in my class had nothing to do with exception, but standard PHP error.

So in essence I did two things. First I did “return ‘My model name: ‘.$modelName;” just above line 277. After that I tried to do “$myModel = new My_Model_Name()” somewhere in my code independent of API call. This is where I spotted the “Cannot redeclare…” error.

I realize these are trivial things, just felt the need to write it down is someone is having hard time debugging it.

Cheers.

It might sound strange or silly, but I guaranty you that Magento folder structure adds certain amount of unnecessary time to development process. What bothers me the most is the way you are forced to develop “by the book” extensions. Is it the lack of vision of purposely engineered concept that forces you to span your custom modules among tens of sub-folders that in the end do not belong to your extension.

What I would like to see is the WordPress or Drupal concept, where each extension with all of its files and logic lives in its one folder. No special view folders in main theme, no special layout folders in custom/default theme etc. Only one place/folder to host your extensions.

Here is my vision of extensions folder layout/structure that I find interesting and appealing.

Certanly this raises several questions like:

• Can we put javascript in this sub-folder, as it is to deep in the modules directory, is this security implication or SEO implication or, etc.
• Can we put css in this sub-folder, as it is to deep in the modules directory, is this security implication or SEO implication or, etc.
• Can we put style images in this sub-folder, as it is to deep in the modules directory, is this security implication or SEO implication or, etc.
• How does this relate to my designer doing the styling, etc.
• …

Have you ever had these problems with extensions/modules for WordPress, Drupal, Joomla, etc.? I doubt that.

I would say that easy workaround can be made for each of the above “implications”, leaving you with “one extension – one folder” concept.

Concept like that is easy to maintain, plus no robust Magento Connect is needed, etc. Certainly it has its flaws, but surely does the current one.

Enough said, for now -Just a little something I have been tinkering around.

Before I proceed I would like to emphasize that although the author mentions me personally in the book (on the page 210), my positive review of it is by no means result of that.

I would rate “Part 2: Advanced Magento development” as a must read for every Magento developer that has not yet overcome these steps. Additional bonus for the book goes on the “Apendix: API References” section that covers the use of Magento API pretty in depth. What impressed me where the “var_dump” response examples for each API call.

I have noticed that the book got some negative reviews, something in terms of “The Definitive Guide To Magento… really? Unless you’re the kind of person that in general has a hard time using computers, about 60% of this book is a complete waste of time in my opinion…”. Lets say I even agree with comments like these, but then again paying around $40-50 for the book is nothing compared to around $60-200/hour we take in professional Magento development. In such cases I would say this: I personally learned nothing new from this book, but several of my coworkers (junior developers) did and for that book payed off for us.

There is no point of me reviewing individual sections of the book here. If you are in the loop of learning Magento I would strongly recommend you purchase the book. Here are the links Amazon or Apress.com site.

Cheers.

After initial configuration I started my Magento installation. And here is where I hit the wall. My installation was OK until it reached the step where it needed to write to database. After some running time browser would give me a “File Download” dialog with file whose content says “The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.“. My first reaction is was that I forgot to boost some timeout in the config.

After several minutes of tracing the issue, I finally figured that it was a “ZendEnablerApache.dll” that was causing my “unable to service your request” issue. I traced the configuration to “C:\Program Files\Zend\ZendServer\etc\ZendEnablerConf.xml” file. There I changed the connectionTimeout to 18000 and the requestTimeout to 36000. After that I restarted my Apache and was able to install Magento and do other time consuming PHP operations.

Hope this helps some of you who might experience the same issue.

Cheers.

When you are dealing with large shop systems, with several thousands of products, then actions like these need to be handled programatically. Below is a just a fraction of the code from the full import script I have been working on last few days.

private function createAttribute($code, $label, $attribute_type, $product_type)
{		
	$_attribute_data = array(
		'attribute_code' => 'old_site_attribute_'.(($product_type) ? $product_type : 'joint').'_'.$code,
		'is_global' => '1',
		'frontend_input' => $attribute_type, //'boolean',
		'default_value_text' => '',
		'default_value_yesno' => '0',
		'default_value_date' => '',
		'default_value_textarea' => '',
		'is_unique' => '0',
		'is_required' => '0',
		'apply_to' => array($product_type), //array('grouped')
		'is_configurable' => '0',
		'is_searchable' => '0',
		'is_visible_in_advanced_search' => '0',
		'is_comparable' => '0',
		'is_used_for_price_rules' => '0',
		'is_wysiwyg_enabled' => '0',
		'is_html_allowed_on_front' => '1',
		'is_visible_on_front' => '0',
		'used_in_product_listing' => '0',
		'used_for_sort_by' => '0',
		'frontend_label' => array('Old Site Attribute '.(($product_type) ? $product_type : 'joint').' '.$label)
	);
 
 
	$model = Mage::getModel('catalog/resource_eav_attribute');
 
	if (!isset($_attribute_data['is_configurable'])) {
		$_attribute_data['is_configurable'] = 0;
	}
	if (!isset($_attribute_data['is_filterable'])) {
		$_attribute_data['is_filterable'] = 0;
	}
	if (!isset($_attribute_data['is_filterable_in_search'])) {
		$_attribute_data['is_filterable_in_search'] = 0;
	}
 
	if (is_null($model->getIsUserDefined()) || $model->getIsUserDefined() != 0) {
		$_attribute_data['backend_type'] = $model->getBackendTypeByInput($_attribute_data['frontend_input']);
	}
 
	$defaultValueField = $model->getDefaultValueByInput($_attribute_data['frontend_input']);
	if ($defaultValueField) {
		$_attribute_data['default_value'] = $this->getRequest()->getParam($defaultValueField);
	}
 
 
	$model->addData($_attribute_data);
 
	$model->setEntityTypeId(Mage::getModel('eav/entity')->setType('catalog_product')->getTypeId());
	$model->setIsUserDefined(1);
 
 
	try {
		$model->save();
	} catch (Exception $e) { echo '<p>Sorry, error occured while trying to save the attribute. Error: '.$e->getMessage().'</p>'; }
}

The import I was running had to deal with grouped and simple products (that go on that grouped products). Besides special attributes that only grouped products had, and some special attributes that only simple products have, system also had some “joint” attributes that both of the product types had. Examples below show how I called the above method to generate such specific or “joint” attributes.

//My "grouped product only" attribute
$this->createAttribute(strtolower("ShirtType"), "ShirtType", "select", "grouped");
 
 
//My "simple product only" attribute
$this->createAttribute(strtolower("Swatch"), "Swatch", "text", "simple");
 
 
//My "joint" attribute, the one that I had both on simple and on grouped products
$this->createAttribute(strtolower("InventoryMsg"), "InventoryMsg", "text", "");
$this->createAttribute(strtolower("Complete"), "Complete", "boolean", "");

Hope that above example help someone. Cheers.

This shop I was working on was relatively “flat” in its architecture. Flat in terms that it had just a few tables, with not so great “normalization”. However, this “flat” architecture produced a lightning fast web shop with speed of page loading that Magento can most of the time dream of, unless placed on truly quality server.

So, how do we transfer the categories from old shop system to the Magento. We all know that Magento CSV file requires category id’s to be placed in the appropriate CSV column. That means we need to have our categories created in front. Here is a simple example on how to programatically create two level categories in Magento.

public function createCategories()
{
	//The root category in Magento, the one you get by default install, usually has the id 2
	$_rootParentCat = 2; 
 
	/* START Create first level categories */
	$_rootCats = $this->_db->fetchCol("SELECT DISTINCT ProductCategory1 FROM SomeProductCategoryTable");
 
 
	foreach($_rootCats as $_rootCat)
	{
		$_c = $this->_db->fetchOne("SELECT ProductCategory1URL FROM SomeProductCategoryTable WHERE ProductCategory1 = ?", array($_rootCat));
 
 
		if($_c != '' && $_c != 'na')
		{
			$_cat = new Mage_Catalog_Model_Category();
			$_cat->setName($_rootCat);
			$_cat->setUrlKey($_c);
			$_cat->setIsActive(1);
 
			$parentCategory = Mage::getModel('catalog/category')->load($_rootParentCat);
			$_cat->setPath($parentCategory->getPath());				
 
			$_cat->save();
			Zend_Debug::dump($_c);
 
			/* START Create second level categories */	
			$_childCats = $this->_db->fetchCol("SELECT DISTINCT ProductCategory2 FROM SomeProductCategoryTable WHERE ProductCategory1 = ?", array($_rootCat));
 
			foreach($_childCats as $_childCat) 
			{
				$_cc = $this->_db->fetchOne("SELECT ProductCategory2URL FROM SomeProductCategoryTable WHERE ProductCategory2 = ?", array($_childCat));
 
				if($_cc != '' && $_cc != 'na')
				{
					$_catChild = new Mage_Catalog_Model_Category();
					$_catChild->setName($_childCat);
					$_catChild->setUrlKey($_cc);
					$_catChild->setIsActive(1);	
 
					$parentCategory = Mage::getModel('catalog/category')->load($_cat->getId());
					$_catChild->setPath($parentCategory->getPath());							
 
					$_catChild->save();	
					Zend_Debug::dump($_cc);	
					unset($_catChild);						
				}
			}
			/* END Create second level categories */
			unset($_cat);		
		}
 
	}
	/* END Create first level categories */
 
 
	/** Zend_Debug::dump($c->debug());
		array(25) {
		  ["entity_id"] => string(1) "3"
		  ["entity_type_id"] => string(1) "3"
		  ["attribute_set_id"] => string(1) "3"
		  ["parent_id"] => string(1) "2"
		  ["created_at"] => string(19) "2010-05-24 12:14:56"
		  ["updated_at"] => string(19) "2010-05-24 17:02:17"
		  ["path"] => string(5) "1/2/3"
		  ["position"] => string(1) "1"
		  ["level"] => string(1) "2"
		  ["children_count"] => string(1) "0"
		  ["name"] => string(6) "Sample"
		  ["url_key"] => string(6) "sample"
		  ["meta_title"] => string(0) ""
		  ["display_mode"] => string(8) "PRODUCTS"
		  ["custom_design"] => string(0) ""
		  ["page_layout"] => string(0) ""
		  ["url_path"] => string(6) "sample"
		  ["is_active"] => string(1) "1"
		  ["is_anchor"] => string(1) "0"
		  ["custom_design_apply"] => string(1) "1"
		  ["description"] => string(21) "Sample category here."
		  ["meta_keywords"] => string(0) ""
		  ["meta_description"] => string(38) "Meta Sample category description here."
		  ["custom_layout_update"] => string(0) ""
		  ["available_sort_by"] => string(0) ""
		}
	 */
}

Please not that the example above is not generally applicable. You will notice that I used it to programatically create only the two level category system. Thus, the example is not to be used as simply “copy-paste”.

Depending on the size (number) of the categories in the old shop, programatically in place of manually creating categories can save you great deal of time.

Hope that above example helps to some of you (to certain extent).

Here is how.

public function saveAction()
{
	/* START: Handle the max images per product */
	$data = $this->getRequest()->getPost();
	$images = Mage::helper('core')->jsonDecode($data['product']['media_gallery']['images']);
 
	if($totalImages = count($images)) {
 
		$maxPhotoPerProduct = 5;
 
		if($totalImages > $maxPhotoPerProduct) {
			Mage::getSingleton('core/session')->addError($this->__('Max. number of images per product reached, extra images have been removed'));
		}
 
		$_allowedImages = array_slice($images, 0, $maxPhotoPerProduct);
		//Return the allowed images back to the $_POST
		$_POST['product']['media_gallery']['images'] = Mage::helper('core')->jsonEncode($_allowedImages); 
	}
	/* END: Handle the max images per product */
	//Zend_Debug::dump(Mage::helper('core')->jsonDecode($_POST['product']['media_gallery']['images'])); exit;
 
	//Run standard saveAction()
	parent::saveAction();
}

Note that code above is from my Mycompany_Mymodule_Adminhtml_Catalog_ProductController class located in the “app/code/local/Mycompany/Mymodule/controllers/Adminhtml/Catalog/ProductController.php” file.

Meaning I overwrote the default “app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php” controller by using the syntax shown below in Mymodule config.xml file.

</config>
...
	<admin>
		<routers>
			<adminhtml>
				<args>
					<modules>
						<sintax before="Mage_Adminhtml">Mycompany_Mymodule_Adminhtml</sintax>
					</modules>
				</args>
			</adminhtml>
		</routers>
	</admin>	
...
</config>

And thats it.

For the last few days I have been playing around with my cool new Android phone, HTC Desire. Given the experience I have with everyday Magetno development (for the last 2 years as of this moment), it was natural for me to try poking around the Magento API and do some XMLRPC based apps on Android phone.

As most of you know, Android apps are Java based, while Magento is PHP based. Not a problem since we are using an XMLRPC. Right?

Well, it turned out it can be serious problem. Not because of the different technologies, but because of the lacking API documentation. For example, if you go to customer.create method definition in Magento API you can see its argument list. It says: “Arguments: array customerData – cutomer data (email, firstname, lastname, etc…)“.

I almost fall off the chair laughing when I saw the “etc…” part in the argument list. I mean, what is this, a poetry or technical document? How should a non PHP programmer that did not work with Magento know what this “etc…” stands for, and what is the full list of parameters that one can attach to “Customer” object?

I managed to “pass by” this kind of things by first doing this XMLRPC stuff from PHP and checking on the the returned parameters. While prior to that I did a loading of objects trough standard Magento model and doing a
$model->debug() to see what kind of “params/attributes” I have at my disposal. After that I simply “copied” my logic to my Android app. And it works like a charm. But my point is, that if I had no clue on Magento, and was only relying on the API documentation, while doing my Java based app, I would most likely had a rough day handling it.

Anyhow…. just wanted to share some of my bitterness on this topic. Feel free to comment, dispute me… Cheers.

When we place <active>true</active> it means is that our module is fully turned off. In such case, if some external module calls our models (classes) we will get error or some sort of exception. Reason for this is that class autoloader does not load anything trough “Mage::getModel(‘something/something’);” if this “something” is defined as model in config file from module that is turned off by <active>true</active>.

So, when would we like to turn off a module per a website level?! Imagine you are running a Magento that server as your own personal private hosted shop solution. On website A and C you want to have a cool JavaScript zoom module that shows awesome zoom feature on product photos. On site B you wish to have a different zoomer coded entirely by different JS framework etc. Something like this can easily be done just by modifying the theme files or setting up a partially different theme for this website where only difference would be in one or two layout xml files that would load up different JavaScript etc.

Besides doing a special theme/layout changes would it not be nice if you can simply say: Turn the Zoomer1 on website A and C and Zoomer2 on website B?! Maybe theme changes are not best fit to describe the possible convenience of having ModuleX turned on on websites A and C and ModuleY on website B. However, for those interested in such possibilities (scenario), here is a possible way of doing it.

First thing we need to do is to modify the app\code\core\Mage\Core\Model\Config.php file. Given that we do not modify the core file in order to avoid upgrade overwrite, we will make a copy of this file in app\code\local\Mage\Core\Model\Config.php.

In this file I will add the method with the content of code as show below.

    /** Start: Per website module on/off */
    public function handleModulesPerWebsite($moduleFiles) 
    {
        if($options = $this->getOptions()) {
 
        	$websiteCode = 'website';
 
        	$mageRunCode = $options->getData('mageRunCode');
        	$mageRunType = $options->getData('mageRunType');
 
        	//Check if we are running a valid website
        	//if($mageRunType == $websiteCode) {
 
        		$xml = simplexml_load_file('S:\Server\apps\shop\srv_staging\modules.xml');
        		$modules = array_keys((array)$xml);
 
        		$moduleFilesX = $moduleFiles;
	        	foreach($moduleFilesX as $k => $moduleFile) {
 
	        		$s = explode('\\', $moduleFile);
	        		$moduleName = str_replace('.xml', '', end($s));
					//Turn off all the other modules that are not listed in modules.php file	        		
					if(!in_array($moduleName, $modules)) {
						unset($moduleFiles[$k]);
					}
		        }    
		        unset($moduleFilesX);	
        	//}
        	//Zend_Debug::dump($moduleFiles);
        }
 
        return $moduleFiles;
 
    }
    /** End: Per website module on/off */

Highly important thing to note here. As you can see I have hard-coded the “S:\Server\apps\shop\srv_staging\modules.xml” path to one specific website folder. If you choose to play with this code, please modify it to do some current website path check and include only the modules.xml file from the currently viewed website on frontend.

And I will modify the existing “protected function _getDeclaredModuleFiles()” method to include a call towards my new method like shown below in code.

/** 
 * Start: Custom addded, calls the new Non-Magento method, 
 coded to do turn-off of modules per website. 
 * Place right below the $collectModuleFiles['custom'] variable definition.
*/
$collectModuleFiles['custom'] = $this->handleModulesPerWebsite($collectModuleFiles['custom']);
/** 
 * End: Custom addded, calls the new Non-Magento method, 
 coded to do turn-off of modules per website. 
 * Place right below the $collectModuleFiles['custom'] variable definition.
*/

Here is the full view of the modified “protected function _getDeclaredModuleFiles()” method.

    protected function _getDeclaredModuleFiles()
    { 	
        $etcDir = $this->getOptions()->getEtcDir();
        $moduleFiles = glob($etcDir . DS . 'modules' . DS . '*.xml');
 
        if (!$moduleFiles) {
            return false;
        }
 
        $collectModuleFiles = array(
            'base'   => array(),
            'mage'   => array(),
            'custom' => array()
        );
 
        foreach ($moduleFiles as $v) {
            $name = explode(DIRECTORY_SEPARATOR, $v);
            $name = substr($name[count($name) - 1], 0, -4);
 
            if ($name == 'Mage_All') {
                $collectModuleFiles['base'][] = $v;
            }
            elseif (substr($name, 0, 5) == 'Mage_') {
                $collectModuleFiles['mage'][] = $v;
            }
            else {
                $collectModuleFiles['custom'][] = $v;
            }
        }
 
        /** 
         * Start: Custom addded, calls the new Non-Magento method, 
coded to do turn-off of modules per website. 
         * Place right below the $collectModuleFiles['custom'] variable definition.
		*/
        $collectModuleFiles['custom'] = $this->handleModulesPerWebsite($collectModuleFiles['custom']);
        /** 
         * End: Custom addded, calls the new Non-Magento method, 
coded to do turn-off of modules per website. 
         * Place right below the $collectModuleFiles['custom'] variable definition.
		*/
 
        return array_merge(
            $collectModuleFiles['base'],
            $collectModuleFiles['mage'],
            $collectModuleFiles['custom']
        );
    }

With the above changes in place we now have a basic mechanism of removing unwanted custom modules from globally merged config file.

Next, we will create a new website in Magento under the “System > Manage Stores” admin section. Lets say we give this site a code name “staging” and we create a folder called “srv_staging” in our root Magento installation folder. For instance if my Magento is installed under the “S:\Server\apps\shop\” then I will place my new website in the “S:\Server\apps\shop\srv_staging\” folder. Keep in mind that when you are doing a multiple websites setup in Magento it is not necessary to set your other websites in a subfolder of root Magento. If you are not on top of the “How To Setup Multiple Magento Stores” topic then please skip this article.

Moving on, now we have a “S:\Server\apps\shop\srv_staging\” folder from which we will run our second website. Reason why I place my second website in the sub-folder of root Magento is simply to avoid playing around with virtual hosts in this example. That way I can do http://shop.local/srv_staging/ and go to my “staging” website given that http://shop.local/ points to my default base website.

In order for our “Aactivate/Deactivate Magento module per a website level” mechanism to work we will need a partially different call for “Mage:.run” in our “S:\Server\apps\shop\srv_staging\index.php” file.

Here is how it should look (at least for my example and the code above):

Mage::run($mageRunCode, $mageRunType, $options = array('mageRunCode'=>$mageRunCode, 'mageRunType'=>$mageRunType));

And for the grand finale, here is the new additional file you can place in the S:\Server\apps\shop\srv_staging\modules.xml file, with a sample content like shown below.

<?xml version="1.0" encoding="UTF-8"?>
 
<ActiveModules>
	<Ajzele_Resourcer />
	<Ajzele_Qrcode />
</ActiveModules>

All the module names declared within ActiveModules tag in this XML file are the names of the custom (community/local) modules we wish to turn on for this website. In my case I said: Turn on the Ajzele_Resourcer and Ajzele_Qrcode modules for the “staging” website.

That’s it. These little modifications and additions should enable you to have “Aactivate/Deactivate Magento module per a website level” mechanism.

Please note that this code and approach entirely are highly experimental. Thus, try not to use them in any live sites. My intention was merely to give you something to think about in case you need something like this.

Also, additional info, this experiment was done on Magento 1.4.0.1.

Cheers.