In Hikashop, I had a single product with options (three color choices for different part of the item). Each color choice consisted of 10 possible colors, so the total variants were over 1,000. I created an image for each possible variant so when the user selects an option, it would then show in the image box. It was a "poor mans" product designer that worked GREAT when there were only a hundred or so variants.
However, after getting up around 1,000 variants, it became unusable because HikaShop would load all 1,000 variants info, images etc. all at once when going to the product details page. It would take up to 5 minutes to load (if it finished at all) and then would be so glitchy it would often freeze up the device / browser.
So, my question is this... Using "multivariants" (with three options and 10 choices per option), is Virtuemart capable of handling a product with a thousand children / variants, each with its own image? Will it load properly and function smooth? Has anyone done something like this that can provide details on how it functioned?
Also, as a follow-up, will Virtuemart even allow me to create 1,000 variations for a single product? Or, is there some limit in place?
It is really an interesting task and I can say that it should work with VM. At least we have some differences in handling the variants, BUT maybe we have also to tricks a bit.
First it is important to understand how VM loads products. A typical product is splitted on 8 different tables. Additionally we have to load the customfields (1 table). Sounds a lot, but VM uses also a lot caching technics. Lets use some numbers.
Lets assume we show 100 products with 3 customfields each, we would get (8 + 3) * 100 = 1100 sql ops per view. That is a really big task :-) But we use sophisticated caching technics. This means we cache any sql loading products.
Usually a shopowner uses the same 3 customfields on each product, just with a different config and so our calculation would be for 100 products (in the ideal case, that we use always the same 3 customs, just differently configurated per product) 8 * 100 + 3 = 803.
So now lets assume a shopowner is using an unpublished parent product as pattern, which keeps two of the customfields already (the same for each product). We get 8 * * 100 + 8 +2 = 810. Sounds a bit more than the 803, but makes 100 sqls faster, because they deliver no result (DB just uses the index). A lot people think by experiences as yours that children products are bad for performance, but actually using product children makes VM faster!
I think this shows a bit how much you can do with a correct setup of the products. Now lets talk about the multivariant. The trick of the multivariant is, that it does NOT load all products, when go on the productdetail page, or when you browse it. The variants are stored in the customfield. So it just loads the parent, the child product and the other products just as simple dropdown (the information is "prerendered" when you store the parent product keeping the children).
So I think you see, it is possible in general, but you face other, different problems. When you are in the Backend, a normal browser just has problems to display a table with more than 800 rows. There comes the next problem (but simple to solve), I added an hardcoded limit of 700 prodcts per "getProducts" call. So actually you will get also trouble with VM to handle that many children with just multivariant,....
But a VM product can have up to 7 parents. So in your case, I suggest to combine the whole thing with the generic child variant. First create a parent, which keeps your first 10 options as generic child variant. Then add to these childs the multivariant.
Then it should work really smoothed. As explained above. It makes almost no difference if you display 20,50, or 100 variants with the MV, it loads always with the same time.
Thank you very much for the information! I will jump in and start creating variances (beginning with using the first 10 colors as "generic") and then adding the next two colors (10 each) as multivariants of the first 10 children. It will take me a while to enter in all 1,000 total variances but hopefully it will work well. Thanks again!
Another solution is to create a new plugin, so all parameters are set and get in one query. The only limit in this case(or using another system) is the PHP post_max_size and max_input_vars.
Of course if you need stock control per variant, you have to use child else a custom field plugin is very quicker because 10 colors associate to 10 colors associate to 10 colors = 1000 variants or children, but only 30 options(10+10+10)
Yes, when you do not need stock control and not different images per product, then you can handle it with the "string" variant or "media" variant (radio with images).
Quote from: Milbo on May 02, 2018, 22:47:40 PM
...
But a VM product can have up to 7 parents. So in your case, I suggest to combine the whole thing with the generic child variant. First create a parent, which keeps your first 10 options as generic child variant. Then add to these childs the multivariant.
Then it should work really smoothed. As explained above. It makes almost no difference if you display 20,50, or 100 variants with the MV, it loads always with the same time.
I am almost done loading up my "custom product builder" variances, each with their own image (have about 600 left total) and I have been doing it as you recommended... It is working PERFECTLY! I do have one recommendation/issue though...
- After you click the primary parent product, you are presented with a drop down with the 10 "generic children" which in my case, are the "Left Color" choices. This looks good so far...
- Unfortunately, in regards to the "generic children" type (after choosing a color from the drop down), the product title reflects the generic child option... For instance, if you select "blue" from the drop down, the product title changes to "blue"
- However, with the "multivariant" type, I am able to have the color option in the drop down be "blue" but ALSO am able to change the title of the child to whatever I want (in my case: "Custom 3-Color Grip: Blue / Select / Select"
With "generic children", is it possible to be able to have the variant option be something like "color" but then ALSO be able to change the "product title" to whatever you want to specify? As it is with multivariants?