u/Upstairs_Control_611

I spent the weekend trying to understand why one of my WooCommerce stores suddenly behaved strangely.

Symptoms:

Database grew to 1.3 GB
PHP error log exploded to 7.9 GB
Random database lock errors
Deadlocks in Action Scheduler
INSERT command denied messages
Background processing running almost continuously

At first I suspected:

Redis
WP Rocket
a custom JSON-LD plugin I was developing
a recent server upgrade

None of them were the cause.

After digging through the database I found this:

wc_run_batch_process
status: complete

1,072,113 actions

The args field pointed to:

Automattic\WooCommerce\Internal\DataStores\Orders\DataSynchronizer

The interesting part:

The store has only 600+ orders.
Only 1 pending Action Scheduler job existed at any given time.
As soon as one batch completed, the next one was immediately scheduled.

So this wasn't a growing queue.

It looked like an endless loop:

pending
↓

complete
↓

schedule next batch
↓

pending
↓

...

The issue only became obvious after comparing the Action Scheduler tables with the HPOS configuration.

I'm still investigating the exact trigger, but if your WooCommerce database suddenly starts growing at an unusual rate, check your Action Scheduler before assuming it's a database or server issue.

Sometimes the problem isn't the database.

It's the background worker that never stops scheduling itself.

Has anyone experienced a similar HPOS / DataSynchronizer loop?

I noticed an interesting behavior while deleting products in a larger WooCommerce catalog.

I deleted products in several bulk actions (20 products per batch). The products did not seem to be permanently deleted immediately.

Instead:

• deletion tasks appeared under Scheduled Actions
• first under "Pending"
• after more bulk deletions, some actions became "Overdue"
• Woo then displayed something like: "The next queue will start in xx seconds."

After the next queue started, around 40-50 products seemed to be permanently deleted in one run.

My impression is that WooCommerce intentionally processes product deletions in batches and inserts pauses between queue runs instead of continuously processing everything.

Questions:

• Is this expected behavior of Action Scheduler?
• Have others observed similar behavior on larger catalogs?
• Did you notice increased database activity while processing large deletion batches?

Environment:

• WooCommerce 10.7.0
• WordPress 7.0
• Elementor 4.1.1 / 4.1.0
• Astra theme

Setup:
Germany, Austria and Switzerland were configured in the same shipping zone.

Behaviour:

• Logged out: shipping costs displayed correctly.
• Logged in: no shipping costs displayed on checkout.
• Order confirmation also showed inconsistent behaviour.

What finally fixed it was disabling:

WooCommerce → Settings → Shipping → Shipping options → "Hide shipping costs until an address is entered."

After unchecking that option, Woo immediately detected Germany correctly and the shipping costs appeared again.

Has anyone seen similar behaviour recently, especially with logged-in users and shipping zones that include multiple countries?

Hey everyone,

since April 27, one of my larger WooCommerce shops started generating a lot of log files named like:

place-order-debug-bbbdcbf4

Inside the logs I see entries such as:

[Shortcode #1] Place Order flow initiated  
[Shortcode #2] Session updated with checkout data and totals calculated  

The context includes an order_uid, but it looks like a UUID, not a normal WooCommerce order ID.

Backtrace points to:

WC_Checkout->process_checkout  
WC_AJAX::checkout  

What’s interesting is the pattern:

• Apr 27: first appearance
• Apr 28–29: almost no logs
• Apr 30: massive spike again

So it doesn’t look like a constant bug — more like something triggering checkout requests in waves.

My questions:

1. Has anyone seen place-order-debug-* logs recently? Is this new in WooCommerce?
2. Could this be bots repeatedly hitting the wc-ajax=checkout endpoint?
3. Any known plugins or themes that might trigger repeated checkout AJAX calls?
4. Where would you start debugging this — frontend JS or server/access logs?

Thanks

Hi all,

I’m dealing with a persistent and rather unusual WordPress compromise affecting multiple domains within the same hosting account, and I’m trying to identify the actual entry vector.

Key observations:

• Administrator accounts are being created directly in the database, not via WordPress
  • no username/email set
  • identical password hashes across multiple accounts
  • fake registration dates (e.g. 2020)
  • no recorded login activity
• Wordfence reports no modified core, plugin, or theme files
• NinjaFirewall logs repeatedly show: Database changes detected - [administrator account] with IP 0.0.0.0 → no HTTP request context
• Access logs show no matching requests at the corresponding timestamps
• Databases are configured for localhost access only (127.0.0.1)

Attack pattern:

1. Admin accounts appear (direct DB insertion)
2. Shortly after, on at least one affected domain:
   • a file manager plugin gets installed (legitimate plugin, not modified)
3. Some domains show:
   • suspicious sitemap.xml with large sets of pre-generated URLs (SEO spam preparation)
   • Google Search Console activity for domains not actively managed

Important context:

• Not all domains are affected, but multiple sites in the same account show related behavior
• No obvious malware found in WordPress files
• No clear HTTP-based attack trace
• Behavior strongly suggests server-side execution or lateral movement

Working assumptions:

• Direct DB manipulation via:
  • local script execution (PHP CLI?)
  • compromised hosting environment
  • or abuse of a vulnerable application layer component

Questions:

1. Has anyone encountered this pattern (direct DB user injection + 0.0.0.0 firewall logs)?
2. What are realistic vectors for creating WP admin users without HTTP traces?
3. Any known techniques for lateral movement between WP installations within the same account?
4. Where would you focus next: server-level audit, DB credential reuse, or application layer?

At this point it does not look like a typical WP file-based compromise, but rather something executing within the server context.

Any insight or similar cases would be greatly appreciated.

Thanks!

Hot take:

GEO may have a prompt research problem more than a content optimization problem.

SEO had keyword research.

But where is the equivalent for real AI prompts?

Most GEO tools seem to monitor curated prompt sets — but what if many of those prompts don’t reflect how people actually use AI search?

Example:

A tool might track something like:

“loft studio Düsseldorf”

But a real AI user might ask:

“Where can I find a loft photo studio near Düsseldorf for business portraits?”

That changes:

* what prompts matter

* what content gets cited

* how “AI visibility” should even be measured

I’m starting to think prompt research may become for GEO what keyword research was for SEO.

Some GEO tools may be optimizing for synthetic prompts, while users ask something else entirely.

Curious what others think:

Are we still doing SEO-style keyword thinking in AI clothing?

Or are people seeing good approaches to real prompt research already?

Without prompt research, GEO may optimize answers to questions nobody asks.