Fixing the Extreme Load Time When Creating a New Product in PrestaShop 1.7.8.10: A Simple Code Replacement to Avoid a Heavy SQL Query That Slows Down Everything

F

Fixing the Extreme Load Time When Creating a New Product in PrestaShop 1.7.8.10: A Simple Code Replacement to Avoid a Heavy SQL Query That Slows Down Everything

If you are running PrestaShop 1.7.8.10 and you have a database with a huge number of products, let’s say 600,000 products or more, and you try to add a new product in the Back Office, but suddenly you notice that your SQL server is under extreme load and everything slows down to the point that the new product page takes forever to open, then you might be facing a serious issue caused by a badly written SQL query, a query that someone thought was a great idea but in reality, it is causing massive performance problems by trying to determine the most used tax rule group by scanning the entire database in an extremely inefficient way, a method that simply does not scale when dealing with large product databases, and the worst part is that this query is executed every single time you try to open the product creation page, making the experience painfully slow and completely unacceptable for any serious e-commerce store running a large catalog.

πŸ”Ž Understanding the Problem: The Query That Slows Everything Down

The issue is caused by the following SQL query that is executed when you open the new product page in the PrestaShop Back Office:

SELECT
  id_tax_rules_group
FROM (
  SELECT
    COUNT ( * ) AS n,
    product_shop.id_tax_rules_group
  FROM
    ps_product p
  INNER JOIN
    ps_product_shop product_shop
  ON
    ( product_shop.id_product = p.id_product
      AND product_shop.id_shop = ? )
  JOIN
    ps_tax_rules_group trg
  ON
    ( product_shop.id_tax_rules_group = trg.id_tax_rules_group )
  WHERE
    trg.active = ?
    AND trg.deleted = ?
  GROUP BY
    product_shop.id_tax_rules_group
  ORDER BY
    n DESC
  LIMIT
    ? ) most_used
LIMIT
  ?;

Now, let’s take a moment to reflect on what this query is actually doing: it tries to calculate the most frequently used tax rule group in the entire product database, meaning it scans all 600,000+ products, groups them by tax rule group, counts how many times each tax rule has been used, sorts them in descending order, and then selects the one that has been used the most, which might sound like a smart idea in a small store with just a few hundred products, but in a real-world e-commerce environment where you have hundreds of thousands of products, this approach is simply unacceptable because it forces MySQL to perform an incredibly expensive operation just to retrieve a tax rule, something that should be almost instant.

πŸ’₯ Who Thought This Was a Good Idea?

Seriously, the person who wrote this must have thought that the best default tax rule for a new product should be the most frequently used one, and while that may sound logical in theory, in practice, this approach is a performance disaster, because instead of setting a simple default value based on the store’s country tax settings or allowing the merchant to define a default tax rule manually, this query puts the entire SQL server under unnecessary load, making the PrestaShop Back Office almost unusable whenever a new product is created, and considering that PrestaShop is used by many stores with large product catalogs, this issue affects a lot of people who simply want to create a product quickly without waiting minutes for the page to load.


πŸ› οΈ The Solution: Stop Running That Query and Use a Simple Default Value Instead

The easiest way to fix this issue is to replace the function that generates this slow query with a simple default value, avoiding the unnecessary database query entirely and ensuring that the product page loads instantly without putting any pressure on the MySQL server.

πŸ“ The Fix: Edit classes/Product.php

To apply this fix, open the file:
πŸ“‚ classes/Product.php

Find the function:

public static function getIdTaxRulesGroupMostUsed()

Replace the entire function with this:

public static function getIdTaxRulesGroupMostUsed()
{
    // Avoid querying the database for the most used tax
    return 1; // Replace '1' with the default tax rule ID for your store
}

This simple change will completely bypass the slow query, and instead of scanning the entire database, it will just return a default tax rule ID, which is much faster and makes the new product page load instantly.


βœ… The Result: A Faster Product Creation Page

By making this simple change, you will notice immediate improvements:
– πŸš€ The new product page loads instantly instead of taking an extreme amount of time.
– πŸ”₯ The MySQL server no longer suffers from unnecessary heavy queries.
– ⚑ Your PrestaShop Back Office becomes more responsive, improving the overall user experience.
– βœ… You still have a valid tax rule, either a default one (1) or the one set in PS_TAX_RULES_GROUP_DEFAULT.


πŸ”š Conclusion: Fixing Bad Code Decisions for a Better PrestaShop Experience

This issue is a classic example of a poorly optimized query that might have worked for small stores but completely fails in large-scale e-commerce environments, and while it’s understandable that developers sometimes try to automate things, running a heavy SQL query to determine a tax rule is simply not acceptable, so by applying this fix, we can avoid unnecessary database stress, improve performance, and make the PrestaShop Back Office much more efficient, ensuring that merchants can create new products quickly and without frustration.

If you are using PrestaShop 1.7.8.10 and you experience slow loading times when adding a new product, I strongly recommend applying this fix right away, because it will save you a lot of time and make your store run much smoother, and if you need more customization, you can always modify the function to fetch the correct tax rule dynamically, but please, avoid that terrible SQL query at all costs.

πŸš€ Enjoy a faster PrestaShop experience! πŸš€


Let me know if you want any further refinements or additions! πŸš€πŸ”₯

About the author

Avatar photo
Matteo Lavaggi