The [Send Email] [Invoice] [Ship] buttons work and send e-mail. Only manual status change that does not send mail

not send email

  • 1
    Michael, I have some questions to help clarify your request for everyone. Have you tried any other steps to debug this issue? Was it ever working previously? Is this a production issue? Are you aware of the server's mail system configuration? Do you have the ability/knowledge to test it? Commented Jun 16, 2017 at 15:56
  • Rick .. thanks. The [Send Email] [Invoice] [Ship] buttons work and send e-mail. Only manual status change that does not send mail. Outside it all works perfectly I am a beginner in magento. Commented Jun 16, 2017 at 16:10

1 Answer 1



I'm not exactly sure of your problem, but I'll walk you through these systems in Magento as a beginner to help you find the solution on your own.


  • Ensure crontab is running + the task scheduler is setup
  • Consult the core_email_queue table to verify your email was generated
  • Trace the call stack on core/email_queue::send to confirm send success

Long description below ...

Order Comment Request Processing

When you click the Add Comment button, you are posting the comment to this file:


In this class, its addCommentsAction method is being called.

ⓘ See http://devdocs.magento.com/guides/m1x/magefordev/mage-for-dev-3.html for more information on controllers.

Depending on your version, see around line 285, for this call:

$order->sendOrderUpdateEmail($notify, $comment);

You need to know that $order is an instance of Mage_Sales_Model_Order, the corresponding class which can be found here:


So if you inspect that class, find its sendOrderUpdateEmail method. It will show you how it simply wraps the call to a sibling method, queueOrderUpdateEmail.

Email Queue System

Since Magento CE, a mail queue was introduced to defer sending of mail until a later time. It requires that the Magento task scheduler system is working, and that system is usually dependent on the host crontab service.

ⓘ See http://devdocs.magento.com/guides/m1x/install/installing_install.html#install-cron to make sure your task scheduler is working.

If that was working as expected, you can go a little deeper from where we left off in the last section. Review the queueOrderUpdateEmail method on the order model, paying close attention around line 1452:


In the middle of the $mailer model we are injecting $emailQueue before "sending" the email. By injecting a queue, we are requesting that Magento does not send the email immediately, but store it in the database until the task scheduler picks it up a little later.

The $mailer object is an instance of Mage_Core_Model_Email_Template_Mailer, and its corresponding class is here:


ⓘ Beginner's tip: do you see the pattern in the class name and the file path? This is the secret to Magento's autoloader. Here's a decent article to get your feet wet with it: http://excellencemagentoblog.com/blog/2015/05/17/magento-autoloader-and-compilation-process/

So this class's send method will be called, and if you study ~lines 75-84 you will see another call out to $emailTemplate, the "email template processor model." This model takes our email template and generates HTML output (the final email content). The corresponding class is Mage_Core_Model_Email_Template, and the file is found here:


We're getting closer. Study its sendTransactional method, which ultimately points to the sibling send method. It is in this method where we see the queue at work. Lines 407-426 demonstrate how Magento, upon detecting that we passed in a queue object, will take the generated email content and write it to the database as a record to process later.

ⓘ Advanced tip: the database table here is core_email_queue. The only way to know that is to understand how Magento model's connect to the database. For more information read here: http://alanstorm.com/magento_models_orm/

If you check the table holding these queue records, core_email_queue, you should find your email bound for the recipient sitting in there.

The queue is configured to be processed every minute. So long as your task scheduler is working properly, you can expect that this queue record would be processed shortly after it went into the table. This table maintains the time at which the emails are processed. See the processed_at column of the table to confirm.

Final Thoughts

I've only walked you through the process of how Magento sends order update emails. It's up to you to do some research at each of these steps along the way to confirm that information is being sent as it should.

If you studied the context of the code I referenced, you might have noticed that when adding a comment, the "Notified ✔" status is saved to the comment before the email is actually sent. This is misleading, because you think the status indicates a successful mail send, yet it only means you elected to notify the customer.

Examining the mail queue in the database is probably your best bet to diagnose this.

  • I was able to find by checking the places you mentioned. I changed [ $mailer->setQueue($emailQueue)->send(); ] to [ $Mailer->send(); ]. And the email was sent. I looked in the database where you mentioned and the emails are really getting stuck in the bank. I believe I need to configure Cron. that's right Commented Jun 17, 2017 at 0:23
  • I'm sorry, my bad English. I hope you understood. Commented Jun 17, 2017 at 0:26
  • I managed to solve it, I disabled cron myself! Was giving api problem with different versions. Thank for your help. Commented Jun 17, 2017 at 3:40
  • You're welcome. Note that editing the core to remove the queue is discouraged, for a test/dev environment you should be OK. Magento uses a queue in order to reduce the chances for transaction failure, like with order placement during checkout. Commented Jun 17, 2017 at 13:41

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.