Dan Wich (MailMechanic)

Am I understanding correctly that SendGrid is only showing your manually-triggered emails?

If so, I wonder if there’s a cron issue or something, though I don’t know why that would specifically show up on 3.6.5. Could you post your System Report? Maybe there will be a clue in the Action Scheduler section.

Just to confirm, are the successfully reaching a status of Processing on their own? And you’re manually change the status to something else and back to Processing/Completed to get the email to go out?

Does SendGrid’s Activity Feed also show no attempt to send the email (or any errors)?

If it’s the site in your profile, it’s using the Varnish caching system, probably provided by your host. They may be able to use the following configuration to fix it:
https://docs.woocommerce.com/document/configuring-caching-plugins/#section-5

Is it possible your host has some caching enabled on their end, or that you’re using a CDN service (Cloudflare, Cloudfront, etc.) that might be caching?

Hmm. If it’s any comfort, it *should* be working the way you want (with WooCommerce sending an email that contains a link for them to reset their password).

If you’d be comfortable with me creating a test customer account and trying the password reset, could you post the URL of the store? And/or the System Report (WooCommerce > System Status > Get System Report)?

To clarify, are you getting that email after opening WooCommerce’s version of the lost password page (usually /my-account/lost-password) and entering an email?

It sounds like you’ve ruled out the common plugins, but you still might want to glance over my list of plugins that frequently mess with the password reset process. Sometimes they’re not the ones you’d expect.

I don’t think it’s due to the automatic username/password options being turned on, because that seems to work the way you’re expecting in my testing.

I don’t see any code changes in 3.6.5 that I think would affect it (most recent changes were about a year ago). And it does work for me on 3.6.5.

Any chance your templates are overridden (check WooCommerce -> Status and scroll down to Templates: Overrides)?

The only other things I can think of:
1) Maybe it’s sending the default WordPress registration email instead of Woo’s due to a plugin or code snippet?
2) Maybe an email customizer, security plugin, or translation plugin is altering the mail?

Can you describe what you mean by it hanging on that line (an error, a timeout, etc.)?

If you’re confident that line is the issue, you could ensure WP_DEBUG_LOG is on and do an error_log of each step (e.g. error_log(print_r(WC(), true)) then error_log(print_r(WC()->mailer(), true)), etc.) to see what part is failing.

Thank you kindly!

That email is manually-triggered, at least with straight WooCommerce. Are you wanting to invoice people after they place the order, or could the “Processing order” email work for your purposes?

You might be able to find a hook or plugin to change the product details shown after checkout. I tried woocommerce_get_item_data, but it only helped for the checkout process, not the final order details.

You can mouse-over the little gray question marks for some more details, but it should be the “Processing Order” one if their payment goes through.

When you do Stef’s suggestion of disabling plugins, try starting with Conversio. I think I remember it disabling some of the built-in emails because they want to manage the email flow on their end.

It looks like my string was slightly different than yours because I was on an older version. But after updating I get one that matches yours:
Alas. Just to let you know — order #%1$s belonging to %2$s has been cancelled:

I was able to find it under Loco Translate -> Plugins -> WooCommerce -> [Language] and entering “Alas” in the filter box. It does show up a little unrecognizable because of the placeholders and HTML encoding though:
Alas. Just to let you know — %1$s has cancelled order #%2$s:

If it doesn’t show up there for you, it might be worth checking for any plugins that might be altering the emails, and making sure there’s nothing listed in the template overrides section at the bottom of WooCommerce -> Status.

+1 on Stef’s suggestion, but if it doesn’t fix the problem, I list a couple other causes here.