Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
We're building out a new ecomm store with Vendr for the first time.
Previously used TC extensively.
How does Vendr handle Variants?
In TC there was a control we added to setup those variants as a property type.
We'd set the Variant details in a separate node, Colour, Size, Price and so on.
Is this handled the same way in Vendr?
We're building a Signage ecom site, so would need to have a start size range and end size range for a product x price per sq meter.
So for instance:
Banner - From £12.50 per M2
Up to 20m2 @ £15sm
20m2 > @ £12.50sm
Not sure how I can handle that with Variants in Vendr, can it be done?
We don't yet have multi variants which is what the control that was in TC was. It's on our todo list but we've been waiting on the v8 block editor so that we can try and make use of some of the built in Umbraco features for it.
Currently then Vendr only supports single level variants where you only have one varying quality of a product and these are handled by creating child nodes to the parent product node. If you take a look at the demo store at https://try.vendr.net you can see what I mean.
I think if your only changing factor is the range, then this might be ok for your setup, it just depends if you are going to have any more configurable options?
Ah right Ok.
Yeh, we've got Multiple Variants.
There are only 6 products, however they have Size Ranges.
And finishing options. But I suppose they can be separate products.
Same as Pole Sizes and some have other options, which I could do again as separate products and just x by sqm. Or even bundles.
I don't suppose you have a time estimate for the Multi Variant options? I guess it depends on the release of the block editor?
Yea, I was thinking bundles might work for you if you have configurable extras.
Unfortunately until 8.7 is out with the block editor we don't really have an eta. We started drafting out how this might work from a data perspective but then the block editors data structure has changed recently according to the RFC so it all feels a bit unstable until it is released.
We could do our own thing, but it would mean we couldn't take advantage of any optimizations core introduce for the block editor, like better indexing or the potential for block items to get stored as nodes in the DB later on down the line.
Not to worry.
I think we'll get away with it, The Finishing Options and Other options have no Price increase to the product.
So really I think I could just add them as a Bundle product, they arent size dependant on the Banner,
They are just stuff like 'Hem Eyelets', 'Trimmed to size' which don't have a price increase but just need to inform them what the customer has picked.
There si one thats nested, but i think i can handle that by nesting a product by product, Pole Pockets.
That then nees to know Pole Size, 150mm, 100mm and so on.
But again no price increase, just inform them what they have chosen, so could just potentially add them as a bundled product to the order line at £0.00
If there is no prices increase on most of these, they could also be stored as order line properties and used as uniqueness product properties to force distinct order lines per configurations.
I think there are quite a few options then that might be able to work for you.
Feel free to shoot me your thoughts on a setup and I'd happily give you my input 👍
Cheers Matt, thanks for sounding this out, makes more sense now :)
Awesome product by the way, we're all loving working with it.
I'll shout if I get into a bind.
Really looking forward to see your thoughts on it, especially given your TC experience.
As always, I'm here if you need anything 👍
You could just create different Product Types, all of which have different extra property types.
At the beginning of the project, you probably think you need a product which uses an endless supply of variants. But in reality, (over time) - you slowly come to the conclusion that most have common attributes, which are never going to change, and are better placed at product level.
"Add-ons" and "Bundles" could just be considered as separate products themselves, and just be made available by using a "content picker".
I agree with Matt, which regard to "sitting and waiting" from HQ about blocks. Although the Variant creator was (is) great in TC, it is a "non-core" property type, and requires quite a bit of funky JS to wire up.
I'm also in the middle of a vendr based project, also having some (bad) TC experience with a Product and ProductVariant scenario.
I've created a parent Product type with ProductVariant child types. Works ok, so far ;)
Great work - Sometimes its easy to overkill a solution with the "what if" thinking. To handle 10000000000001 scenarios - When in "real life" your client is merely going to be confused by an overly complex product builder.
Just build what they "asked and briefed you" for - and if something requires updating, go back and bill them for time and changes.
Ignore anything that starts with "It would be great if....."
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted