Hello, I'm trying to set up an ecommerce with a large variety of attributes and the final price depending on the options selected, as you can see here:
http://www.latipografiaonline.net/vina_bonnie_v2.1_for_Joomla_v3.4.1/volantini/volantini-a5-1-detail
I found very useful the new multivariant approach, but I'm experiencing some problems after creating around 145 child products (while I needed to reach something as 550 different combinations :-\)
If I try to add some other child products it just redirect me to virtueMart dashboard without saving...
Do you know anything about this issue?
PS: I could also have less child products combinations turning the two last multivariant ramifications , "Tipo di carta" and "Servizi Grafici", into simple string custom fields, because their value don't affect the final price. However the problem in this scenario is that if a customer changes one of the multivariant fields, the value of the string custom fields is reset to their default. Is there a way to "remember" the customer choice of these attributes?
Cant' add more then 110 child products, i have the same problem, please help (VirtueMart 3.0.19)
In the product model loop. The problem is here :
while (!empty($child->product_parent_id)) {
$runtime = microtime (TRUE) - $this->starttime;
if ($runtime >= $this->maxScriptTime) {
vmdebug ('Max execution time reached in model product getProduct() ', $child);
vmError ('Max execution time reached in model product getProduct() ' . $child->product_parent_id);
break;
}
else {
if ($i > 10) {
vmdebug ('Time: ' . $runtime . ' Too many child products in getProduct() ', $child);
vmError ('Time: ' . $runtime . ' Too many child products in getProduct() ' . $child->product_parent_id);
break;
}
}
If you use more then 10 level the loop stop or max execution time
Another problem can be this :
if ($this->memory_limit<$mem = memory_get_usage(FALSE)) {
vmdebug ('Memory limit reached in model product getProduct('.$virtuemart_product_id.'), consumed: '.round($mem,2).'M');
vmError ('Memory limit reached in model product getProduct() ' . $virtuemart_product_id);
return false;
}
Your server have to low memory to support so many products. If you can (no stock) try to use other custom fields, this can save memory and execution time too.
Thanks for reply i ll try do it
Patrick, 10 levels,... means 10 parents. But you can have 550 variants with only one parent. So the problem is not there. It is more likely a memory issue.
When people reported this problem, the number is always different. So it seems to be a problem with either the server OR browser (needs to send the form). It can also be the maximum POST limit. it could also make sense to split the whole thing. Create a parent with the two options "Tipo di carta" and "Servizi Grafici", with a generic child variant. Use this both products to add your Multivariant.
Max, you mean i'm an idiot ?
I can read the code and know that this is 10 parent > child levels
Hi, need help
What can be done to correct the problem? You wrote that can be a problem with the server OR browser. We have a dedicated server with good parameters, up to the latest updates on version 3.16, we added more than 200 products. But now not more than 110. Tanks for reply
Hi FDT,
VM 3.16 do not exist, so i suppose vm 3.0.16 and last direct update is vm 3.0.18.
Because 3.0.18 have some bugn best is to use 3.0.18.6 or beta 3.0.19.6.
Of course try this on a copy and not live site, because this can break plugins,template layouts or other extensions using Virtuemart.
In some server, max allowed memory is set to 128M as default, check if you can set this to 512M.
Another problem can be PHP max_post_size, or max upload size.
You can change this mostly in your server panel in PHP settings
or
php.ini
post_max_size=8M
upload_max_filesize=8M
.htaccess, httpd.conf or virtualhost
php_value post_max_size 8M
php_value upload_max_filesize 8M
Another problem can be max_input_vars to.
Hi,
Thanks for all replies
we found the solution
First we increased the memory size for:
Memory_limit = 256M
Post_max_size = 256M
Upload_max_filesize = 256M
But it didn't help.
When the size of this variable was increased max_input_vars to 10,000, our problem is solved.
It is fixed in vm3.2.1, the reason was a too small customfield_params column in the database. Changed to text now.