I ran in to a challenging situation the other day.
I recently helped fast-lane an ecommerce site for a small book store, and the traffic has been booming. Where I expected a few dozen orders out-of-the-gate, and to slowly correct any issues, it blew everyone’s expectations away, taking in hundreds of orders the first week. They’ve seen over 2k orders (that’s individual orders, not dollars) in less than a month. Awesome for the bookshop! Not so awesome for the over-whelmed dev :x
Initially, Paypal was the only payment gateway, and Paypal sends confirmation emails when orders are placed.
No news is good news, right? Wrong.
We integrated another payment gateway, only to realize Magento wasn’t automatically sending out order confirmation emails… All of the prior order confirmation emails had been sent by Paypal. And Magento hadn’t sent squat! Ruh-roh.
My first guess was correct: I hadn’t set up the cronjob for cron.php. Duh!
I logged in to Media Temple’s AccountManager and set up a simple cron set to hit the cron.php file every 5 minutes. “This should do the trick,” I think:
Easy enough! Except it didn’t work.
No emails firing out, and no email from the cronjob saying it has experienced any issues.
Enter AOS Scheduler, a free Magento extension which gives me a timeline view of the cron schedule, and allowed me to manually trigger the would-be cron’ed email blasts. It also gave me a heart-beat cron which ensures that you crons are periodically running. This proved vital in my upcoming troubleshooting.
Catching up and looking forward
With the ability to manually trigger these emails, I addressed the back-log of unsent order confirmations: I manually fired core_email_queue_send_all. This resulted in a 504 error on the admin side (likely a PHP resources issue would could be alleviated by a few php.ini tweaks), and then the admin panel would come back up after a few minutes… Log back in, run the send all cron again, break the site again. It was clumsy, but each time it ran, Magento fired out about ~200 order confirmation emails. Note: This was around 1AM, during a low traffic time for the site, in case the admin-side timeout had impact on the front-end.
After the back-log was eliminated, I was able to manually visit cron.php via my web browser and the new batches would fire out. At this point, everything works except for the actual cronjob on Media Temple’s GS.
It was time for ol’ trial & error:
- Make a change to the cron configuration
- Wait for the 5-minute cron to trigger
- Look for an email from the cron, checking for errors
- Look at the AOS Scheduler interface to see if the heart-beat is refreshing
I concluded that no combination of /usr/bin/php, php, php5, or suggested precursor was going to trigger this cron as desired. It was simply beyond the capabilities of the Grid Server limitations, according to one of their support team… I was contemplating a 3rd party cron when I tried curl, almost out of desperation:
Shit. Still nothing. Oh, wait! curl can work for external URLs, and if the objective is to simply hit cron.php, we could try:
And it worked! I received the curl respond by means of the cron email, AND the AOS Scheduler’s heart-beat was refreshing! I almost did a cart-wheel, except I knew that would end poorly.
One Last Tweak
To only receive notification in the case of an error, I changed the cron configuration to read:
curl --silent http://example.com/cron.php
- Read your documentation thoroughly. Mangeto 1.9.1 mentioned the cron change in the release notes, but I overlooked it. I could have been aware of this issue sooner, or perhaps been ahead of the issue entirely and resolved it before it caused any concern for customers and/or the shop owner.
- Troubleshooting resources are abundant online, and can take you a long way, but every situation is unique. Discuss your issue, in detail, with people of a related expertise. They may have valued insight and experience.
- Someone, somewhere, (probably) knows how to fix this. When all else fails, find someone who knows more than you do. I didn’t quite hit this point, but I wasn’t far from it. If you can’t do it, use reputable job boards to find the experts that can. It’s better to out-source than to spin your tires. And treat anyone you work with like you would want to be treated; they may become a valuable resource for future projects!
One last note: If you’re using Media Temple for a Magento deployment, they recommend using their virtual server solution (VS). I agree with this. While our deployment is functional as-is, looking forward, we may run in to scaling issues. We’re currently considering migrating to the VS after the initial traffic rush starts to taper.