Options Attributes - discussion

[ecartz]

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.

I'd sort of lean towards

1. Remove attributes from core.
2. Add any hook points needed to make an add-on.
3. Release attributes (the current core version) as an add-on.

Then if someone wanted to release any of the versions under discussion, they could. Some would work for one store. Some wouldn't.

QT Pro could become its own system then. It wouldn't have to work around the existing system. It could make its own choices.

Part of the problem is that we're trying to make attributes work for all use cases. However, there are four or five different cases (e.g. we haven't mentioned downloads yet, which are currently done through the attribute system). There probably should be four or five different systems to match. Someone like burt would probably have already released some different systems if there weren't already a system in core.

[azpro]

1. Remove attributes from core.
2. Add any hook points needed to make an add-on.
3. Release attributes (the current core version) as an add-on.

Then if someone wanted to release any of the versions under discussion, they could. Some would work for one store. Some wouldn't.

+1

[Dan Cole]

Part of the problem is that we're trying to make attributes work for all use cases. However, there are four or five different cases (e.g. we haven't mentioned downloads yet, which are currently done through the attribute system). There probably should be four or five different systems to match. Someone like burt would probably have already released some different systems if there weren't already a system in core.

I agree it needs to be simplified but I would lean towards having a master/slave system in core which would probably work for most and add-ons for anything that doesn't.

Dan

[ecartz]

We don't need a parent/child in core. It's one of the easiest to add on. Just

1. Add a nullable parent_products_id column to the product table.
2. Add a field in admin's new/edit product pages to select the parent product ID (which could be just a text box).
3. Add the column to what gets saved when the form is submitted.
4. Add a new module for the product info page to display the child products, with buy buttons.
5. Create some kind of page to view the child products and link to it.
6. Remove the move and copy buttons in admin (or replace them).

Since they're real products, everything else just works. No new hook points needed. There's no reason to make any core changes to allow that. It's probably small enough that if someone really wanted it, they could just pay for it to be developed. Or a few people could band together, each putting a bit in.

OK. One core change: https://github.com/CE-PhoenixCart/Phoen ... ct.php#L43 would need to be moved into a hook, possibly the existing insertProductAction hook.

Alternately, instead of a selector for the parent product, you could add a button to the product info box that allows to add children. Then the field on the new/edit product pages would be hidden.

[burt]

Mens Trainers
9, Blue
9.5, Blue
10, Red

Womens Trainers
7, Blue
5, Blue
3, Red

Shopowner probably would not want these child products to be orphaned in (eg) products_new.php as a male shopper might end up buying a "7, Blue" without realising this is a female fit.

That would need careful consideration in core code - the ability to easily remove child products from menus, pages, lists..

[ecartz]

That would need careful consideration in core code - the ability to easily remove child products from menus, pages, lists..

Except we already have a hook for that: https://github.com/CE-PhoenixCart/Phoen ... er.php#L31

Add criterion: parent_products_id is NULL. Done. In a hook, without modifying core code.

[azpro]

Bumping this discussion.

Are there shopowners who like to team up ($$$) so ```a coder``` can code a Parent/Child solution?

My request would be an Extra tab in admin product eg - https://phoenixcart.org/demo_admin/admi ... ew_product

After you made a new product - you should be able to mark it as Parent and then copy it by an input box eg 10 times and those products are marked Childs. The idea is the Parent data are the same for each Child - except minor differences for example EAN - Price and Product name. So you have a table in admin Parent product where you simply correct EAN - price etc. But the Main description and Images are the same. Otherwise it would be more an Attrributes thing. That might be important for other shopowners - but not for me at this moment.

Than in admin there will be a table to select (extra) Childs for the case (eg) you have an automated .xls from supplier which you have imported to the database. Or you start using Parent/Childs from an old database etc.etc. So in cases where your products are allready in your catalog / databse but need to be transformed to Parent/Child.

• First line gives the Product Name - Product Model - reference - Price - EAN and a thumbnail of the product you work on (the Parent)

• Second Line gives an input box with ajax Type Ahead search (the childs). Already selected childs should not appear in Type Ahead list. Search on Products name - model - reference ++

• Third line - gives the child Product Name and a thumbnail you have selected

• Fourth line - gives the child Product Name and a thumbnail you have selected etc etc

• Last line - Update Button - update by Ajax

The childs list should be draggable to sort eg https://mdbootstrap.com/docs/standard/p ... ic-example

On the shop side ... On the Parent Product page a table with the Childs (Product Name and a thumbnail + off course price - might be a special price) (order by sort order set in admin) and input box to let customer give a number to put in shopping cart and in the footer of the table a Button to put all childs in cart at once (possibly by Ajax) .. But customer can also give enter/return so the child goes in shoppig-cart.

On the Parent/Child page the Google Structured data should be taken care of.

On category pages the Parent product should have a price tag "From $5 - $15" instead of single price.

I made/code this in old OSC and it was doable - in Phoenix probably even more easy - but I want it done by professional / expert!

Please reply in the thread if you would like to team up and what your budget would be. And state your special requests for your business.

Remember - this is a team effort - give your feedback - and $$ - and let Gary - Matt or any expert who is available - to do their magic if they are prepared to take the assignment.

Thanks! Arjan

Edit to Parent/Child - TY matt

[ecartz]

After you made a new product - you should be able to mark it as Master and then copy it by an input box eg 10 times and those products are marked slaves.

It would be simpler to just allow child products to be added to any product that is not already a child product. I.e. any product that is not a child of another product can be a parent. One button added to the infobox: Add Child.

In general, I would recommend parent/child over master/slave, as the latter terminology has issues in the US. I realize that Matti Ressler's version used the master/slave phrasing, but if you're starting fresh, might as well use the more inclusive version.

[azpro]

In general, I would recommend parent/child over master/slave, as the latter terminology has issues in the US. I realize that Matti Ressler's version used the master/slave phrasing, but if you're starting fresh, might as well use the more inclusive version.

TY - post edited accordingly

It would be simpler to just allow child products to be added to any product that is not already a child product. I.e. any product that is not a child of another product can be a parent. One button added to the infobox: Add Child.

That is over my head What I try to do with copy (eg 10x) is saving time in the process of adding products (the data / image etc) which is standard. We just need 10x (eg) product-id's to fill the childs list. Than we only have to change the EAN and model for instance. In my system / solution the standard table products is used. A new table defines parent product-id to childs product-id.

Maybe an example clarifies. You have a product "spanner" of a certain brand/manufacturer. So this product is added with a beautiful description - nice images - optimized etc. That is the Parent. Now we copy it in this case 38 times. Because we have sizes 4 mm - up to 54 mm. But each size needs SKU - model - EAN and price. Price (purchase and sales price) ... Product for all the sizes is the same - but I would not recommend a 54 mm where you need a 10 mm

But there might be much better solutions!

[burt]

Assume the following, mostly as per Matts advice;

In Admin catalog.php

1. Put a button in the right hand column "Add Child"
1a. When clicked it pops up a modal with a form
Make the form have at the very least "Name, Price, Model/SKU, Qty" & Hidden parent product_id
Make that form hooked, so anyone can update it with more form fields.

2. make a new column in DB products.parent_id

3. Have the form in #1 write to products Table etc

4. Maybe add in some type of icon to differentiate a parent/child product in the list

At this point we know that any product that has a parent_id...is a child.
Yet these child products are more or less just standard products.


In Shop Side

5. Have the shopside react appropriately
5a. don't show child products anywhere (use criterion on product_searcher)
5b. make a content module that displays child products - could be individual buyable (each child has its own buy button) or multi (eg buyer wants to buy 10mm, 12mm and 20mm spanners in one shot, maybe tickboxes and one buy button).
5c. if a shopper somehow tries to access a child product page, simply redirect to the parent page (perhaps with the relevant child product highlighted or selected).

That seems like a solid way to approach this.