Amirali YaghoutiSenior Software Engineer

woocommerce Case study

A2 Woo Details Excel

The people packing orders needed to record eight things WooCommerce has no field for: whether the box, pouch, warranty card and battery went in, where the item was pulled from, the shipping date on the Persian calendar, the tracking code and the external invoice number. They were doing it in a spreadsheet kept alongside the store.

The business problem

Order operations lived outside WooCommerce, so the packing spreadsheet and the store disagreed constantly. The obvious fix is custom fields, but eight postmeta rows per order across a large order table makes the admin list slow, and postmeta gives you no clean way to render a sortable column or export a range. The data needed a real home.

What I delivered

  • a2-woo-details-exel.php, a 2,168-line MU plugin that provisions its own table rather than writing eight postmeta rows per order.
  • Eight operational columns rendered directly in the orders list, with the widths tuned so the checkbox fields read as a scannable grid.
  • A modal editor opened from the order row, with a Jalali date picker for the shipping date because that is the calendar the team works in.
  • A managed stock-location list stored as an option, editable from the modal, so warehouse locations are a dropdown rather than free text that drifts.
  • XLSX export over the current filter, so a date range or status selection in the admin becomes a file the accounting team can use.
  • An order note recording which user saved which change, so the fields carry the same accountability as the rest of the order history.
  • Support for both the legacy post-based orders screen and HPOS, since the two use entirely different column hooks.

Technical approach

  • The custom table is the decision the rest follows from. Columns render with one read per screen instead of eight postmeta lookups per row, and export becomes a query rather than a loop.
  • Schema changes are versioned and checked at most every six hours rather than on every admin load, so the install check does not become its own overhead.
  • Everything writes through nonce-protected AJAX endpoints; there is no form post path that could be replayed.
  • Both column hooks are registered at priority 9999 so the fields land after whatever the theme and other plugins have already done to that table.
  • Export runs behind an overlay with its own progress state, because a large range is slow enough that a silent wait reads as a broken button.

Result and evidence

Order operations moved into WooCommerce. The parallel spreadsheet is gone, which removes the reconciliation step it used to require, and the fields are now visible to everyone who opens the order rather than to whoever had the file open.

Commercial value

This is the kind of internal tooling that does not appear in any feature list but decides whether a team ships orders accurately. It replaced a manual process with one that is auditable by default.

implementation-brief.readme

Readable implementation brief

implementation_brief {
  project: "A2 Woo Details Excel"
  file: "mu-plugins/a2-woo-details-exel.php (2168 lines, v2.0.0)"
  storage: "custom table {prefix}a2_order_ops, not postmeta"
  fields: "external invoice, box, pouch, warranty, battery,
           stock location, Jalali ship date, tracking code"
  ui: "modal editor from the orders row + 8 list columns"
  compat: "legacy shop_order screen and HPOS, both at 9999"
  export: "XLSX over the current admin filter"
  audit: "order note naming the user who saved"
  schema: "versioned, checked at most every 6 hours"
}

What this project shows

Choosing a custom table over postmeta is the whole engineering content of this project. Postmeta would have shipped faster and made the orders list unusable at this volume.

Supporting the legacy screen and HPOS at the same time is unglamorous, but the alternative is a plugin that breaks on a WooCommerce settings change nobody remembers making.