woocommerce Case study
A2 Brand Hubs
Shoppers comparing watch brands needed one place per brand family that shows what we stock and in which price band. I built hub pages for the Swiss and Japanese watch category trees, refreshing price ranges and counts daily while caching the heavy HTML for a month.
The business problem
Computing a price range across a brand's products is expensive in WooCommerce, and doing it live for dozens of brands on a single page would have crushed our shared host. At the same time, stale numbers on a price-led page are worse than no numbers, so the caching had to treat layout and data differently.
What I delivered
- One MU file, a2-brand-hubs-mu.php, with shortcodes that render hub grids for the child categories of swiss-watches and japanese-watches.
- A daily snapshot job through WP-Cron that rebuilds currency-aware price ranges and product counts, guarded by a lock option so two runs cannot overlap.
- A two-tier cache: rendered hub HTML held for 30 days, price and count data refreshed every 24 hours, with term create, edit and delete events busting the structural layer.
- Brand search, letter filtering and price filtering on the hub page, plus a resolver that links each brand to its history article when one exists.
- Admin controls as query strings: ?a2bh_daily_refresh=1 for the snapshot, ?a2bh_rebuild=1 for a full rebuild, and a JSON endpoint exposing the daily metrics.
Technical approach
- Data and presentation expire on different clocks; that single decision is what keeps the page cheap while the numbers stay trustworthy.
- MU plugins have no activation hook, so the cron schedule (a2_bhc_refresh_daily_v23) is verified on init and re-created whenever it goes missing.
- The snapshot lives in one option, a2_bhc_daily_v23, instead of per-term transients, which keeps a hub render at a single extra read.
- Cache invalidation listens to created_term, edited_term and delete_term so category restructuring never leaves ghost brands on the page.
Result and evidence
The hubs serve traffic on the store today. I did not set up a controlled measurement for them, so I will not attribute traffic numbers; what production shows is price data landing on schedule every day and hub pages answering from cache.
Commercial value
Brand-level landing pages give search engines an indexable answer to brand-plus-price queries, and they give our sales team a link to send anyone who asks what we carry from a given maker.
Readable implementation brief
implementation_brief {
project: "A2 Brand Hubs"
file: "mu-plugins/a2-brand-hubs-mu.php (v2.3.5)"
scope: "child categories of swiss-watches / japanese-watches"
cache: { html: "30 days", prices_and_counts: "24h snapshot" }
storage: "a2_bhc_daily_v23 option, a2_bhc_daily_lock_v23 lock"
cron: "a2_bhc_refresh_daily_v23 on a custom daily schedule"
admin: "?a2bh_daily_refresh=1, ?a2bh_rebuild=1, ?a2bh_daily_json=1"
status: "in production; traffic impact not separately measured"
}What this project shows
The part I would point a reviewer at is the operator story: refresh, rebuild and debug paths that a non-developer can trigger from a URL. Cache systems tend to fail the day only their author can reset them.
It also shows I think about the lifecycle of derived data, who rebuilds it, when it goes stale, and how it dies, before I think about how the page looks.