Clover Modifier Groups → WooCommerce Variations

Clover modifier groups are the heart of any food-service catalog — size on a drink, milk choice on a coffee, add-ons on a sandwich, preparation notes on an entrée. Getting them to sync cleanly into WooCommerce is the single most common technical question we hear from new merchants. This guide walks the mapping rules CloverWoo uses, the edge cases that cause drift, and how to debug when a modifier shows up wrong on the website.

The basic mapping model

Clover and WooCommerce describe customizable products differently:

• Clover has products with attached modifier groups. A modifier group has a name ("Size"), a min/max selection count, and modifiers ("Small +$0", "Medium +$0.50", "Large +$1").
• WooCommerce has variable products. A variable product has attributes ("Size", "Milk") with terms ("Small/Medium/Large") and variations that combine specific term values into purchasable SKUs with their own prices.

CloverWoo bridges this by treating each Clover modifier group as a WooCommerce product attribute and each modifier inside the group as a term of that attribute. The variation table is generated automatically by computing every combination of selectable modifiers.

The simple case (one modifier group)

A Clover product 'Latte' with one modifier group 'Size' (Small +$0, Medium +$0.50, Large +$1) syncs to WooCommerce as:

• A variable product 'Latte'
• One attribute 'Size' with terms Small, Medium, Large (used for variations)
• Three variations: Latte–Small at $4.50, Latte–Medium at $5.00, Latte–Large at $5.50 (base $4.50 + modifier price deltas)

The customer picks a size on the WooCommerce product page, the variation price updates, they add to cart. When CloverWoo pushes the order back to Clover, the original modifier selection ('Size: Medium') is preserved on the Clover order ticket.

Multiple modifier groups

A Clover product 'Latte' with two modifier groups — 'Size' (Small/Medium/Large) and 'Milk' (Whole/Oat/Almond/Soy) — generates a Cartesian product of variations:

• Small × Whole, Small × Oat, Small × Almond, Small × Soy
• Medium × Whole, Medium × Oat, …
• 12 total variations from 3 size × 4 milk options

CloverWoo generates all 12 automatically with appropriately combined prices. If 'Oat milk' carries a $0.75 modifier price, every Oat-containing variation includes that delta on top of the size delta.

Required vs optional modifier groups

Clover marks modifier groups as required (customer must pick one) or optional (customer can skip). The mapping behaves differently:

• Required modifier group: becomes a WooCommerce variation attribute. The customer must pick a value before adding to cart. Each value generates its own variation.
• Optional modifier group: becomes a WooCommerce product attribute that's exposed as a multi-select on the product page (or as variation attributes if min/max = 1). Customer can skip or add multiple values. CloverWoo handles the price computation at checkout based on what was selected.

The distinction matters most for things like 'Add-ons' on a sandwich — customer might add 0, 1, 2, or 3 toppings. That doesn't fit cleanly into the variation table model, so it's rendered as a checkbox group with per-checkbox price modifiers.

Nested modifier groups (the tricky case)

Some Clover setups nest modifier groups — picking 'Add Espresso Shot' opens a secondary group 'How many shots?'. WooCommerce doesn't have a native concept of nested attributes.

CloverWoo handles this by flattening: 'Espresso Shots' becomes its own product attribute with options 0/1/2/3, and the variation table includes shot count as a dimension. The customer doesn't see the nested-flow UX from Clover — they see a flat dropdown — but the end state is the same on the Clover order.

If you want the nested flow preserved exactly (e.g., 'show espresso shot count only if customer ticks Add Shot'), that requires custom WooCommerce conditional logic — typically via a plugin like WooCommerce Conditional Product Fields. CloverWoo doesn't do this conditional UI itself, but it doesn't prevent it either.

How price deltas work

Clover stores modifier prices as deltas (e.g., Large is +$1 on top of base). CloverWoo translates these to absolute prices on each WooCommerce variation. So a $4.50 Latte with Large size (+$1) and Oat milk (+$0.75) becomes a variation with absolute price $6.25.

If you edit a price in Clover (e.g., bump the Large modifier from +$1 to +$1.25), CloverWoo's webhook receives the update and re-syncs every variation that contains 'Large'. Each affected variation's WooCommerce price recalculates. This happens automatically — you don't need to re-run the bulk import.

Debugging mismatches

Modifier missing on the WooCommerce product page

First check: is the modifier group attached to that specific product in Clover, or just to the category? Modifier groups are attached at the product level in Clover; a category-level association requires you to also tag the product. Open the Clover product detail and confirm the modifier groups listed there match what's on the WooCommerce product attributes tab.

Wrong price on a variation

Usually a modifier price was edited in Clover after import. Force a resync: WooCommerce admin → Edit the product → CloverWoo metabox → 'Resync from Clover'. This pulls the latest modifier prices and rebuilds the variation table.

Variation count explosion

If you imported a product and got 200+ variations, the source product in Clover probably has too many modifier groups marked as variation-generating. Open the WooCommerce product, switch some attributes from 'Used for variations' to 'Visible on the product page' instead — that lets the attribute display without generating a variation per value.

Next steps

• If sync gets stuck mid-import: sync stuck playbook.
• If a product's modifier prices don't match Clover: inventory mismatch playbook.
• For restaurant-specific modifier patterns: Clover + WooCommerce for restaurants.