I'm having little problem with my cron task catalogrule/observer::dailyCatalogUpdate (catalogrule_apply_all) which is triggering invalidated Page blocks HTML cache. I'm running my magento 1.9.1 on CentOS VPS with php 5.5 (with opcache enabled) and mysql 5.6. Anyone have an idea, what could possible be wrong?

  • The Cron job is now always Invalidating Blocks HTML Output Cache. This since (really annoyingly) we now need a CRON job to send emails (that was a really stoopid idea, BTW, who wants to have the customer WAIT for an order acknowledgment?). Why has this not been fixed, I ask myself... Jun 3, 2015 at 9:18

3 Answers 3


The implementation of the dailyCatalogUpdate method has been changed in it now calls Mage_CatalogRule_Model_Rule::applyAll which always invalidates the block html output cache. As indicated by Fabrizio Branca, this is wrong for a number of reasons.

To resolve this, we have created a rewrite of the dailyCatalogUpdate method that does the following:

  1. Refresh the block html cache after running the job. Rationale: cron jobs should clean up after themselves.
  2. Only run the cron job when there is at least one catalog rule for which is_active is not 0. Rationale: for this situation, running the cron job has no effect. More precisely, in a standard Magento installation, users can only add/remove a catalog rule or change the value of is_active via a deliberate admin action on "Promotions" > "Catalog Price Rules" or "Catalog > Attributes > Manage Attributes" (removing an attribute, or setting the is_used_for_promo_rules value to false for an existing attribute). After these actions, the catalog rules are either applied automatically, or the user is informed that he/she should apply the catalog rules. So there is no need to have a daily cron job to do this.

Code of the observer class:

class ISAAC_CatalogRuleFix_Model_Observer extends Mage_CatalogRule_Model_Observer
    public function dailyCatalogUpdate($observer)
        $collection = Mage::getResourceModel('catalogrule/rule_collection')
            ->addFieldToFilter('is_active', array('neq' => 0));
        if ($collection->getSize() == 0) {
            return $this;
        $types = Mage::getConfig()->getNode('global/catalogrule/related_cache_types')->asArray();
        foreach (array_keys($types) as $type) {
        return $this;
  • Any chance you could add the config.xml to this answer? Or can this just be changed by rewriting the function in the local code pool? Struggling to get it right and could use a bit of help. Thank you. Nov 16, 2018 at 15:40

I'm definitely experiencing the same issue.

The first "fix" I attempted was to disable Mage_CatalogRule under Admin : Advanced : Advanced. This completely disables catalog & shopping cart rules, which I don't use myself. Unfortunately the cron job continues to run even with the Mage_CatalogRule module disabled. Seems like a design flaw.

I then made a copy of app/code/core/Mage/CatalogRule/etc/config.xml and placed it into the local folder. Then I commented out the crontab section as follows:

<!-- crontab>
</crontab -->

This file does not appear to override the core file, for some reason I cannot figure out. So I ended up editing the core file and that definitely made the HTML Blocks invalidation go away.

This is not a great solution if you need catalog rules, but it works for me since I don't use them.

  • I did not solve the problem. What I did is just a little workaround. I have set up cron task, to clean HTML cache just after catalogrule_apply_all is executed.
    – Iztok
    Jan 27, 2015 at 8:22
  • I wish I knew whether this is a problem unique to our installs or whether all Magento stores exhibit this behavior.
    – Chrysippus
    Jan 31, 2015 at 19:08

OK - so we see that the CRON job in question is catalogrule_apply_all catalogrule/observer::dailyCatalogUpdate

This creates the error: "One or more of the Cache Types are invalidated: Blocks HTML output."

I run the scheduler extension that lists all the CRON jobs and easily allows disabling any of them, so there is a work-around.

The question is, do any of the developers accept that this is a bug?

Here's a more comprehensive report than I'm able to make: https://gist.github.com/fbrnc/a758315e2d9af024ab0f

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.