Who Changed It/Answers
On a blog, an unexplained change is annoying. In a store, it costs money by the hour — a product at the wrong price, a payment gateway switched into test mode, a sale price still running a fortnight after the campaign. A WooCommerce audit log exists so a store keeps receipts for its own changes.
WooCommerce keeps order notes, and that is about it. Price changes, coupon edits and store settings changes leave no history at all. The expensive failures are rarely dramatic — they are quiet states nobody chose on purpose and nobody notices for a while:
Without a log, the recovery conversation is guesswork between everyone who has admin access, plus every plugin and integration that writes to the catalogue.
Who Changed It adds WooCommerce support automatically when WooCommerce is active, on top of everything it already records site-wide. The commerce-specific events are the ones the general content hooks cannot see, each with the old value next to the new one — the full list with severities is in the event reference:
Products, coupons and — on the legacy storage — orders are ordinary WordPress content underneath, so creating, trashing and deleting them is already covered by the general content events, in the same timeline.
#41203 · 02:14 · no user · product_price_changed · "Alpine Jacket" — _regular_price: "189.00" → "18.90" — dangerous
Notice what the actor column says there, because it does a lot of work in a store: so much of a catalogue is written by software — feed syncs, ERP connectors, dynamic-pricing rules, dropshipping tools — and those run without a logged-in user. A price rewritten at 02:14 with no user behind it is not a mystery to solve by asking your staff; it tells you to go and look at an integration. A change one of your people made carries their name, role, IP and session instead.
Worth stating outright, because store owners reasonably assume otherwise. There is no tracking of stock quantities, edits to line items inside an existing order, shipping zones, the tax rate tables, or coupon expiry and usage limits — the tax entries above are the store-level toggles, not the rates themselves. And nothing about your customers' own activity is recorded: this is an audit trail for the people and software that administer the store, not analytics for the people shopping in it.
Stores have staff, and staff make normal changes all day. The point of behaviour scoring is that normal stays quiet: the person who updates prices every morning never lights up the board. What surfaces is deviation — an edit at an hour that account never works, a sign-in from an address it has never used before touching the catalogue, or a payment gateway being reconfigured at all. When the accountant asks about a refund from March, filter the timeline to that order and export the rows as CSV or JSON — export is part of the free plugin, so evidence is never behind a paywall, and each export carries a manifest and the record hashes so the file can be verified later.
Worth being clear about the limit, though: a log records the store, it does not defend it. A shop with a dozen integrations, staff accounts, a payment gateway and a checkout worth attacking wants preventative work underneath the audit trail — which is where an independent WordPress security audit earns its keep (WooCommerce and multisite are covered when they are named in the scope), together with a hardened host under it. Both are what this plugin's author does day to day at WP Server Guard.