Treat the main product and chosen components as one configuration group, even when they technically consist of several WooCommerce cart lines. Retain a stable group relationship, scale dependent quantities together and prevent required children being left behind when the main product is removed.
This parent-child relationship becomes necessary when options are actual products. Without an explicit link, the cart sees only separate rows. Customers can then accidentally remove a mounting kit, session restoration can split the group and order export cannot identify which components form one delivered product.
Define which lines are dependent
Not every added product needs a strict connection to the main product. A required frame must be removed with it and scale in quantity. An optional maintenance kit may belong to the configuration but perhaps remain independently. Define for each option type whether removal, quantity changes and return relationships are linked.
| Relationship | When removing the main product | When changing quantity |
|---|---|---|
| Required component | Remove automatically with it | Scale proportionally |
| Optional configuration component | Usually remove with it; explain clearly first | According to the configured ratio |
| One-off service | Reassess the line | Do not automatically double |
| Separate recommended product | May remain independently | Its own quantity |
Use an internal group key created when building the cart and retained on every child line. Do not rely on cart position or product name. Two identical main products with different configurations must each retain their own children.
Do not use the group key to decide pricing or access. It only connects lines within the cart. Prices, availability and allowed add-ons still come from the current catalogue and server rules. Also validate that a child actually points to the intended parent; group data supplied by the browser is not automatically trustworthy.
Restore the relationship through sessions and orders
WooCommerce serialises the cart and rebuilds it later. After session restoration, check that every group key remains valid and a parent exists. An orphaned required component must not silently remain purchasable as a standalone product. Show a recovery message or remove the invalid group under a predefined rule.
Carry the same relationship into order lines. Customers see a readable configuration summary; the warehouse and integration also receive separate SKUs and quantities. An ERP integration must not have to guess which items belong together from order-line sequence. Reliably connecting your online store and ERP starts with an explicit data model like this.
Decide what price each cart line displays. Some shops show the full amount on the parent and zero prices for components; others price every component separately. Both can work if cart, checkout, order email and administration produce the same total. Do not hide priced components so thoroughly that customers cannot check the breakdown.
Fictional example: two verandas in one cart
Garden specialist Buitenlijn sells verandas with posts, gutters and optional lighting. A customer first configures a small veranda with two posts, then a larger one with three. Both main products use the same base model but receive unique groups.
When the customer doubles the quantity of the small veranda, its two associated posts and gutters scale with it. The one-off measuring service does not double; the online store asks whether one visit can cover both verandas. Removing the large veranda removes only the children from that group. The small veranda's lighting remains intact.
At ordering, Buitenlijn retains both individual items and the group summary. Fulfilment can then pick components, and customer service can later explain which set belonged to which veranda. To carry this structure through, Yindle Connect can make translation to back-end systems manageable.
If one component sells out during checkout, Buitenlijn blocks the entire affected group and identifies the precise problem. The other veranda in the same cart remains recognisable. Customers can edit or remove the affected configuration without rebuilding the whole cart.
Test matrix for group behaviour
- Add two configurations of the same main product.
- Change the quantity of only one group.
- Remove the parent, required child and optional child separately.
- Reload the session and restore a saved cart.
- Make a child product temporarily unavailable.
- Apply a coupon to the parent, children and group.
- Check cart, checkout, order email, warehouse and ERP export.
- Test cancellation and partial returns without losing relationships.
Make group behaviour visible in the interface. Automatic scaling is useful, but an unexpectedly changed quantity feels like an error. Briefly explain why a component changes too and provide a deliberate choice for exceptions. If standard extensions cannot support this model, explore the choice between custom and standard software.
Have Yindle design the parent-child structure of your composite products.