Emails

Ha! Sorry about the whack-a-mole – but this one may be a quick answer.

Milo has a safety feature that stops a staging or development copy of a store from emailing real customers. When it triggers, it silences only the subscription emails and leaves WooCommerce’s own order emails alone – which is exactly the pattern you’re describing. And here’s the part that’s our fault: WooCommerce → Settings → Emails keeps showing them all as “Enabled”, because the block is applied on top of those settings rather than through them. So you were right that everything was turned on, and there was nothing there to tell you otherwise.

Could you check one thing: in wp-admin, on any page other than the Milo screens (your Plugins list is fine), do you see a yellow notice saying “Milo Subscriptions: Staging Site Detected”? If it’s there, click the “This is the production site” button in it and your subscription emails will start sending again immediately.

If that notice is not there, then this isn’t the cause and I’ll dig further – in that case, could you tell me whether anything changed on the site around when the emails stopped: a move to https, a domain or URL change, a migration or a restore from a staging copy, or anything added to wp-config.php while we were debugging the payment issue? Any of those can make the plugin think it’s looking at a copy of your store.

Either way, the next release makes this impossible to miss: the email settings screen itself will say the emails are being held back and why, and the staging notice will list emails among what it disables instead of only mentioning payments.

That’s almost certainly it, and it’s a quick fix.

What to look for: open your wp-config.php and look for a line like this. Many “how to enable debug logging in WordPress” snippets include it alongside the WP_DEBUG ones, so it may well have come in with the lines you added for the payment issue:

define( ‘WP_ENVIRONMENT_TYPE’, ‘development’ );

It might say ‘staging’ or ‘local’ instead of ‘development’. Your WP_DEBUG and WP_DEBUG_LOG lines are fine and can stay – they have no effect on this.

WordPress uses it to tell every plugin “this is not a live store”. Milo takes it at its word and switches into a protective mode designed for staging copies: it holds back all subscription emails so a duplicate of a store can never email real customers. It deliberately leaves WooCommerce’s own order emails alone, which is exactly the split you’re seeing.

And here is the part that’s our fault: WooCommerce → Settings → Emails keeps showing every subscription email as “Enabled”, because this is applied on top of those settings rather than through them. So you were right that everything was turned on, and there was nothing on that screen to tell you otherwise. Sorry for the hunt.

Two ways to fix it, either is fine:

1. Delete that line from wp-config.php (or change ‘development’ to ‘production’), or
2. In wp-admin, find the yellow “Milo Subscriptions: Staging Site Detected” notice and click “This is the production site”. That overrides the detection permanently, and works whatever the underlying cause turns out to be.

Worth doing today rather than later: what’s wrong here isn’t that Milo holds things back on staging – that’s deliberate, so a copy of a store can never charge real customers or email them. It’s that your live store is being read as a copy. The same switch that silenced your emails also pauses automatic renewal payments and their scheduled events. Your subscriptions bill every 2 months, so nothing has come due yet; clearing this now means you never find out the hard way.

If that line isn’t in your wp-config.php, then something else is triggering the detection. Do you see the yellow “Staging Site Detected” notice in wp-admin (on any page except the Milo screens)? If yes, click its button and you’re sorted either way. If no, then this isn’t the cause and I’ll keep digging — just let me know.

Either way, this was far too hard to find, and that’s on us. The next release makes it impossible to miss: the email settings screen itself will say the subscription emails are being held back and why, right under the toggles that currently claim they’re on, and the staging notice will list emails among what it disables instead of mentioning only payments.

Thanks – that rules out my first theory. Could you open one recent subscription (Subscriptions → click one that should have triggered an email) and tell me two things:

1. Does it show a customer email address? Ours are addressed from the subscription, whereas WooCommerce’s order emails are addressed from the order – so a subscription that lost its email address would show exactly what you’re seeing.
2. What do its notes say? Specifically, is there a “Subscription status changed from … to …” entry around the time of a checkout? If the status never changed, no email would have been triggered in the first place – a different problem from one that was sent and lost.

A screenshot of that subscription screen would answer both at once.

That second point matters because it splits the problem cleanly: never sent, or sent and not delivered. WP Mail SMTP fixed delivery for your order emails, so if ours were being sent they should be arriving too – which points at them not being triggered or having nobody to send to.

Perfect!

Look at the first line: Email “Activated Subscription” sent, at 3:04 PM, in the same second as the activation. So Milo did trigger and hand off that email at the right moment. Everything below it is the chain working exactly as it should: subscription created from the order, order activated, subscription activated, email sent.

Which means this was never about the emails being sent. It was about them being delivered, and that fits what you saw: you’d just set up WP Mail SMTP, and when a site starts sending through a newly configured sender, receiving servers commonly hold the first messages back for a while before accepting them. Nothing was lost, and nothing reset itself; the deferred ones were released once your sending domain settled. That’s also why your order confirmations came good first and the subscription emails followed: they simply queued behind.

Nothing to change on your side. If you want to make it stick, it’s worth checking that your SPF (and DKIM if your provider offers it) records are in place for the sending domain in WP Mail SMTP – that’s what shortens or removes that settling period, and it protects you if you ever change sender again.

Thanks for sticking with this one and for the screenshot; it made the difference between guessing and knowing.