The only way out of this, is to open each rule and save and apply it one at a time. Hitting the “Apply All Rules” button doesn’t work.

The Cause

After saving a product (new or existing) an event fires triggering the Mage_CatalogRule_Model_Observer::applyAllRulesOnProduct function.

    public function applyAllRulesOnProduct($observer)
    {
        $product = $observer->getEvent()->getProduct();
        if ($product->getIsMassupdate()) {
            return;
        }

        $productWebsiteIds = $product->getWebsiteIds();

        $rules = Mage::getModel('catalogrule/rule')->getCollection()
            ->addFieldToFilter('is_active', 1);

        foreach ($rules as $rule) {
            if (!is_array($rule->getWebsiteIds())) {
                $ruleWebsiteIds = (array)explode(',', $rule->getWebsiteIds());
            } else {
                $ruleWebsiteIds = $rule->getWebsiteIds();
            }
            $websiteIds = array_intersect($productWebsiteIds, $ruleWebsiteIds);
            $rule->applyToProduct($product, $websiteIds);
        }
        return $this;
    }

This function is responsible for applying all the rules to the single product you just edited. In this function, all rules get loaded and applied to the product one at a time.

Now, when we take a look at the Mage_CatalogRule_Model_Mysql4_Rule::applyToProduct function, there’s a lot going on.

1. The catalogrule_product table loses all records related to your product and the current rule.
2. If the rule is not valid, the catalogrule_product_price table loses all records related to your product.

Now this is a problem! All rule prices get dropped, regardless of the other (good) rules, because the current rule is invalid. I was in fact amazed to find this kind of poor logic, but hey, we’ll fix it in a minute :p So, here you have it. What will happen in reality goes like this:

1. Processing rule A -> Invalid -> Delete all rows for the product
2. Processing rule B -> Invalid -> Delete all rows for the product
3. Processing rule C -> Valid -> Writing new prices
4. Processing rule D -> Invalid -> Delete all rows for the product

So rule C did run, but it’s hard work got deleted immediately after. Depending on how the rules are ordered in your database (table catalogrule), you may actually see some products discounted, given that rule C was your last one.

The Solution

Now, I’ve given this a lot of thought, how to best deal with this problem, and not needing to change too much core code. This is what I can up with, and it will work just fine on Magento 1.4.2.0. First of all, we won’t be editing Mage_CatalogRule_Model_Mysql4_Rule, but instead create a new model that is a replacement for the observer that started it all: Mage_CatalogRule_Model_Observer.

Instead of applying all rules to the product, I will first check which rules actually apply to the product, and then only apply those. Now, there’s one thing to keep in mind here: If all rules are valid, the catalogrule_product_price table will never get reset for the specific product, so this we’ll have to do first. After that, when we apply the right rules, it will get filled up and nothing will be lost again.

Here’s my finished code with comments:

public function applyAllRulesOnProduct($observer) {
		$product = $observer->getEvent ()->getProduct ();
		/* @var $product Mage_Catalog_Model_Product */

		if ($product->getIsMassupdate ()) {
			return;
		}

		$productWebsiteIds = $product->getWebsiteIds ();

		$rules = Mage::getModel ( 'catalogrule/rule' )->getCollection ()->addFieldToFilter ( 'is_active', 1 );

		// WOUTER - WE ARE DOING THIS DIFFERENTLY, BECAUSE MAGENTO'S OWN CODE DOESN'T WORK

		// 1. Delete all rule prices
		$write = Mage::getSingleton ( 'core/resource' )->getConnection ( 'core_write' );
		/* @var $write Varien_Db_Adapter_Pdo_Mysql */

		$tableName = Mage::getSingleton ( 'core/resource' )->getTableName ( 'catalogrule/rule_product_price' );
		$write->delete ( $tableName, array ($write->quoteInto ( 'product_id=?', $product->getId() ) ) );

		foreach ( $rules as $rule ) {
			/* @var $rule Mage_CatalogRule_Model_Mysql4_Rule */

			// 2. Find the rules that are valid
			if ($rule->getConditions ()->validate ( $product )) {

				// 3. Apply the valid rules
				if (! is_array ( $rule->getWebsiteIds () )) {
					$ruleWebsiteIds = ( array ) explode ( ',', $rule->getWebsiteIds () );
				} else {
					$ruleWebsiteIds = $rule->getWebsiteIds ();
				}
				$websiteIds = array_intersect ( $productWebsiteIds, $ruleWebsiteIds );
				$rule->applyToProduct ( $product, $websiteIds );
			}
		}
		return $this;
	}

So, that’s it. You can now save products and have the right rules applied immediately!

Liked my solution or need further help? I’m free for hire.

The Problem

When digging deeper into the problem, I discovered the problem was caused in Mage_Eav_Model_Config::getEntityAttributeCodes($entityType, $object=null), around line 475.

The code in 1.4.2.0 reads:

$attributesInfo = Mage::getResourceModel($entityType->getEntityAttributeCollection())
->setEntityTypeFilter($entityType)
->setAttributeSetFilter($attributeSetId)
//                ->addSetInfo()
->addStoreLabel($storeId)
->getData();

This results in an empty array for $attributesInfo.

In 1.4.1.1 the code was working and returned an array of over 80 elements (in my setup). The old code was:

$attributesInfo = Mage::getResourceModel('eav/entity_attribute_collection')
->setEntityTypeFilter($entityType)
->setAttributeSetFilter($attributeSetId)
// ->addSetInfo()
->addStoreLabel($storeId)
->getData();

Basically it comes down to the argument for the getResourceModel() function. The argument used to be “eav/entity_attribute_collection”, but has now been swapped for a function that returns the value “catalog/category_attribute_collection”.

I’m not sure if this is an evolutionary move Magento is making, or a glitch in the upgrade procedure.

The Solution

This new function getEntityAttributeCollection() is used a couple of times more in the same file, but never anywhere else. Instead of swapping out the new code for the old, you should take care of the problem at the core: in your database!

Take a look at the eav_entity_type table and make sure the record for “catalog/product” has the value “catalog/product_attribute_collection” instead of “catalog/category_attribute_collection”. If you change this, there is no need to change any core files!

Did this work for you? Let us know!

For this reason, I will explain how my system is set up and what practices I have developed over the years. This article is targeted at PHP hobbyists and beginners.

Development Server

First of all we require a local webserver. PHP is a server-side scripting language, which means that the

One thing I did discover with the Netbeans and Xdebug combo was that for some reason it didn’t break on breakpoints set in Netbeans. While trying to figure it out I did notice that Xdebug was loaded and actually working (I tried MacGDBp, a simple debugger GUI on Mac, and that did work), but for some reason Netbeans didn’t break.

I read many guides and instructions online, but the answer turned out to be really simple (but little tricky to figure out).

Loading the module correctly

xdebug.so (or xdebug.dll on Windows) should be loaded using:

And not using:

If you do use this way, you will get the module to load, and it will show up in phpinfo(), but Netbeans will not break on your breakpoints! So, switch to zend_extension. This has to do with the way xdebug loads, and is essential.

Making sure you have the Zend Extension Manager

This zend_extension directive relies on the Zend Extension Manager, which comes bundled with many all-in-one development packages (like MAMP). However, it did not came bundled with XAMPP on Mac. So, I took ZendExtensionManager.so from MAMP and put it in my PHP extension folder.

ZendExtensionManager.so should be loaded using the regular extension directive (obviously):

After this, you will be able to use the zend_extension directive.

Zend Optimizer doesn’t like Xdebug

If you already had the Zend Extension Manager, you will most likely also have the Zend Optimizer. You’ll probably need to turn it off. I didn’t try to get both to work at the same time, but I was informed that the 2 don’t go together.

Configure Xdebug correctly

This is the easy part. Netbeans only requires these 5 lines of configuration. While Netbeans itself will tell you to add the first 4 lines, I did figure out the 5th line is also needed.

I also added these 2 lines, but they are optional. The log is actually quite helpful for figuring out problems in the future.

Use phpinfo() to check that the settings are actually applied.

Check your phpinfo()

Now, you should see Xdebug being loaded as a Zend extension, like demonstrated below:

You will also see it loaded further down the phpinfo() page:

Conclusion

So, I hope this may have helped you. If it didn’t, leave a message and I’ll check it out.

After 1 to 2 months of study and many more years of PHP practise before that, I finally reached Zend PHP5 Certified status. The exam was arranged at my old school, and hardly took an hour. Still, there were some pretty tough questions, but I got it well covered. Still, studying the certification book will only get you 50% score, which isn’t enough. Thankfully I know the PHP manual pretty thorough, as it has been my main resource since the day I started. Woohoo!

So, I’m in the Zend Yellow Pages as of now, and here’s the proof.