CubeCart Email Overhaul: Async Sending, Open Tracking and Template Preview
Email in CubeCart was rebuilt across 6.6.0 and 6.7.0, with an important correction in 6.7.2. If your store sends order confirmations, dispatch notices or newsletters, all of this affects you.
Asynchronous sending
The most significant change. Before 6.7.0, sending an email happened inside the customer’s request. If your mail server was slow, the customer waited. If it timed out, the customer saw an error on a page that had already taken their money.
Now email is queued and sent by cron. The customer’s checkout completes immediately and the mail goes out behind it. On a store with an external SMTP provider having a slow morning, this is the difference between a checkout that feels sluggish and one that does not.
There is a condition attached: your cron has to actually run. If scheduled tasks are only being triggered by web traffic, then on a quiet store your queued email goes out when somebody happens to visit. Set up the CLI cron runner added in 6.7.4 (cli/cron.php) as a real cron entry. This is the single most common way to get async email wrong.
The 6.7.2 bug you should know about
Async sending shipped with a significant fault in 6.7.0 and 6.7.1: store emails, including the admin order received notification and the customer order confirmation, rendered with empty {$DATA.*} fields. Customers received confirmations with blanks where their order should have been.
The cause is instructive. Template parsing had been deferred to shutdown, to keep it out of the request. But by shutdown, page rendering had reassigned the global Smarty DATA variable, so the order context the template needed was gone. The fix in 6.7.2 moves parsing to queue time, while the order context is still authoritative, and only the sending is deferred.
If you ran 6.7.0 or 6.7.1 and had complaints about blank confirmations, that was this, and it is fixed.
Open tracking
6.7.0 added open tracking with per message counters, served by a new track/open.php endpoint. It works the standard way: a tracking pixel in the HTML email, requested when the client loads images.
Understand the limitations before you make decisions on the numbers. Many mail clients block remote images by default, so opens are undercounted. Apple Mail Privacy Protection pre-fetches images regardless of whether the human read anything, so opens are also overcounted, in the other direction, for a different population. Treat open rates as a rough relative signal between your own campaigns, not as a fact about how many people read your email.
It is genuinely useful for one thing: confirming an email was delivered and rendered at all. If a customer says they never got their confirmation and the counter shows an open, you have somewhere to start.
Automatic plain text
From 6.6.0, the plain text alternative is generated automatically from the HTML version. Previously you maintained both by hand, which in practice meant the plain text copy drifted out of date and then said something wrong.
This also helps deliverability. A multipart message with a proper text alternative looks less like spam than an HTML-only one. It will not rescue you if your SPF, DKIM and DMARC records are wrong, though, and that is the more common reason order confirmations end up in a junk folder.
Template preview
You can now preview any email template from the back office. This sounds minor and is not: the previous method of checking a template change was to place a test order and see what arrived. Being able to preview means you will actually check your templates after changing them.
Every email the store sends, with its translations and an enable toggle. Click for full sized image
6.7.0 also fixed email content being lost across a save, and 6.6.0 added per-template toggles to enable or disable content, plus automatic recovery of missing email content from the language XML.
SendGrid, Mailgun and the send log
6.6.0 moved SendGrid and Mailgun out of core and into plugins, so they update independently of CubeCart releases, and promoted Mailgun to a first class sending option alongside SMTP.
The email log now records which send method was used for each message. If you have ever had intermittent delivery problems and no way to tell whether a given message went via SMTP or an API, this is the field that answers it. The email log itself was redesigned in 6.7.0 and had further fixes in the same release.
One fresh-install bug worth noting: CubeCart_email_log was not being created on new installations until 6.6.3.
Newsletters
Newsletter sending moved to asynchronous batched delivery through a new processNewsletters cron task, with throttling. If you have a list of any size, sending it in one burst is how you get rate limited by your provider or flagged by recipients. Batched and throttled is correct, and again depends on cron actually running.
What to check after upgrading
- Set up a real cron entry calling
cli/cron.php. Without it, async email is a queue nobody empties. - Send yourself a test order and confirm the confirmation arrives complete, with all fields populated.
- Preview your customised templates in the back office, particularly if you have edited them.
- Check the email log after a day’s trading and confirm messages are going out by the method you expect.
If you host your CubeCart store with us and want the cron entry set up so async email and newsletters send reliably, just ask.
