The [Send Email] [Invoice] [Ship] buttons work and send e-mail. Only manual status change that does not send mail
1Michael, 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?– Rick BuczynskiJun 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.– MichaelCostaJun 16, 2017 at 16:10
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.
crontabis running + the task scheduler is setup
- Consult the
core_email_queuetable to verify your email was generated
- Trace the call stack on
core/email_queue::sendto 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:
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,
Email Queue System
Since Magento CE 184.108.40.206, 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
ⓘ 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
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.
$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.
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 Jun 17, 2017 at 0:23
I'm sorry, my bad English. I hope you understood. 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. 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. Jun 17, 2017 at 13:41