1

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.

  • 1
    I think that you need to take a step back and rethink the approach - in what you describe there's too many hacks and limitations where your trying to bend Store to fit. Instead look at other ways to achieve the same result - for example multiple products that combine to form variants of a single product. Ideally could you update your question to include a bit more about the outcome you want, not the details of the path you're currently pursuing. For example - how many products? What are the variants? How many variants? Please provide the original question. More info will help us advise better. – Peter Lewis Feb 1 '14 at 14:16
  • hopefully the above edits will improve the question, and help you see why i'm seeing it the way i am. – stevesweets Feb 1 '14 at 18:39
2

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.

  • ... (added an answer instead) – stevesweets Feb 3 '14 at 7:45
  • In this instance, there is only a few products, and only one product that has four option groups, each option group has at least five options, at a low estimate thats 625 variations (it could lead to thousands of possible variations on this single product). Not all variations are possible, and each variation has a price based on the complexity. The product is being custom made, but the pricelist is fixed. I'm competent enough to do it with a field, i was just hoping for a little back and forth to see if i was missing anything obvious, which it seems I'm not, so thats that! – stevesweets Feb 3 '14 at 7:48
  • Steve - I've converted this back to a comment, as that's what it is. – Derek Hogue Feb 3 '14 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.