Skip to content
WooCommerce The per-site Store views for a WooCommerce shop — orders, products, customers, coupons and reports.

WooCommerce

When a WordPress site runs WooCommerce, MZPanel adds a Store group to the site rail with five views — Orders, Products, Customers, Coupons and Reports (/sites/:srv/:dom/store/…). They read your live store data straight off the box and let you do the quick, common tasks — change an order status, refund, tweak a price or stock count, create a coupon — without logging into wp-admin. It’s a WordPress-site feature, available on all plans.

  • Orders — a searchable, status-filtered list of orders (number, customer, date, item count, payment method, status pill and total). Open one to see line items and billing/shipping addresses, then change status, add a note (optionally emailed to the customer) or issue a refund — each running WooCommerce’s real side-effects, not raw SQL.
  • Products — the catalog with search and a stock-status filter. Quick-edit a product’s regular/sale price and stock quantity/status inline.
  • Customers — store customers with their order count and lifetime spend.
  • Coupons — list, create, edit and delete discount coupons (type, amount, expiry, usage limit, free shipping, minimum spend).
  • Reports — sales and revenue over a window (default 30 days) plus top sellers, derived from order rows.

The Store views split cleanly into fast reads and safe writes:

  • Reads go through a set of site-scoped API endpoints (GET /v1/servers/:id/wc/{status,orders,products,customers,coupons,report}) that relay wp.wc_* jobs to the site’s agent. The agent answers them natively by querying the site’s database directly — no WooCommerce REST key, no child plugin — so lists load fast. It auto-detects HPOS (High-Performance Order Storage, the wc_orders tables, default since WooCommerce 8.2) versus legacy post-based storage and branches its queries accordingly; the Orders footer tells you which one your store uses.
  • Detection — a wp.wc_status job reports whether WooCommerce is active (and whether HPOS is on). The Store group only appears for sites where it’s active.
  • Writes (status change, order note, refund, product edit, coupon create/edit/ delete) do not touch the database directly. They call the WooCommerce wc/v3 REST API through MZPanel’s elevate-to-admin content proxy (the same bridge the WP content editor uses): the agent’s mu-plugin runs the REST request in-process as an administrator, so WooCommerce’s stock adjustments, emails and status-transition hooks all fire correctly.

No store state is mirrored in MZPanel’s control plane — the box’s WordPress database is the source of truth, read and written live each time.

There is no dedicated mz wc command. Store reads are internal agent job kinds (wp.wc_orders, wp.wc_products, …) driven by the dashboard, and writes go through the same WordPress content bridge as the post editor rather than a shell command — so there’s no on-box mz verb to script against for store data yet.

For WordPress automation on the box in general, see The mz CLI and the command catalog. If a scriptable store surface is something you need, tell us on the roadmap.

  • Shelved behind a flag — you won’t see it. The Store rail is gated off in the current build, so orders/products/etc. are unreachable from the UI regardless of whether the site runs WooCommerce. This is deliberate (see the note above), not a bug. Manage your store in wp-admin for now — the site rail’s magic-login button gets you there in one click, no password.
  • WooCommerce sites only. The group is meant to appear only when the site’s agent reports WooCommerce active; a plain WordPress site never shows it.
  • HPOS vs legacy is auto-detected. Stores on High-Performance Order Storage and older post-based stores both work; the Orders view labels which storage it read. If order counts look wrong right after an HPOS migration, re-sync WooCommerce’s order tables in wp-admin.
  • Refunds are irreversible, and gateway money-back depends on the payment method. A refund creates a real WooCommerce refund; whether the customer’s card is actually credited depends on the gateway supporting API refunds.
  • Needs the agent online. Every read and write goes through the site’s agent live; when the server is offline the site shell shows an “agent offline” banner and store data is unavailable.