CE Phoenix Cart Forum

This (or something along these lines) has been on the cards for years. Over the weekend I spent around 12 hours iterating through different approaches - building, scrapping, and restarting ideas repeatedly.

I need your help, feedback, and practical input to bring this into a stable reality. Phoenix is a co-operative project, and though I can take this further alone, I would much rather have input from real shoppowners!!

Put as simply as possible, products now exist in three states with explicit purchasing rules:

Parent Product

• Cannot be purchased directly
• Exists purely as a container for variations
• Used to present and organise child products

Child Products

• Can be purchased
• Only purchased from the Parent product page
• Represent the actual sellable variants (size, colour, etc.)

Normal Product

• Fully standalone product
• Can be purchased directly
• No variation structure involved

For clarity, `Normal` products behave exactly as they always have done in Phoenix - nothing changes there.

The entire focus here is on redefining how Parent/Child product structures behave at the point of purchase, while keeping the rest of the system intact.

What we need to achieve is a model where:

1. Parents are purely structural (not purchasable)
2. Children are the actual purchasable SKUs
3. The parent page becomes a controlled selection interface for those children

I'd really appreciate feedback on edge cases, UX concerns, and any structural pitfalls I may be missing - especially around stock handling, cart behaviour, and variant resolution.

Where am I, in the Admin Side


Parent
-> Child
-> Child
-> Child
Normal
Normal

Product Page, Shop Side


When a filter is selected only the relevant Children show


Allowing the buyer to select the one they want

Cart Page, Shop Side

Clicking the usual buy button on product page, will add selected Child to Cart


And because Child Products are a `product`...easy to give them an Image

Side Notes, out loud thinking, all "to do";

1. remove child products from product listings
2. redirect child product_info to it's parent product_info
and
3. make prettier - cosmetics is unimportant for now.

Your Help Is Needed

Phoenix continues to evolve through the people who actually use it.

At the moment, progress is being driven by a tiny group of shopowners who actively engage in practical discussion. Meanwhile, many *many* more shopowners are running live stores but not contributing the real-world feedback that only comes from day-to-day use. If you're running a store and not feeding back your experience, this is about you. That imbalance matters more than it might seem.

---

To move this idea of Parent/Child variants forward correctly, I really need real-world perspective rather than just work on my gut feelings.

• Where might this feel unclear if you saw it in a shop?
• At what point does the experience become confusing for a customer?
• Does the structure match how you naturally think about your own products?
• Where might this create friction in a live store?

This is one of those stages where small pieces of feedback shape the direction far more than large design decisions.

If you are running a store on Phoenix, even in a simple form, your view is highly relevant here - particularly if you’ve not previously felt the need to get involved. And even if you have never touched on "Product Options" as a Shopowner running Phoenix, your viewpoint as a Customer would be golden. We're all Customers as well as Shopowners, right?

Please...now is the time to take a closer look and share your thoughts.

Looking nice! I'm really happy that you started on this
- At what point does the experience become confusing for a customer?
Regarding the product page: I think it would be much clearer for the customer if its only displayed one option at a time. The subsequent choices should only appear after the initial selection is made or the dropdowns list shows.

- Does the structure match how you naturally think about your own products?
Regarding the structure, it makes sense, but we need to stick with our current setup for now. We just paid for an attribute filter specifically for the QTpro module, and we don't want that investment to go to waste.

happy to test

br
Omar

@Omar_one thank you.

If I'm remembering well, QTPro bolts onto the usual Options/Attributes system ?
I haven't really ever used it, so I am unsure exactly how it bolts into Phoenix.

This new Parent/Child proposal does not touch Options/Attributes at all, so I
think shopowner could probably use both at the same time.

Parent
-> Children

Normal
-> Options/Attribs (or of course, none)

Would probably be confusing (for shopowner and for customers), but the
architecture is separate so it should be possible.

--

Note, think & probably & should all in italics above...
As I am unsure until the system becomes something workable

burt wrote: ↑Mon Apr 13, 2026 1:55 pm
If I'm remembering well, QTPro bolts onto the usual Options/Attributes system ?
I haven't really ever used it, so I am unsure exactly how it bolts into Phoenix.

This new Parent/Child proposal does not touch Options/Attributes at all,

yes

burt wrote: ↑Mon Apr 13, 2026 1:55 pm
so I
think shopowner could probably use both at the same time.

Parent
-> Children

Normal
-> Options/Attribs (or of course, none)

That's perfect
--

burt wrote: ↑Mon Apr 13, 2026 1:55 pm
Note, think & probably & should all in italics above...
As I am unsure until the system becomes something workable

It’s much better to acknowledge the uncertainty while a system is still evolving than to over-promise. It sounds like you’re staying grounded and waiting for the results to speak for themselves, which is always the most professional way to handle a work-in-progress.

You’re basically saying, "I’m optimistic, but I’m a realist," and that’s a great balance to strike!

If you need to run some tests, I’m fully available.