DEV Community: Chetan Upare

Modelling Product Relationships in WooCommerce (Accessories, Bundles, and More)

Chetan Upare — Fri, 06 Feb 2026 17:30:24 +0000

WooCommerce does a lot out of the box.

But when it comes to real product relationships, things get messy very quickly.

Questions like:

How do I link accessories to a product?
How do I model bundles or kits?
How do I create truly related products (not just upsells)?
How do I query these relationships cleanly?

Most WooCommerce stores eventually hit this wall.

How WooCommerce handles relationships today

WooCommerce provides:

Upsells
Cross-sells
Grouped products

These work — but they’re opinionated and limited.

They don’t:

Model meaning (accessory vs replacement)
Support custom relationship types
Scale well for complex catalogs
Work cleanly outside WooCommerce templates

As soon as your catalog grows, these limitations show.

Common workarounds (and their problems)

1. Product meta fields

Many stores add custom fields to products:

accessory_ids
related_items
bundle_products

This quickly leads to:

Meta-heavy queries
Poor performance
Complex reverse lookups
Fragile template logic

2. Taxonomies

Some teams use categories or tags for relationships.

But taxonomies are about classification, not relationships.

A camera doesn’t belong to the “Lens” category —

it has compatible lenses.

The meaning is lost.

3. Custom database tables

Technically correct — but expensive.

You now maintain:

Schema
Queries
Validation
Sync logic with WooCommerce

For most stores, this is overkill.

The missing piece: a relationship layer

What WooCommerce really needs is a generic relationship layer that can model:

Product → Accessory
Product → Replacement
Product → Bundle
Product ↔ Related product

With:

Direction
Meaning
Clean querying
Performance at scale

This is exactly what Native Content Relationships provides.

👉 https://wordpress.org/plugins/native-content-relationships/

How this improves WooCommerce setups

Instead of forcing relationships into meta or taxonomies:

Accessories become a one-way relationship

(Camera → Lens → Tripod)
Related products become bidirectional

(Alternative or similar products)
Bundles are modeled explicitly

(Bundle → Contains → Products)

All without abusing WooCommerce internals.

Why this scales better

With a structured relationship layer:

Relationships live in an indexed table
Queries are predictable and fast
Reverse lookups are trivial
Editors manage relationships safely
Data remains portable and future-proof

You’re no longer fighting WooCommerce — you’re extending it cleanly.

When this matters most

Large product catalogs
Stores with accessories or replacements
Multilingual WooCommerce sites
Headless storefronts
Long-lived eCommerce platforms

If your store is growing, relationship modeling becomes infrastructure — not a feature.

Final thought

WooCommerce solves commerce.

It doesn’t solve data modeling.

Once you separate those concerns, complex product relationships become much easier to reason about.

If you need a clean, WordPress-native way to model product relationships, you can explore the plugin here:
https://wordpress.org/plugins/native-content-relationships/

Modeling Events & Speakers in WordPress (The Clean, Scalable Way)

Chetan Upare — Fri, 06 Feb 2026 17:27:39 +0000

WordPress is great at managing content — until you need real relationships.

If you’ve ever built an Events website, you’ve probably heard questions like:

Can one Event have multiple Speakers?
Can one Speaker appear in many Events?
Can editors manage this safely without breaking the site?

On the surface, this sounds simple. In reality, it’s one of the most repeated architectural problems in WordPress projects.

The usual approaches (and why they fall apart)

1. Taxonomies

Using categories or custom taxonomies for Speakers feels convenient.

But taxonomies are built for classification, not relationships.

An Event has Speakers.

A Speaker does not categorize an Event.

There’s no direction, no meaning, and no clean way to model the relationship itself.

2. ACF relationship fields

This is where many projects land.

ACF relationships work well initially:

Easy to configure
Editor-friendly
Quick to ship

But as content grows, problems appear:

Slower queries
Complex reverse lookups
Meta-heavy database usage
Tight coupling to a single plugin

What started as a shortcut becomes technical debt.

3. Custom tables

Technically correct — but often too heavy.

You now need to manage:

Schema
Queries
Validation
Migrations

For most projects, this adds complexity without solving the root issue cleanly.

The real problem

WordPress has no native relationship layer.

So relationships are usually faked using tools never designed for them.

A better approach: treat relationships as first-class data

Instead of forcing relationships into post meta or taxonomies, the cleaner approach is to model them explicitly:

Structured relationship types
Direction (Event → Speaker)
Reverse querying without hacks
Indexed, predictable performance
Editor-safe management

This is exactly the problem Native Content Relationships was built to solve.

👉 https://wordpress.org/plugins/native-content-relationships/

How this looks in practice

Event → Speaker (one-way relationship)
Speaker → Events (automatic reverse query)
No taxonomy misuse
No meta table scans
Clean, maintainable templates

Editors manage relationships naturally.

Developers get predictable data.

Performance scales as content grows.

Where this really shines

Events & Speakers
Courses & Instructors
Products & Accessories
Documentation & References
Any many-to-many content model

If your project keeps revisiting the same relationship problem every few months, it’s usually a sign that the data model is wrong, not the code.

Final thought

Most WordPress relationship pain isn’t caused by bad plugins.

It comes from using the wrong abstraction.

Once relationships are treated as native data, WordPress becomes much easier to work with.

If you’re interested in a clean, core-friendly solution, you can explore the plugin here:
https://wordpress.org/plugins/native-content-relationships/

Why ACF Relationship Fields Struggle at Scale (And What to Use Instead)

Chetan Upare — Fri, 06 Feb 2026 17:20:41 +0000

Advanced Custom Fields is one of the most widely used plugins in the WordPress ecosystem — and for good reason.

But relationship fields are often pushed far beyond what they were designed for.

That’s where long-term problems begin.

Why developers love ACF relationships

ACF relationship fields are appealing because:

They’re fast to set up
Editors understand them
They work fine for small datasets

For simple projects, they’re completely acceptable.

Where things start to go wrong

As sites grow, the cracks start to show.

1. Performance issues

ACF stores relationship data in post meta.

That means:

Multiple rows per relationship
Meta queries instead of indexed joins
Expensive reverse lookups

As content grows, performance degrades quietly — until it doesn’t.

2. Query complexity

Forward queries are manageable.

Reverse queries often require:

Nested meta queries
Custom SQL
Template-level hacks

This makes themes harder to reason about and maintain.

3. Data lock-in

Relationship data becomes tightly coupled to ACF.

Removing it later usually means:

Writing migration scripts
Cleaning orphaned data
Risky refactors on production data

Temporary convenience turns into permanent debt.

The real issue

ACF relationship fields store relationships as metadata.

Metadata is flexible — but it’s not relational.

When relationships become central to your data model, this approach stops scaling.

A better pattern: structured relationships

For projects that require:

Many-to-many relationships
Directional meaning
Clean reverse queries
Long-term maintainability

A structured relationship layer is a better fit.

This is the exact gap Native Content Relationships was designed to fill.

👉 https://wordpress.org/plugins/native-content-relationships/

What changes with a proper relationship layer

Relationships live in a dedicated, indexed table
Queries become predictable and performant
Reverse lookups are first-class
Editors still get a clean UI
Data stays portable and future-proof

Most importantly:

Your content model stops fighting WordPress.

When you should move away from ACF relationships

Large datasets
High-traffic sites
Multilingual WordPress setups
Headless WordPress projects
Long-lived systems expected to evolve

ACF is still great — just not for everything.

Final takeaway

ACF relationship fields are convenient.

But convenience has limits.

When relationships are core to your application, they deserve first-class treatment.

If you’re looking for a clean, native approach, you can explore the plugin here:
https://wordpress.org/plugins/native-content-relationships/