Product Options

@ modx
Yes, I thought so too in regards to ecommerce. Which is why I went looking on the net for a solution.
However, something is brewing and apparently it might be the solution for modx.
http://modxcms.com/forums/index.php/top ... 8.180.html

note: That was forwarded to me when I was talking with the CEO of modx. Also, December is going to be a happening month for modx.

Still haven't really gone into it too much. But I do know that sku's are a major part of the system.

@ millionaire
lolo, I will 1 day

I do agree that this is in a way a the holy grail, but this is part of my personality. Always trying to find a way to make something better. I might not be Steve Jobs but I really can understand his drive to make things better. I went to a seer once and she said the same thing about me, except that I've been doing this for centuries

@ agile development frameworks -- ie, zend
That could be one of the problems of magneto. Zend is not the fastest but people like because they are the folks that put money and time into php. Actually, I heard that Grails kicks but ... it's java. php is still lagging in the field of RoR, Grails and django ... I tried to find a compatible php option but ... mvc is still the way to go with php.

@ framework
I have also said the same thing about programmers in other threads.
However, what is the focus? Adding functions to say that you do the same thing, meaning it's just a matter of personal choice or do you want to differentiate yourselves from other code bases?

I might not be using the right terminology for "ecommerce framework" but those 2 words are what most people looking on the net will understand. They could give a ratz arse about yii, code ignitor, cakephp, or zend for the backend framework. They are more interested in knowing that XYZ application is agile, fast, strong, and modifiable to meet their own specific needs.

What I'm trying to convince you all of is really simple.
IF opencart were a agile, hardened, easy to mashable system you would have the killer solution in the php world. Possibly among all the languages. I have not found yet 1 cart that does this.

Getting even close to the holy grail would even allow you to place yourself above Magneto and oscommerce combined.

What will that get you?
lolo, possibly a nice fat check from Google!

Xsecrets wrote:I have to say after looking over the schema proposed at the beginning of this thread I think with some tweaks it could make a very nice option system. It would of course have to be tweaked to accomidate the new option types, also you would have to figure out how to handle having only some of the options be a sku as mentioned above the large-green part of a tshirt would be a sku, but you don't want the text entry or file upload fields to be included in that sku. Plus I think I would rather have the arrays and such handled in php instead of javascript, but I think all those issues could be worked out for a nice system.

Option Types:

Just create a table to store the different types of options available (i.e. Select, Radio, Checkbox, etc.) and add a column to the option table to specify which type should be used.
Arrays in PHP instead of Javascript:

If you just pass the product_id along with the chosen option_value_ids to PHP you should be able to figure out the SKU from that. However, I think the javascript array would still be useful for dynamically enabling/disabling options that aren't available. Of course you'd re-validate everything in PHP just to be safe.

As far as the custom fields and file uploads you mentioned, I think we could figure something out. Let me think about it!

So basically 1.5.0 will come out with Global Mega Options which is available now for 1.4.9 - all options available NOW are select, radio, checkbox, text input, text area, file upload - (shameless plug)
Up to this point I have hardcoded SKU's (& any other extra fields) for merchants based on their needs, but in the next release I may put all extra fields in the hands of the admin user.

So if 1.5.0 brings out global options... I'll release dependent options... with validation... how fun will this be?

readyman wrote:So basically 1.5.0 will come out with Global Mega Options which is available now for 1.4.9 - all options available NOW are select, radio, checkbox, text input, text area, file upload - (shameless plug)
Up to this point I have hardcoded SKU's (& any other extra fields) for merchants based on their needs, but in the next release I may put all extra fields in the hands of the admin user.

So if 1.5.0 brings out global options... I'll release dependent options... with validation... how fun will this be?

I've send you a couple of e-mails over the last 2 weeks, about your Global Mega Options, no response up until now

PM me, maybe you're going to spam for some reason. I have no outstanding emails to respond to at the moment.

If I can put in my .02. Please, no emphasis on skus please.

I've yet to use the sku field for anything. I do use model number however.

I like the idea of being able to select from preset options. Prespecify options like we prespecify categories and then when we get to the options tab for each individual product they've already been typed in and we can just select from them. And maybe still be able to enter options from there as well if its something that is one off or custom.

I'm experiencing anxiety with options now for a client that has 8 lengths for every one of her products. Entering them in options one by one for every product is going to be tedious.

patchouly wrote:If I can put in my .02. Please, no emphasis on skus please.

I've yet to use the sku field for anything. I do use model number however.

I like the idea of being able to select from preset options. Prespecify options like we prespecify categories and then when we get to the options tab for each individual product they've already been typed in and we can just select from them. And maybe still be able to enter options from there as well if its something that is one off or custom.

I'm experiencing anxiety with options now for a client that has 8 lengths for every one of her products. Entering them in options one by one for every product is going to be tedious.

I would bet that you either run a store where you dropship or you don't have that many products. Many people will use a SKU in addition to a UPC and model number. The model number is generally the manufacturers SKU, the SKU is your own inventory tracking number (since if you carry multiple manufacturers it is possible for the model numbers to overlap), and the UPC should be the actual UPC for the product (this is useful for submitting your products online to feeds like Google Base).

As far as product options go, you might want to try installing the Export/Import extension. It should help you add those product options must faster! Especially if you combined it with some sort of keyboard/mouse automation program like AutoIT Script (autoitscript.com). Here is the link to the extension: http://www.opencart.com/index.php?route ... sion_id=17

For what it's worth, I have three OpenCart sites running and none of those store owners use SKUs.

SKU/UPC are used for retail sites that sell pre-packaged merchandise. Ipods, tvs, vcrs, etc all use skus. Clothing is especially big on skus. Many stores selling software or beads or soap or whatever don't have a need for sku.. But it is equally important to have

Yeah - it's definitely good to have. I was just saying that not every store uses them (two out of the three clients I mentioned sell clothing).

Sorry to wake this thread up but there may be some new blood and 5 months later, the situation is the same.

The problem (as raised time after time by different people) is that it is impossible to check stock if there is more than one product option - you can tell how many Small shirts; you can tell how many Blue shirts; but you can't tell how many Small Blue shirts are in stock.

This single issue would put Opencart in a different league; it is currently only suitable for trivial applications.

I will happily pay for a commercial solution.

As a start point, can anyone provide a SELECT query that generates a dataset of ALL possible unique products?

select * from product
Cross join product_option
Cross join product_option_value
Where product.product_id = 123 and product_option.product_id = 123 and product_option_value.product_id = 123

Would collect options for Product 123 but how can I extent this for each product (Where Product_id in (select Product_id from product)) ?

How can I get the Cartesian product of multiple Select statements because Cross Join only allows tables (do I have to create temporary tables/views?).

My SQL just isn't up to it. Can anyone help?

well the big problem is that with the current per product options even a commercial solution would be very difficult, and with 1.5 supposedly coming out soon with everything changed to global options you know you would have to completely rewrite it. So why would people spend vast amount of time on something where the revenue stream has the potential to dry up pretty much overnight if 1.5 is released.

1.5 will apparently have something akin to Mega Global Options so that defined options can then be assigned to multiple products but the same problem exists.

Unless there is a relationship between Options, it is impossible to control stock which makes it a non-starter for any serious application.

Once 1.5.0 is released I'll take a look and see if I can come up with a solution.

I think you will see a solution in short order once 1.5 comes out. There are several people who are looking at this, as a matter of fact there is a db schema at the beginning of this thread that handles it, but it's rather pointless to spend alot of time on ti right now if it's all going to become irrelevant tomorrow.

Several looking... nothing seeming to come from it. I can't even draw it conceptually on paper. I just can't envision the db structure to allow for this. Sometimes I think i got it.. and then I realize I don't... not dynamically. Hopefully others have better vision than I do on this.

Qphoria wrote:Several looking... nothing seeming to come from it. I can't even draw it conceptually on paper. I just can't envision the db structure to allow for this. Sometimes I think i got it.. and then I realize I don't... not dynamically. Hopefully others have better vision than I do on this.

what's wrong with the db structure outlined in the very first post of this thread. It will work perfectly well. Of course there is some code that needs to be written to go with it, and the hardest part is coming up with an easy to use admin interface for entering the data.

Maybe I don't get it.. but it looks like you still need to show people
"White-small"
"White-large"
"White-xlarge"
"Blue-small"
"Blue-large"
"Blue-Xlarge"

The example query doesn't actually return the qty or price but I suppose that can be added. But I don't really get it. How would you handle the dynamic loading of subsequents or set what the "parent" is.. unless they are all parents based on the last one selected.

If I have 10 Large White Shirts i need to say:
Then another guy wants Then another guy wants

why does anything need to be a parent?
your options and values are still just options and values. the only difference is that you are moving your price/qty etc out into a sku table then using a relational table to link it back to any combination of option values you want.

Nothing is a parent. Though like I said creating a good easy to use interface will be quite challenging. I've never really seen a great interface for it.

generally what you have is you setup your options and values as normal, then you have a button for create sku's or whatever you want to call it that takes you to a different page where you can create sku's by choosing combinations of option values.

I'm certainly no database expert, but logically I think the problem is being addressed back-to-front. The point of this exercise is to allow users to enter stock levels for particular types of items. Therefore, shouldn't the discussion be more along the lines of 'what is the quickest way for the user to enter all of their stock levels'?

At the end of the day, the user is going to need an interface where they can enter the type of product (e.g. a shirt) and then all of the options (colour, size etc). I think the solution lies in giving the user a page which is called 'Stock levels' and it lists every product, and every option for that product, on the one page. Next to each item is a text field for the stock level and a single 'submit' button updates the entire page (or use AJAX to just save the values).

Thinking about the database from that perspective, I think you need to have parents (products) with child options (colour, size etc). The only extra level of complexity lies in storing children of children, but again I think in the end the user is going to need to enter those items manually so it would be a matter of entering something like this:

----------------------------------------------------------------------
Polo shirt
----------------------------------
+ Colours: Blue | Green (becomes a drop-down below for each combination row)
+ Sizes: S | M | L (becomes a drop-down below for each combination row)

Combinations: (these would be dynamic rows where the user can choose from drop-downs populated from the options above)
== Blue + Small QTY: 35
== Blue + Medium QTY: 50
== Blue + Large QTY: 20
== Green + Small QTY: 20
== Green + Medium QTY: 0
== Green + Large QTY: 67
----------------------------------------------------------------------

On the front end, the product's option list is built simply by listing all of the children.

I know that sounds quite simplistic considering the technical programming requirements, but does it make sense on some level?