Dan Wich (MailMechanic)

This doesn’t fix the root problem, but does it work if you manually put in the # in the text box? I’m thinking there’s some problem that’s preventing the JavaScript color selector controls from adding the # on your site, because they’re correctly including it on my test site.

Definitely. I assume it’s MailChimp’s Mandrill service? If so, here’s some info on it: https://mandrill.zendesk.com/hc/en-us/sections/200775417-Open-and-Click-Tracking

Yeah, there’s nothing in WooCommerce core that generates URLs like that. And it looks exactly like the common click-tracking URL structure from email services.

That looks to me like a click-tracking URL from either the abandoned cart service or an email service your mail is sent through. If that’s what it is, you’ll need to follow the provider’s instructions to set up your click-tracking subdomain in your DNS.

That sounds suspiciously like your password reset is set to use WordPress’s default reset (or a plugin) instead of WooCommerce. Does the subject line say “[SiteName] Password Reset”? If so, that’s the WordPress email.

My password reset troubleshooting page will probably help, particularly the sections on recognizing overridden login URLs and the commonly-conflicting plugins section.

I don’t know of a place that documents all of that, but generally three things influence when the emails go out:

• If all the information necessary for the email is available when the user takes the action (new account, new order, etc.), WooCommerce immediately sends the email unless you’ve intentionally set up background/deferred emails.
• If it’s dependent on an external action (like a payment gateway callback), it’ll be sent when that action occurs.
• If it’s dependent on “polling”/scheduling (like subscriptions), the timing may be unpredictable because of WP-Cron being used. You can decrease that delay by changing how often it’s called.

You might still see some additional delays from the process by which your email makes it from your server to the recipient.

Hmm, I’ve not specifically looked at GoDaddy email logs, but I found a message on their support forum implying that their support team has access to them, at least. So it might be worth contacting them to ask them to take a look, especially since it sounds reproducible enough that you could give them an exact time stamp to look at.

That is really strange, especially given it’s showing up in the email log plugin. Could you get access to any logs on the outgoing email server/service itself? Maybe it has some spam filtering of its own that’s getting triggered prior to the receivers’ spam filtering. Sometimes those get triggered by things you wouldn’t expect.

shujaat92, are any emails (contact forms, order emails, etc.) going out from the site? That error makes me think something about mail delivery is configured incorrectly:
https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting#could-not-instantiate-mail-function

If no mail is going out, I’ll second NickGreen’s suggestion of trying SMTP: it might be easier than trying to figure out what the underlying problem is.

I’ll second NickGreen’s suggestion of trying WP Mail Logging, it’ll help narrow down the source of the problem. After that my password reset troubleshooting guide has a couple sections that might help:

1. Reset email troubleshooting
2. General troubleshooting / common conflicts

One thing that might trip you up is that the background emails aren’t directly added to WP-Cron. They instead go through WP-Background-Processing with keys that look like “wp_1_wc_emailer_batch_4403b7d6fedac5a9e4cd16c1e25ef7b3” (I wrote a little bit about that here).

But it sounds like they’re still sending too quickly to be explained by WP-Background-Processing picking them up? If so, it might be worth doing something like var_dump( $wp_filter['woocommerce_defer_transactional_emails'] ); to see if anything else is hooking that filter at a higher priority.

This doesn’t fix your root problem, but might be worth it since people can’t check out: if you remove the “Questions about the Terms of Service should be sent to us at [email link]” from the end of the Terms and Conditions page (https://beachstickers.ca/terms-and-conditions/), does the checkbox resume working?

I haven’t looked at it very thoroughly, but I notice that the text of your terms and conditions has broken HTML with an unclosed “mailto” link. I suspect it’s causing the whole “I have read and agreed to the website…” link to open the mail client, and that it’ll work if you edit your terms-and-conditions.

I wonder if it could be an issue on your comment-approval settings? If I remember right, the admin and the post/product author get the approval email, and just the post author gets the final “new comment” email.

I mention that because in my quick test with comments automatically approved, the product author got the (sole) notification email. I didn’t strip out plugins like you did though, so maybe one of them is altering the behavior on my end.

I bet you’ll find the order status has been set to Processing (thus triggering those emails) prematurely. I’m not familiar with PayPal PLUS für WooCommerce, but I’d expect they’re probably the ones changing the status, so you might have to check with their support.