Expresso Store: 'Variants' 3rd Party Dev Question

Question

Following on from a question I had a couple months back (Disable certain Combination Variations), I now actually need to do it, and i'm kinda stuck a bit.

What i need to do is this:

Add a product with all its options. Disable certain variations from control panel. Set a price for a certain variation. Give a particular variation a description field Prevent users from selecting a particular variation on the front end (obeying the disabled variation option on the front end). Display description for a particular variation. Charge variation price.

It looks like I can do a lot of this with the stock section. I could use the SKU field for the description. Ok, its a hack, but it'd work.

I could also use the 'limit stock' button to disable a variation , but then, this kind of means that i'm using what may in future be a useful feature, so i'd like to avoid that.

My thinking is to replicate the 'stock' section in a way, with its own table, with all the fields i need.

So, I'm thinking hooks aint gonna cut it. I'm thinking that I probably am best to look at this as a new expression engine fieldtype that just so happens to require store to run.

I guess i'm just looking for any thoughts, or perhaps even a bit of confirmation that a new ee fieldtype would be the best way to approach this (and then using hooks to override product pricing).... because a big concern is whether or not i'll actually be able to do the frontend stuff too.

I obviously want to do this in a way that means it can be reused... (and not get overwritten every time store release an update)

---

To furnish this question with a little more info about the original problem, here's my original question.

Disable certain Combination Variations

I'm selling a series of products, one of which is configurable. It has four options, but not all combinations are available, and different combinations will result in a different price.

Answer 1

Peter is right - how many products and variations you have will make a big difference to how you should approach this. For example, instead of using the SKU as a description, why don't you just have a single option group for each product. There's no harm in having options called "300mm - Mahogany" and "500mm - Plywood" and specifying prices for each one.

Of course this would quickly get out of hand if you have dozens of variations for each item, but if you're going to have to review each option anyway there isn't much difference really.

Another way you can approach this is to set it up as two separate channels, so each Store product only has a single variation/SKU. For example, you can create a channel called "Products", with a single entry called "Table". You can then create another channel called "Product Options", with custom fields for "Size" and "Material", and a relationship back to the original "Table" product. You can then create an entry in the Product Options channel, with Size=300mm, Material=Mahogany (both standard custom fields), and then set only the price in the Store Product Details field, and ignore Store's modifiers altogether.

This method works well if you only have a few main products, and lots of potential variations. It's much more flexible, with a slight trade-off of ease of entry for your client. However, it's also fairly easy to understand, and we've used it successfully in the past.

I wouldn't recommend creating your own custom field unless you're fairly confident with PHP and MySQL. It's certainly possible, but the way modifiers, options, and stock items work in Store is pretty complicated. To get an idea, take a look at the exp_store_product_modifiers, exp_store_product_options, exp_store_stock and exp_store_stock_options tables. If you can get your head around that first, then you should be ok.