Magento – Magento 1.9.1 Order emails not sent – cron checked – stuck in core_email_queue

I've been researching this area of Magento 1.9.1 and from what I can see all new order or order update emails will now be routed through the queue. For example this is the sendNewOrderEmail() function now.

public function sendNewOrderEmail()
    {
        $this->queueNewOrderEmail(true);
        return $this;
    }

And the queueNewOrderEmail() function forces the email into the queue.

To be sure you can add debug in the class Mage_Core_Model_Email_Template send() function to check that it uses the queue. You can also check the queued email table: core_email_queue.

However, based on my research so far - I have not been able to find any other emails that are sent through the queue - for example contact form emails appear to send normally, in the same way they used to. Which does not seem consistent with the release notes:

all Magento e-mails (including order confirmation and transactional) are now queued

I'll post another question on that as I'd like to be sure.

We have shops running where the cron script is called every minute and it isn't a problem resource-wise, but this is how you would do it with Aoe_Scheduler by creating separated cron groups:

• Create a symlink cron_email.php in your Magento root directory which points to cron.php: ln -s cron.php cron_email.php

• Define the normal cronjob for all cron tasks excluding the one sending the mail:

  */5 * * * * /usr/bin/env SCHEDULER_BLACKLIST='core_email_queue_send_all' /bin/sh /path/to/magento/cron.sh
  

• Define the second cronjob which is only responsible for sending the mail:

  * * * * * /usr/bin/env SCHEDULER_WHITELIST='core_email_queue_send_all' /bin/sh /path/to/magento/cron.sh cron_email.php
  

One advantage you'll get when separating the crons into groups is that long running jobs in the "normal" cronjob won't keep your mails from being sent and vice versa.

As @fschmengler pointed out in the comment you'll have to be cautious when using symlinks and you are on a non-Windows system with shell_exec enabled. Here is how we actually do it to avoid problems parallel execution when using symlinks:

• create symlinks with different names pointing to cron.php for every cron group
• explicitly define whether the mode of the cron is always or default

The result looks like this:

crontab:

*/5 * * * * /usr/bin/env SCHEDULER_BLACKLIST='core_email_queue_send_all,long_running_cron' /bin/sh /path/to/magento/cron.sh cron.php -m=default
* * * * * /usr/bin/env /bin/sh /path/to/magento/cron.sh cron_always.php -m=always
* * * * * /usr/bin/env SCHEDULER_WHITELIST='core_email_queue_send_all' /bin/sh /path/to/magento/cron.sh cron_email.php -m=default
* * * * * /usr/bin/env SCHEDULER_WHITELIST='long_running_cron' /bin/sh /path/to/magento/cron.sh cron_longrunning.php -m=default

Magento root dir:

ls -la
cron_always.php -> cron.php
cron_email.php -> cron.php
cron_longrunning.php -> cron.php
cron.php

This makes things a little bit more complicated but it has served us well.