Prestashop Combinations Suck 11


There are a lot of great features with Prestshop, but as of version 1.1 their idea of product options and values, attributes, or combinations (whatever you want to call them) is not good.  If you have five or six different options with four or five option values each, you cannot use this solution.  Why?  Let me show you….

Use the “generator” to assign attributes to a product.  Below is the full screenshot of all the attributes assigned so far.  Notice the green box at the top that says “4900” products created.  I don’t know why they call it “products” b/c it’s really some sort of product/attribute combination.

untitled-1

The attribute tables in the database contain a ton of records!

db-1

Add another option with two values.

untitled-31

And the table record counts jump to 9800 and 58802!  How the can this be?  I only added one more option and two values?!?!

db-2

Add one more option value and things go boom.  It’s broke.

untitled-4

The database says…

db-3

What happened?  Prestashop was successful at increasing the number of rows in the product attribute table again by 50%, but when it tries to insert 117,000 records into the product_attribute_combination table things don’t work.

I used my debugger and stepped though the code in of the generator page in attempt to figure out the problem.  The code loops through all the records and builds an array of objects with 18 properties each for all the combinations, except that the array contained well over 100000 objects!  This took forever and locked up my machine.  Additionally, when you have this many combinations, the product detail page that the customers use takes about 15 seconds to load.

Why would you attempt to store every possible combination of a product and all its options and all its values in the database?????  This is not using a relational database as it is supposed to be used!  You build relationships, not just store data!  Prestashop is great in many ways and “had” a lot of potential… until this.  Prestashop product combinations suck!


Leave a comment

Your email address will not be published. Required fields are marked *

11 thoughts on “Prestashop Combinations Suck

  • friend

    Thanks for sharing what you uncovered… now hurry up and fix it and share the details of the fix, eh?

    attributes (or “whatever ya call them” as you mentioned) require a hairy bit of coding logic, unless…

    just stick a field in the products table to store a “product is attribute-ized” boolean flag & build the attributes into a separate table, using productID as a foreign key?

    Perhaps within the attributes table, an overriding flag could indicate (where appropriate) that the merchant wishes a given attribute to be applied “globally” to every product in his catalog?

    I’m thinking along these lines, because concepts of attributes vs “attribute sets” vs “product types” are such a PITA to develop around.

    Recently, while reviewing various cart apps, I noticed that one of them provided a means of “templating” (not quite “clone this product”) — merchant can setup/save various partially-populated “new product form” sets. This approach seems pretty slick, and although I didn’t examine the underlying code, I doubt it relies on creation of additional “product types”.

    On the other hand (regarding “types”), instead of wrestling around the notion that “every product details page displays a PRODUCT”… I’m considering (considering toying with) the drupal-ish approach, where *a* product page would be treated as a node type, and numerous interchangeable node templates could be swapped in/out, elected for each product by the merchant where the default “type of presentation node” layout, or content, isn’t desired.

    For the above, I think the approach utilized by CMS app “Silverstripe” (I’m a bit foggy on the specifics) would be well-received. Once a dev (or savvy user) creates a node type definition, the UI enables further customization of a node — drag-n-drop rearrangement of defined content blocks and choice of which blocks to display. Somehow, you would need to limit which saved “presentation node types” could be selected for a given product, though. Otherwise, not only would the user be overwhelmed by too many choices, some would be inappropriate (like a presentation node specially created to accomodate display thumbnails of both left/right handed product variants.) Um, not a great example, but anyhow…

    A few minutes ago, I read someone’s defense (defensive response) regarding Magento. In my trial use this past week, it is BUGGY. Telling me that it’s a great platform doesn’t sway me, nor am I favorably impressed to hear claims that it’s a “wonderful, scalable, enterprise-level solution”. Buggy is the immediate, overriding, consideration.

    Zen cart:
    OMG, how many hours did I spend (waste) a year or so back, wrestling with its spaghetti? They have a lot of gall professing how “easy” it is to configure/customize. I took a look at the latest version this week, and quickly noted which addons I would expect to install in order to bring its featureset to a “reasonable” usable state for me… and threw up my hands at reading the “readme” very first (and only) l’il mod I downloaded to test. INSANITY — it dictated manual SQL queries to be run against the cart db *and* instructions for manually editing core files… in order to get the mod to work. Yeah, I could have followed the instructions… buy WHY?!?

    Why, indeed. I guess the market for Linda’s “essential” zencart howto book has dried up… so, after eons (in internet time) the zen team is now (maybe, this year) going to release a new MAJOR point version of the app. Throw away yer existing templates boy and girls; chuck all them dozens of extensions you’ve come to rely upon… they’re all GUARANTEED to be imcompatible with the new version. Yeah, it’s amazing the bullcrap users put up with, in their pursuit of using a “free” app.

    Above, the ranting just serves to provide background and underscore the point that I’ve “been around the block”. I’m neither a staunch advocate of OOP nor MVC design, and I loathe back-and-fro overlays (css/templates in general, Smarty in particular)… and I believe that currently, Prestashop is the best cart platform to build against.

    I’m a bit distressed to note how many “sharks” are out, *selling* templates/mods for Prestashop — that doesn’t bode well for the platform, IMO. If it’s so friggin complicated that you need to hire a consultant to effect customizations of your installed app… then it doesn’t ACTUALLY qualify as a “free” platform et the end of the day, does it?

    Also distressing — seeing the Prestashop devs berate, slam, strongarm (use your own interpretation) forum users who have requested CAPTCHA functionality. “Oh, that leads to cart abandonment.” No, that’s not a good sign — users are stating (repeatedly) a very real need, and the devs are oblivious.

  • Agouti

    Prestashop’s implementation of attributes is valid, and perhaps even favourable in a limited range of uses: For example, a clothes shop. Because each combination of attributes (Blue, small) is a unique product in the store it gives a much more powerful stock management capability.

    However.

    The way prestashop currently does the submitting of attributes – ie, how the choice makes it from the UI to the back end – is the worst possible way of doing it. Literally.

    As of the latest version (26/9/09) the way it works is via javascript; whenever you make a selection from the dropbox, it uses javascript, which then, via a pair of JOIN’s in a database query, works out the ID of the attribute combination. It then writes that into a hidden field, to be submitted when you buy the product.

    Oh, and there is no backup system in case the javascript dies – which it has on both occasions I’ve used this cart.

    What possible reason did the devs have for doing it this way? The exact same code, written in PHP, could of pulled the id out when the cart was being updated, and it would only have needed to be executed once.

    Doubtless it has something to do with some fancy JS/AJAX based cart addition, but even then it should still have been done in PHP via a AJAX call, or at the very least had backup code incase the JS didn’t work.

  • Dmitry

    Speaking of PS. It’s BUGGY too. Latest production 1.2.5.0 release generates 499 database queries on a single click on product category. Now, that’s what is called “Lightning fast” on their web site. The main advantage of PS as I see it from my little corner (tried OfBiz, Oscommerce, Magento) are these:

    – Close following on real commerce business model. Try to find Manufacturer link on admin panel on competitors!
    – Modules
    – Nice UI, not just boxed HTML, but CSS driven templates.
    – Back office is intuitive and consistent.

    But downside is PS definetely has some critical bugs mentioned in this blog and they are serious to stop planning to use it in production.

  • latorante

    Hi there guys, was having a same problem with import of combinations, was puzzling my head … buecase seriously, no1 can create import file with all possible combinations … so I told my client to create it in certain way and then I wrote a script, that creates special combinations.csv file to import with all possible combinations … and recently I decided to make it public as well.

    have a look:
    http://tools.latorante.name/prestashop-combinations-generator

  • vitaliy

    Hi
    Maybe somebody my fix will help. This reduce memory usage in 5 times.
    Product::getAttributeCombinations()

    Original code
    $res = Db::getInstance()->executeS($sql);

    //Get quantity of each variations
    foreach ($res as $key => $row)
    {
    $cache_key = $row[‘id_product’].’_’.$row[‘id_product_attribute’].’_quantity’;

    if (!Cache::isStored($cache_key))
    Cache::store(
    $cache_key,
    StockAvailable::getQuantityAvailableByProduct($row[‘id_product’], $row[‘id_product_attribute’])
    );

    $res[$key][‘quantity’] = Cache::retrieve($cache_key);
    }

    return $res;

    Change to

    $res = Db::getInstance()->query($sql);

    $data = array();
    //Get quantity of each variations
    $key = 0;
    while($row = Db::getInstance()->nextRow($res))
    {
    $cache_key = $row[‘id_product’].’_’.$row[‘id_product_attribute’].’_quantity’;

    if (!Cache::isStored($cache_key))
    Cache::store(
    $cache_key,
    StockAvailable::getQuantityAvailableByProduct($row[‘id_product’], $row[‘id_product_attribute’])
    );
    $row[‘quantity’] = Cache::retrieve($cache_key);
    $data[] = $row;

    $key++;
    }

    return $data;

  • Sandro

    I have a website with many products exposed, and with prestashop I got some products in specific with many combinations. In Attributes & Values I added all the possible combinations to these products. With this, at my site it should only be possible to view the correct combinations right?

    For example, one of my products is a shirt. It has 2 attributes & values possible:
    Yellow shirt with squares
    Red shirt with triangles

    Yet, at the site I still can realize the combination of “red with squares”, and it shouldn’t be possible. What should I do?

  • pow

    This “bug” drives me crazy!!
    My client has a jewelery shop, and now he has a products with ~6500 combinations. The shop needs about 15-40 seconds to load.

    Even the worst shop he has came from, had a better combination coding.

    What is the fix? I had to use prestashop 1.4, because 1.5 could not handle the combinations in the backoffice.

    What a shame!