Too Many Attributes Breaks the Product?!?

[error411]

After adding 4 Attributes, each with about 5 to 10 values, generating the combinations (with the Attributes Generator) my product will not display. It also seems to break the Categories Block.

I have included a screen shot of the Admin panel and the Product page. The Admin panel shows the 3645 Products being successfully created (yikes). And the Product page shows the front end result.

Keep in mind that all the products (relating to this attribute combination) worked fine until I added the last Attribute (happened to be Logo_Color).

It seems that the system doesn't like this many Attributes.

Using Version 1.1.0.5

Can anyone comment on this or help with any suggestions?

As a side note: All the products and attributes have been imported using import tool. I simply have to use the Attribute Generator for each product to create all the combinations (which worked fine until this last Attribute addition).

Thank you in advance for any help.

Dan Walter

[knford]

I'm having the same problem. I have eight options with four to five values each. It says "24500 product(s) successfully created" and doesn't display anything else after that. I suspect there may be a database timeout issue going on now. If I add any more values up to a certain point, things stop working in the backend admin of the store and the product detail page on the front end of the store takes fifteen or more seconds to load. Long story short, this is a very bad design issue. In the database, there are nearly 100,000 different combinations created and stored in a table. I don't think there is going to be a fix for this one as it's not a bug, just a poor design. At this point we'll need to eliminate some options and values or find a different ecommerce solution.

[tmouse]

I can only confirm the problem, this is a design issue I will try to investigate if can be hacked easily.
As i mentioned in other post, you can disable showing of combinations in admin panel (by hacking files) but this does not solve heavy load on DB during product display.

I dont expect this to have easy solution but nevertheless try to do something as overall this shop software fits my needs best, bar this one blocking issue.

[TheotV]

I ran into the same problem with Prestashop 1.2.0.8. It seems to crash when more than 10.000 combinations are generated.
Any news on this subject? Any solutions found lately?

[tmouse]

I finally modified my installation of prestashop - removed creation of combinations during product definition.
Now combination is created dynamically only when user actually selects it and puts into cart.
Price/weight modifications are calculated from impacts on the fly and even if i have products with 100K combinations only few are in DB.

Its more like hack than ultimate solution thou - combinations have to be cleaned during impacts updates so old ones are not used.

[TheotV]

How did you do that then? If you choose a combination that is not valid, Prestashop gives an error about a non-existant combination if I recall correctly. Did you change the code to create the combinations dynamically? Sounds interesting.

[tmouse]

Yes, I changed the code creating effectively two classes of products (yet another column in products table). 'Old ones' and 'dynamic'.
Now when user attempts to put dynamic product into cart, request is intercepted and checked if specified product combination exists, if not it is created in the same way generator does this.
Then control is released and shop works as usual - I didnt want to check where exaclty those combinations are used so after this step shop does not care if its full combinations product or 'dynamic' product.

I had one issue was with default combination (first created combination was taken as default, even if it was at higher price as base) but was able to hack it.

I added attribute priorities, so default one is selected according to some integer number attached to it (needed when you have set of 26 colors and different products have different defaults without additional charge).

[spott]

Can You share Your code?

[TheotV]

Very smart tmouse! I am also interested in your code. I have no problem with coding myself, but the problem with Prestashop is that the documentation for developers is not up to date. (To say the least). Or did I miss something and is there documentation somewhere I did not stumble upon yet?

Hopefully we can help each other here in the mean time until the documentation gets better.

If you can give us a look at the code you made the changes with, that would be great. Or maybe you could give us a hint about the place (files, classes, functions) you made the changes.

Cheers!

[tmouse]

The code is not really in a shape to be published (as there are some hacks and things 'I know' not to do).
BUT when I get to it I'll try to summarize where I had to change things and how, so maybe someone will come up with more clean solution.

For example, there is currently no interface to change impacts from GUI because im updating them with SQL queries using my EPMT = External Product Management Tool = Excel with Macros)
Updating hundreds of impacts with GUI would be suicidal.

[TheotV]

I'm willing to think with you about a more clean solution. But how did you find out where to change things in the first place?
Looking forward to your answer!

[tmouse]

You motivated me enough to take a second look at what I've done. I'll try to summarize as cleanly as possible

1st warning - my modifications currently allow adding product to cart only from product page (so no adding directly from accessories list, etc) This can be probably fixed easily but because in my case adding product without selecting options is not meaningful it stays like this.

Having said that, major modifications went to:

database
products table - added column with indicator if its dynamic or not

`product_combinations` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT 'Are new products created with all impacts combinations'

./product.php
I had first send impact information to client, then to collect information about specific attributes and groups selected and send them all back in POST. This way, server is able to work out if this attribute values combination exists or not

./cart.php
major task - during 'add' operation attribute combination is actually checked and if required product_attribute incarnation is created based on main product - creation code snippet below:

   $productImpacts = $product->getAttributesImpacts(intval($cookie->id_lang));

   foreach($attributeGroupChoices as $attributeChoiceID)
   {
       $priceOfCombination += floatval($productImpacts[$attributeChoiceID]['price']);
       $weightOfCombination += floatval($productImpacts[$attributeChoiceID]['weight']);
   }
$new_product_attribute_id = $product->addProductAttribute($priceOfCombination, $weightOfCombination, 0, 0, null, null, null, "", false);
$product->addAttributeCombinaison($new_product_attribute_id, $attributeGroupChoices);

I had to improve impacts handling here and there as in base prestashop it is rarely used besides administration.
Also mentioned before - without 'default combination' shop started behaving wrong, so I killed whole default attribute thing in classes/Product.php

static public function getDefaultAttribute($id_product, $minimumQuantity = 0)
{
return 0;
}

More proper solution would be to create default product combination during product addition or add special handling here.

hope I presented above clear enough, I might've missed something but those are major places that needed changing.
I am monitoring this thread so if time premits I'll try to help more

and yes, documentation could exist, it would help a lot as it took me few weeks to understand how shop was made. database model was nice to see thou

[TheotV]

Cheers!
That helps.
I am not exactly sure when I have time to dive into this; probably not before the weekend. But I will surely use this idea in some form. It solves one of the major issues with Prestashop for me as long as their developers will not change the way Prestashop handles attributes.

That brings me to another issue I haven't solved. I posted another thread here(http://www.prestashop.com/forums/viewthread/26505/general_discussion/product_customization_issues). Do you happen to know a way to change the labels of customization fields in the cart? They are now presented as Text #1, Text #2 and I just want to show the name of the option that is chosen. The other issue is not that important anymore. Any chance you know where to find this in the Prestashop code?

I'll definitely have a try with the dynamic attributes in the future.

Thanks again.

[tmouse]

I'm not sure if this works as I killed whole customization functionality in my shop but there is a table customization_field_lang that looks like place where names of customization fields should be kept

hope I understood your problem correctly - as of per character pricing i would've added javascript code to display price for client on the fly and then some additional (maybe little hard-coded) logic during cart addition (product in cart has its own price set, independent from original product - so whatever you put there will stay)

[Tomasz Słomiński]

I'm having the same problem. I have eight options with four to five values each. It says "24500 product(s) successfully created" and doesn't display anything else after that. I suspect there may be a database timeout issue going on now. If I add any more values up to a certain point, things stop working in the backend admin of the store and the product detail page on the front end of the store takes fifteen or more seconds to load. Long story short, this is a very bad design issue. In the database, there are nearly 100,000 different combinations created and stored in a table. I don't think there is going to be a fix for this one as it's not a bug, just a poor design. At this point we'll need to eliminate some options and values or find a different ecommerce solution.

Indeed. Change in classes/Product.php

   public function getAttributeCombinaisons($id_lang)
   {
       return Db::getInstance()->ExecuteS('
       SELECT pa.*, ag.`id_attribute_group`, ag.`is_color_group`, agl.`name` AS group_name, al.`name` AS attribute_name, a.`id_attribute`
       FROM `'._DB_PREFIX_.'product_attribute` pa
       LEFT JOIN `'._DB_PREFIX_.'product_attribute_combination` pac ON pac.`id_product_attribute` = pa.`id_product_attribute`
       LEFT JOIN `'._DB_PREFIX_.'attribute` a ON a.`id_attribute` = pac.`id_attribute`
       LEFT JOIN `'._DB_PREFIX_.'attribute_group` ag ON ag.`id_attribute_group` = a.`id_attribute_group`
       LEFT JOIN `'._DB_PREFIX_.'attribute_lang` al ON (a.`id_attribute` = al.`id_attribute` AND al.`id_lang` = '.intval($id_lang).')
       LEFT JOIN `'._DB_PREFIX_.'attribute_group_lang` agl ON (ag.`id_attribute_group` = agl.`id_attribute_group` AND agl.`id_lang` = '.intval($id_lang).')
       WHERE pa.`id_product` = '.intval($this->id).'
       ORDER BY pa.`id_product_attribute`');
   }

to

   public function getAttributeCombinaisons($id_lang)
   {
       return Db::getInstance()->ExecuteS('
       SELECT pa.*, ag.`id_attribute_group`, ag.`is_color_group`, agl.`name` AS group_name, al.`name` AS attribute_name, a.`id_attribute`
       FROM `'._DB_PREFIX_.'product_attribute` pa
       RIGHT JOIN `'._DB_PREFIX_.'product_attribute_combination` pac ON pac.`id_product_attribute` = pa.`id_product_attribute`
       RIGHT JOIN `'._DB_PREFIX_.'attribute` a ON a.`id_attribute` = pac.`id_attribute`
       RIGHT  JOIN `'._DB_PREFIX_.'attribute_group` ag ON ag.`id_attribute_group` = a.`id_attribute_group`
       RIGHT  JOIN `'._DB_PREFIX_.'attribute_lang` al ON (a.`id_attribute` = al.`id_attribute` AND al.`id_lang` = '.intval($id_lang).')
       RIGHT  JOIN `'._DB_PREFIX_.'attribute_group_lang` agl ON (ag.`id_attribute_group` = agl.`id_attribute_group` AND agl.`id_lang` = '.intval($id_lang).')
       WHERE pa.`id_product` = '.intval($this->id));
   }

[spott]

But this dowsn't show the product attributes at front office.

[Tomasz Słomiński]

Maybe it's database timeout frontend, too. Or php memory limit is exceeded . We had problems only with backoffice (for few thousands of combinations), at solution worked. How many combinations do you have ? Did you try to change memory_limit? If you run this query direct in phpMyAdmin or mysql command line, do you have any results?

[spott]

1458000 products

And I have only five attributes groups...

Sad, that Presta team doesn't give any answer about this problem. They just ignoring that.

[Tomasz Słomiński]

Wow, quite impressive. I don't think that Presta Team even bothered to make performance tests. In fact, for back office you have at least two bottlenecks - one is SQL query (max response size in mySQL) and the second is AJAX (they are passing generated HTML instead of JSON data only, so it wastes bandwidth). For backend we are currently using pagination of results of getAttributeCombinaisons (without searching/filtering of given attribute editing is not easy but who cares...). Frontend is a little bit simpler and we hadn't faced problems here yet. Did you try experiments with memory_usage() / memory limit and set_time_limit?

[mhu100]

For backend we are currently using pagination of results of getAttributeCombinaisons

How do/can we manage this?

[scottyboy]

Wow.
This must be a HUGE problem for thousands of wannabe users of prestashop who have customizable products to sell - and I'm but another number in the huge list!
But we must never forget the fact that this is 'open source' and the volunteers that put their own time and effort into building this amazing free shopping cart can only work on a limited number of projects at any one time.
To re-code the attributes function will be a major task/project for the team. maybe if we all pull together some funds, we could hire a coder to do this for us as I'm sure we would all benefit from being able to use prestashop for our ecommerce solution.

...just my 2 pence worth.

[Martin nl]

i tried it (thomasz solution), now the generator doesn't work anymore, so you'll have to do 2000 or more combinations manually... problem not solved, is it ?

[Camille Frisch]

successfully had FO and BO working with 13000 declinaisons using thomasz fix and pushing memory limit to 128Mo

[ladivito]

by setting memory limit to 128M may make the server overload, so some low spec of hosting is not suitable.

[Camille Frisch]

What would be a reasonable maximum then ? I'm testing the site on localhost for now ...

[tomerg3]

I have just released my Attribute Wizard Pro module which offers a solution for this problem.
See http://www.prestashop.com/forums/viewthread/47363/

[unik]

successfully had FO and BO working with 13000 declinaisons using thomasz fix and pushing memory limit to 128Mo

 

Hello, Mika, I know that this post is two years old but I would like to ask you something. I used the patch from Thomas, like you but I don´t know where to change memory limit to 128M. I did it in config.inc.php but with no luck and I don´t know if there is another place to change.

 

My problem is than if I have 1000 combinations I can´t see the product in FO. The loads fine, categories, heder, footer etc, but not the product.

 

I don´t know what to do now because I tested increase memory at .htaccess file, at php.ini etc with no luck.

 

Please, could you help me.

 

Regards.

[tomerg3]

Many hosts (especially on shared servers) do not allow to change the memory limit.

You should check with them if they allow it or not.

[unik]

Many hosts (especially on shared servers) do not allow to change the memory limit. You should check with them if they allow it or not.

 

Thank you for response Tomerg3, but my host has been told that I can try to change parametres in php.ini, .htaccess or in script. I tried to do except in script with no luck or maybe I don´t do it well. In back office there´s no problem just in front office.

 

I don´t know what else can I try.

 

Regards.

[tomerg3]

You can try to ask them specifically on how to increase the memory limit, and if you can do that...

[unik]

You can try to ask them specifically on how to increase the memory limit, and if you can do that...

 

Yes, I did it and I´m waiting the answer. I know that if I increase the memory in php.ini I need to restart apache but it´s not possible because it´s not my server. About the htaccess file I just insert the line php_value memory_limit 64M but i´m not sure where I must do it exactly and if I must write something else.

 

Regards.

[unik]

Yes, I did it and I´m waiting the answer. I know that if I increase the memory in php.ini I need to restart apache but it´s not possible because it´s not my server. About the htaccess file I just insert the line php_value memory_limit 64M but i´m not sure where I must do it exactly and if I must write something else. Regards.

 

Well my host change php.ini file to memory_limit = 64M; and I´m at the same situation.

In my BO I can create combinations without any problem is just in FO in product page.

I just created a product with 1782 combinations.

If Tomerg3 or anybody can check it this is the link to my product page with the issue.

http://www.mirman.es/servidores/247-zzz.html T

As you can see nothing about the product is showed.

Why all run fin in BO and not in FO?

Any idea?

 

Thanks and regards.

[tomerg3]

It really depends on what else is loaded in the FO, but you will get out of memory errors when you have 1,000-3,000+ combinations, as PS is not handling them very well. Even without the out of memory error, there is a lot of Javascript calculations that are made, which can slow down the page load.

If you turn on error reporting (/config/config.inc.php line #29), you should be able to see the out of memory error.

 

 

You can check out http://www.prestashop.com/forums/index.php?/topic/47363-module-attribute-wizard-pro-create-an-unlimited-number-of-attributes-and-display-as-radio-button-checkbox-dropdown-textbox-teaxtarea-files/ which changes the way combinations are handled and reduces the number of combinations that are needed.

[unik]

It really depends on what else is loaded in the FO, but you will get out of memory errors when you have 1,000-3,000+ combinations, as PS is not handling them very well. Even without the out of memory error, there is a lot of Javascript calculations that are made, which can slow down the page load. If you turn on error reporting (/config/config.inc.php line #29), you should be able to see the out of memory error. You can check out http://www.prestashop.com/forums/index.php?/topic/47363-module-attribute-wizard-pro-create-an-unlimited-number-of-attributes-and-display-as-radio-button-checkbox-dropdown-textbox-teaxtarea-files/ which changes the way combinations are handled and reduces the number of combinations that are needed.

 

Thanks Tomerg3 for your fast reply. At this moment error reporting is "on" but no message is showed, maybe I must wait a long time to see the message "out of memory".

As you say, Javascript can be the reason and in this case I can´t do anything because I don´t know how..

In other way, I´m interested in to buy your module Wizard Pro but I will prefer to send some emails asking you about some questions about it.

 

Thanks again.

[unik]

Thank you Tom, I just bought the module Attribute Wizard Pro.

 

Regards.