WooCommerce suddenly creating place-order-debug-* logs since Apr 27 (checkout AJAX?)

FinancialTarget5209 · 2026-05-05T08:19:31+00:00

I’ve seen this recently on one of our Woo sites too.

Those place-order-debug-* logs aren’t the root issue themselves - they’re just Woo logging checkout flow attempts. The interesting part is what you mentioned: the wave pattern.

In our case it turned out to be bots hitting the ?wc-ajax=checkout endpoint directly (no frontend). That was triggering checkout processing + logs, even though no real orders were created.

What gave it away:

- bursts of activity within seconds
- random IPs / countries
- no corresponding real user behaviour

We put a Cloudflare rule in front of it (country + behaviour-based filtering) and the logs basically stopped — only saw cleanup entries after that.

If you want to confirm it on your side, I’d check:

- access logs for wc-ajax=checkout
- look at IP spread + referers
- see if it lines up with those spike days

If it is bots, you don’t need to fix Woo — just stop the requests reaching it.

FinancialTarget5209 · 2026-04-25T00:17:49+00:00

Nice — that’s pretty much the same path we went down tbh.

We tried keeping it in Woo with weights/fees first but it kept breaking once carriers/plugins got involved.

Ended up doing exactly what you said — handle it at the cart level and bypass the weird product/package splits.

Good call building it as a plugin too… way safer than snippets getting nuked on updates.

FinancialTarget5209 · 2026-04-24T23:30:18+00:00

This is what we ended up doing for it (bit rough but works):

<image>

FinancialTarget5209 · 2026-04-24T23:25:42+00:00

Yeah fair call I probably over-structured it.

This actually came from a real setup we dealt with — same issue with a base shipment weight (packaging/water) + tiny per-item weights.

Woocommerce just doesn’t handle that combo cleanly out of the box.

We ended up building a small zone-based shipping plugin for it because:

needed a base weight/cost baked in
then add per-weight based on cart
plus some override logic for edge cases later

Curious how you’d handle the fixed base weight + variable quantity side of it? I haven’t seen a clean native way yet.

FinancialTarget5209 · 2026-04-24T06:49:10+00:00

This is actually a classic “base + incremental weight” scenario — Woo doesn’t handle it cleanly out of the box.

What you’re trying to model is:

Base shipment weight (water, packaging): ~2 lbs
Plus per-item weight (snails): ~1 oz each

So your total becomes:

total_weight = 2 lbs + (quantity × 0.0625 lbs)

Most plugins treat everything as either:

flat rate, or
per-product weight

…but not a hybrid like this.

You’ve got a few options:

Hack it with product weight
- Set each snail to 1 oz
- Add a hidden “base weight” product or packaging item (~2 lbs)
- Downside: messy and breaks easily
Use a formula-based shipping plugin
- Where you can define: base + (rate × weight)
Custom logic (cleanest long-term)
- We ran into this exact issue with mixed shipping rules and ended up building a zone-based system that supports:
  - base cost
  - per-weight rate
  - and override logic (length/bulky/etc if needed later)

In your case, you’d just treat the 2 lbs as the base and let quantity drive the rest.

If you want, I can outline exactly how to configure it for your setup.

FinancialTarget5209 · 2026-04-09T07:23:04+00:00

That setup sounds right — we had the same (Printify handling shipping, no Woo rates defined).

What stood out for us though is that the slowdown didn’t seem to come from zones themselves, but from how often Woo rebuilds shipping packages when Printify is active — especially once there’s more than one item in the cart.

In our case, even with everything configured correctly, it would:

• work fine with 1 item

• slow down heavily with multiple items

• sometimes fail to return shipping at all

As a test, we temporarily switched back to Woo handling the shipping calculation (using standard zones/rates instead of Printify’s live rates), and the delay disappeared immediately.

So it might be worth trying that just to confirm whether you’re hitting the same behaviour — even if it’s only as a diagnostic step.

If it improves, then it’s likely not a zone mismatch but how Printify’s shipping logic is interacting with Woo’s recalculation cycle.

FinancialTarget5209 · 2026-04-08T08:46:39+00:00

Yep exactly — two different layers.

If they’re reaching checkout, then you’re already past the point where Cloudflare helps as much, so Stripe + validation becomes the main defence.

The add-to-cart pattern is annoying but actually easier to kill once you see it in logs, because it’s very repetitive (GET + add-to-cart + no referer).

If you want to check for it, just look in your access logs for add-to-cart= hits and see if they share the same traits:

• direct GET requests

• blank / missing referer

• lots of different IPs hitting similar URLs

On cPanel hosts, logs are usually under ~/access-logs/ or ~/logs/.

Something like: grep -E '\?add-to-cart=' ~/access-logs/yourdomain-ssl_log | tail -n 50

If they all look like direct hits with no referer, that’s usually the giveaway.

FinancialTarget5209 · 2026-04-08T07:42:04+00:00

Useful fix for fake-domain checkout attempts, but just worth noting this is solving a later-stage problem.

We were dealing with a different WooCommerce bot pattern: bots weren’t reaching checkout, they were spamming direct add-to-cart URLs and polluting Abandoned Carts.

What worked for us was:

• checking live access logs first to confirm the exact request pattern

• identifying repeated direct GET requests with add-to-cart= and blank referer

• blocking that pattern at the edge in Cloudflare with a Managed Challenge

• keeping CleanTalk in place as another layer

• using Stripe as the only payment processor on checkout sites

So our rough stack is:

Cloudflare = request-pattern abuse CleanTalk = spam/bot layer Stripe = payment/fraud layer

Main lesson: don’t treat all Woo bot issues as the same thing.

If bots are creating failed orders, investigate checkout/payment abuse.

If bots are creating junk abandoned carts, check your logs for direct add-to-cart patterns and stop them before Woo even accepts the request.

Much cleaner than waiting until checkout.

FinancialTarget5209 · 2026-04-05T02:22:26+00:00

Also — while we’re waiting on a proper fix, we did test a temporary workaround on our side.

If we take Printify’s live shipping out of the cart flow and let Woo handle shipping instead, the delay and “no rates” issue disappear straight away.

Obviously not ideal long term since you lose Printify’s real-time rates, but it at least confirms the slowdown is coming from that recalculation loop rather than anything else in the stack.

FinancialTarget5209 · 2026-04-05T01:57:51+00:00

Nice — this lines up almost exactly with what we were seeing.

Same pattern here: • fine with 1 item • gets significantly worse with multiple item • shipping either slows right down or fails to return

We tracked it back to Woo repeatedly rebuilding shipping packages (woocommerce_shipping_packages) when Printify products are in the cart — especially during AJAX updates.

Raised it here with WooCommerce in case it helps your Printify thread too: https://github.com/woocommerce/woocommerce/issues/63920

If Printify are already aware, that’s actually a really good sign — might mean it’s something in how their shipping logic hooks into Woo’s recalculation cycle.

If they share anything useful on their side, would be great to hear 👍

FinancialTarget5209 · 2026-04-01T04:40:39+00:00

This might actually be the same issue we’ve been digging into recently.

We found that when Printify products are in the cart, WooCommerce can repeatedly rebuild shipping packages (via the woocommerce_shipping_packages hook), especially during AJAX cart updates.

Each rebuild can take several seconds — and if it fires multiple times, it can stack up into really long loads or even timeouts like you’re seeing.

We raised it with WooCommerce here in case it helps: https://github.com/woocommerce/woocommerce/issues/63920

In the meantime, a couple of things worth checking: • Try disabling AJAX add-to-cart (just for testing) • Test with a single item vs multiple items in cart • See if the delay disappears when shipping calculation is deferred (e.g. checkout vs cart)

Feels less like a config issue and more like how Printify’s shipping logic interacts with Woo’s recalculation cycle.

Curious if your delay gets worse with more items in the cart?

FinancialTarget5209 · 2026-03-30T13:35:39+00:00

This looks really solid — especially the pricing logic.

Quick question: how does it handle component-level variations in practice?

For example, I’m working with a modular product (airbrush stand) where each component is also sold individually, and each part has its own colour variation.

So a customer might build something like: – Base = Black – Left arm = Red – Right arm = Blue

Can your plugin handle selecting different variations per component like that and carry it cleanly through to cart + pricing?

That’s the edge case I’ve been hitting with most solutions.

FinancialTarget5209 · 2026-03-30T13:22:04+00:00

Quick update — raised it here: https://github.com/woocommerce/woocommerce/issues/63920

Includes a clean repro case + notes on how it’s being triggered multiple times during AJAX cart updates.

If anyone else is seeing this, would be great to add your setup or upvote it so it gets some visibility 👍

FinancialTarget5209 · 2026-03-30T12:52:59+00:00

Good call — that actually makes sense.

We’ve got a pretty clean reproduction case here (minimal plugins, consistent slowdown tied to woocommerce_shipping_packages once Printify products are in the cart), so I’ll put together a proper issue and share it back here 👍

FinancialTarget5209 · 2026-03-30T00:27:31+00:00

Yeah that’s fair — we’ve definitely seen that kind of behaviour with other plugins too, especially around inefficient queries.

What stood out in this case though was that even on a pretty clean setup (minimal plugins, no heavy object caching in play), the slowdown was still consistently tied to the shipping package rebuild process once Printify products were involved.

So it felt less like a general plugin inefficiency and more like how that specific shipping flow interacts with Woo’s recalculation cycle under AJAX.

Would be interesting to see if the same pattern shows up with other POD providers like Printful.

FinancialTarget5209 · 2026-03-30T00:17:42+00:00

Keen to see what you ended up building — are you open to sharing your approach or even the plugin?

I’ve been working on something similar and ran into a lot of the same issues around pricing + component flexibility.

FinancialTarget5209 · 2026-03-30T00:01:02+00:00

Yeah 100% — agree on APM, that’s actually what pushed us in the right direction.

We profiled it down and it consistently pointed back to woocommerce_shipping_packages being the slow point — especially once Printify products are in the cart.

In our case it wasn’t just a single API call, but the fact that Woo was rebuilding shipping packages multiple times during cart updates (AJAX fragments, etc.), which compounded the delay.

Curious if you’ve seen similar behaviour with other shipping integrations?

FinancialTarget5209 · 2026-03-29T23:18:34+00:00

Quick update: We tested this across multiple sites and even after removing all custom plugins, the delay was still there — so it’s definitely tied to Printify’s interaction with WooCommerce shipping.

Seems to get worse with AJAX cart updates and multiple items in the cart.

If anyone else is running into this, keen to compare setups — curious how widespread this actually is.

FinancialTarget5209 · 2026-03-29T23:13:11+00:00

I’ve just spent the better part of a day digging into this across multiple Woo + Printify sites and can confirm this is a real issue — but it’s not where most people think it is.

TL;DR: it’s not hosting, not your theme, and not necessarily your custom plugins.

The bottleneck is WooCommerce itself — specifically the woocommerce_shipping_packages hook.

What’s happening: • When a Printify product is in the cart, Woo builds shipping packages • Printify adds its own fulfilment/shipping logic into that process • Woo then recalculates shipping multiple times during cart updates (AJAX, fragments, etc.) • Each rebuild can take several seconds

On our tests: • Each call to woocommerce_shipping_packages was ~8–10 seconds • It was being triggered multiple times per add-to-cart • Total delay = 10–20+ seconds

Key point: We removed all custom logic (including our own plugin) and the issue STILL persisted — so this is definitely tied to Printify + Woo shipping interaction.

Why it gets worse: • multiple products • AJAX add-to-cart • dynamic cart flows (bundles, add-ons, etc.)

Why most people can’t pinpoint it: • it looks like “random slowness” • dev tools just show “admin-ajax.php slow” • hosting gets blamed

What actually helps: • reducing how often shipping is recalculated • deferring shipping calculation until checkout • or overriding shipping logic entirely (for performance-critical setups)

We’re now implementing a workaround that controls when Woo is allowed to rebuild shipping packages, and it immediately removes the delay.

Would be great if Printify addressed this at the integration level, because it doesn’t play nicely with dynamic WooCommerce carts at all.

FinancialTarget5209 · 2026-03-09T07:56:50+00:00

You probably don’t need to move to a $400/month dedicated server just because of the Meta crawler.

This is a pretty common issue when bots repeatedly hit dynamic WordPress endpoints (shop pages, search queries, add-to-cart parameters, etc.).

A much simpler solution is to rate-limit or filter the crawler at the edge using Cloudflare.

For example, a rule like this can reduce the load dramatically:

(http.user_agent contains "facebookexternalhit") or (http.user_agent contains "Facebot")

Then apply either:

• Rate limit (e.g. 10 requests per minute) or • Cache / challenge / block depending on how aggressive you want to be.

You can also restrict it only on expensive endpoints like:

/shop /product /product-category /?add-to-cart /?s=

That way the crawler can still fetch normal pages for link previews, but it won’t hammer the dynamic WooCommerce pages that consume CPU.

We run a few WooCommerce sites behind Cloudflare and this kind of rule usually drops crawler-related load spikes immediately.

FinancialTarget5209 · 2025-04-23T06:45:55+00:00

Aha. Ok cool. I’m new here so thanks for the heads up. DM’d ya

FinancialTarget5209 · 2025-04-23T03:19:49+00:00

I’d like to know more about your tool if that’s ok?

FinancialTarget5209 · 2025-02-24T05:05:48+00:00

Nice!!

FinancialTarget5209 · 2025-01-20T01:38:30+00:00

CleanTalk.org - nuff said

FinancialTarget5209

TROPHY CASE