skafte

Hi @dwpriv,

Hope you’re well. Just following up as I’m still seeing this problem across multiple renewal orders.

The invoice PDF is consistently attached to the renewal email sent to the store owner, but missing from the copy sent to the customer – across all renewal orders. This looks like a bug specific to the customer copy of renewal emails.

Happy to share any details that might help.

Hope you can help and many thanks.

Great! Many thanks @yordansoares 🙌

I hope you don’t mind me asking – what’s the reason this extension isn’t part of the core plugin?

Hi there @dwpriv

Many thanks for your response, and apologies for the delay on my end.

Here’s a screenshot of my settings:

https://imgur.com/a/UPufsgI

I’ve since enabled “New Renewal Order” after making my original post, and interestingly, it now seems to be working correctly. That said, I wouldn’t have expected this to resolve the issue, as that email is sent to the store manager rather than the customer.

So I’m not entirely sure whether it was simply a temporary glitch, but I’ll keep an eye on the next few renewals and report back if the invoice is missing from the customer emails again.

Thanks again!

Hi,

Many thanks — that is very helpful and confirms what I was seeing in the cache headers.

In our case, SiteGround confirmed that requests with mc_cid / mc_eid were contributing to uncached traffic during a newsletter spike, and that those uncached requests then hit a fairly heavy landing page, which led to long-running PHP processes and exhausted available workers.

So it does seem that the plugin’s cookie-setting behaviour was one of the triggers here.

I will test the mailchimp_allowed_to_use_cookie filter next, as that sounds like the most relevant workaround for our setup.

It might also be worth considering adding a native option in the plugin settings to disable Mailchimp cookies. For sites relying heavily on full-page caching, having a simple toggle for this could make the plugin easier to use without requiring custom code.

In our case we are using SiteGround, where there isn’t currently an obvious way to configure ignored query strings such as mc_cid / mc_eid directly in the caching interface, so having an inbuilt option to disable the cookie behaviour could be particularly helpful for setups like this.

Thanks again for the clarification.

Hi again,

Just a quick update after further investigation together with our hosting provider.

The issue occurred after a newsletter campaign linking to the page mentioned above (https://example.com/sale-page/). During the traffic spike the server logs showed a number of long-running PHP processes related to requests for that page, some running for several minutes before being terminated by the server’s CPU limit.

Most requests were still served from cache, and only a relatively small portion were uncached, but this appears to have been enough to exhaust available PHP workers during the spike in traffic.

I’m still interested in understanding whether the plugin intentionally sets cookies or otherwise modifies requests when mc_cid / mc_eid parameters are present, as this may influence cache behaviour.

Any clarification would be much appreciated.

Thanks again.

Thanks so much for testing and confirming the behavior @optimocha — I’ve tested on my end too and can confirm that WooCommerce allows the ?add-to-cart= query string regardless of whether cart fragments are disabled. So the root cause in my case was bot/crawler abuse of public WooCommerce endpoints rather than an issue introduced by DCF. Thanks for pointing me to that distinction.

Where DCF does play a role in my setup is the fallback behavior on product/archive pages. When fragments are disabled, more add-to-cart buttons behave as simple GET requests, which crawlers are more likely to follow. That increases the exposure of these heavier endpoints, which in my case seems to have led to a short burst of load from many different IPs.

Based on this, I’d love to suggest a possible enhancement for users who disable fragments:

Feature request ideas

1. An option to keep AJAX/nonce-protected add-to-cart buttons on archive pages, even with fragments disabled.
2. Optional guidance or preset rules for robots.txt to discourage bot crawling of known heavy endpoints. For reference, here are the rules I am currently testing:
   Disallow: /?wc-ajax=get_refreshed_fragments
Disallow: /*?add-to-cart=
Disallow: /*?*add-to-cart=
3. (Advanced) A setting that ignores or rate-limits repeated add-to-cart GET requests without a valid WooCommerce session.

I completely understand if these are outside the intended scope of the plugin, but I think they could be helpful optimizations for WooCommerce stores using DCF — especially given how common bot traffic is nowadays.

Thanks again for your quick responses and for maintaining such a useful performance plugin. Happy to provide logs privately if anything I experienced could be useful for improving detection or documentation.

Thanks for your help @lovingbro!

Apparently, my WooCommerce account had somehow been disassociated with my WordPress account, and the system wouldn’t allow me to reconnect because there was already an account (my account) using my email address, even though it wasn’t associated with my WooCommerce account 🙃

Luckily, one of your colleagues was able to help from the other side of the gates!

Anyway, thanks again for your help!

• This reply was modified 11 months ago by skafte.
• This reply was modified 11 months ago by skafte.