CE Phoenix Cart Forum

burt wrote: ↑Wed Jul 16, 2025 4:00 pm Best of all, that roadblock is out of the way - users can just upload (properly formatted) files when they want to add in a new product type

May be out-of-scope for this - but I am looking for "Variants" and this might be a good moment to consider.

Imagine a head product which has up to 20 or whatever small variants. So in the category listing it says for the head product Price from €8.00 and on product_info.php you have the standard description of the head product - and a table with the variants, Example you have Sanding paper with a description - and it comes in slightly diferent vaniants and prices (eg K80 - K100 - K120 - K180 - K240 etc) ..

This is in Magento named Grouped Products if I remember correctly. And it is slightly different and more modern than the attributes system ... which I hate for different reasons.

The usability impact for Grouped Products / Variants for a site with lots of products is very big.

You would need accomodating Google Structured data for this [item_group_id].

Not a request - just thinking ahead .. Thanks Gary for your effort!

We've been talking about uprating options/attribs area of Phoenix for a while, as it is needing an update desperately. No one can agree the way forward and no one has time/effort to get it done.

Put simple, the current options/attributes in Phoenix is the only part that lets it down. No Image, No SKU, No Qty, No Nothing it's shite.

I still like the idea of "parent" and "child" products, where parents show everywhere, but children only show on the master page.

EG:
Tshirt (parent)
Yellow, Small (child, 3 in stock)
Yellow, Large (child, 5 in stock)
Red, Long Sleeve, XXXL (child, 10 in stock)
etc etc

I might take a look at some point in the near future.
Too many plates are spinning at the moment, I have too much code work ongoing.

I'll split the conversation out later on, as it deserves it's own thread, where we need to get other community members to have a say.

Split. Community, please get involved.

burt wrote: ↑Wed Jul 16, 2025 6:36 pm Split. Community, please get involved.

Good!

I'll split the conversation out later on, as it deserves it's own thread, where we need to get other community members to have a say.

Yeah - we need involvement but also respect the fact there is limited time for both developers and shop-owners. My own time is also very limited so I am sorry not to be able to be more helpfull.

I can think of two different use cases:
-Variation of the same product (different color and/or size t-shirt). Needs individual stock, SKU and maybe images and price. Name and description would probably be the same.
-Different quantity of the same product (100g or 500g - or 1 pcs or a box of 20 pcs). Needs individual price and maybe some mechanic for stock-keeping. SKU, image, and probably name and description would be the same.

If I think of more or read about other uses, I'll add them.

//Daniel

I don't use attributes so I'm probably not the best person to comment on this but I always thought it should be simplified to something like master and slave just like Gary seems to be suggesting.

I still like the idea of "master" and "sub" products, where masters show everywhere, but subs only show on the master page.

What is the problem with this approach? Are there situations where this just wouldn't work?

Dan

Kofod95 wrote: ↑Wed Jul 16, 2025 9:43 pm I can think of two different use cases:
-Variation of the same product (different color and/or size t-shirt). Needs individual stock, SKU and maybe images and price. Name and description would probably be the same.
-Different quantity of the same product (100g or 500g - or 1 pcs or a box of 20 pcs). Needs individual price and maybe some mechanic for stock-keeping. SKU, image, and probably name and description would be the same.

I would expect 100g and 500g to be separate SKUs. Image and name as well.

There's also things like gift wrap. Doesn't need a separate SKU. Both with and without gift wrap is the same product. Inscribed is the same kind of thing in terms of stock, but is more open-ended in selection.

Or a builder. There, the product doesn't need a SKU, but the pieces do. For example, if you are building a PC, you might have a choice of cases, motherboards, CPUs, video cards, storage (hard drives, SSDs, etc.), keyboards, mice, etc.

Some things might support more than one. For example, a t-shirt might also be inscribed. A uniform might be inscribed and built. Perhaps uniforms might come as singles and as a five-day set.

The problem with master/subs is that you still have to build the selector. For example, for t-shirts, you want to select color and size separately. This is doable. Note that Amazon has parent and child products and can select them separately based on attributes. However, it's not really simpler. It just shifts the complexity to describing the variant.

Hi;
I do have too many attributes on most of the products and really hope for a better way to manage them.
Have separate subs meaning more complexity on products that may cause too many of subs then...

Most variants have stock with no limit as they are customized.
And some variants are with limited stock so will need the qty. limit on them.

I may not suggest the master /slave type approach as with much more attributes it may get complex..

Currently we need a kind of combo of Ajax Attribute Manager and QT Pro addons in core which will take it way forward..

Regds./
radhavallabh

burt wrote: ↑Wed Jul 16, 2025 6:10 pm Put simple, the current options/attributes in Phoenix is the only part that lets it down. No Image, No SKU, No Qty, No Nothing it's shite.

Image: app.php/addons/free_addon/options_images
Weight: app.php/addons/free_addon/attributes_weight
Qty: app.php/addons/free_addon/qtpro

The first 2 are very easy to integrate into core.

QtPro would need some simplification for the Product info module, no need for 4 different selection methods. SKU can be very easy added to it and stored in the qty table.

Maybe an alternative to a complete remake with product variants/master/slave etc. Not sure about pro/cons of both. But at least much easier to realize.

QT Pro would not make a good basis for an attributes system. It's bolted onto the existing attributes system in a way that makes it finicky and fragile.

osC 3 variations system [...] don't like it as it essentially works by mapping strings to the various options. Again, finicky and fragile.

Which leaves us with "sub products" as a potential option.

Maybe something could be done a bit like the "product_images" part in product adding/editing ?
Instead of "images" have "image | name | description | stock | sku | qty | weight"