Slow loading times of BO page "Price Catalog Rules" due to full smarty cache clear at every load

[gennaris]

Prerequisites

• [X] I understand and accept the project's code of conduct
• [X] I have already searched in existing issues and found no previous report of this bug.

Describe the bug and add screenshots

If you have a lot of smarty cache , backoffice "Price Catalog Rules" page loading time can take a lot of time or timeout the page due to Tools::clearSmartyCache(); being called :

    public function postProcess()
    {
        Tools::clearSmartyCache();

        return parent::postProcess();
    }

in: controllers/admin/AdminSpecificPriceRuleController.php

This method is called during page load and / or when submitting modifications.

This sounds nosense to me, I don't see a good reason to clear the smarty cache when loading a BO controller.

Expected behavior

Unless I'm missing something, BO Page loading should not be affected by front office smarty cache clear

Steps to reproduce

1. Fill your shop with a lot of smarty cache (difficult part 😀)
2. Go on Catalog > Discounts > Catalog Price Rules
3. See the operation takes a lot of time as the folders var/cache/prod/smarty/cache and var/cache/prod/smarty/compile are getting totally wiped before the load of the page.

PrestaShop version(s) where the bug happened

1.7.8.7

PHP version(s) where the bug happened

7.4

If your bug is related to a module, specify its name and its version

No response

[Hlavtox]

It was added in this commit, but god knows why :D https://github.com/PrestaShop/PrestaShop/commit/2556d64f6e1cfd636dc4152dadc7ff61c5433cd7

[AureRita]

Hi @gennaris

Thank for your report, This issue is too technical for me, ping @PrestaShop/prestashop-core-developers, can someone please reproduce this issue ?

Thanks

[ghost]

Hello @AureRita

https://user-images.githubusercontent.com/5064590/184079998-28162ce2-98a6-41b3-a1f2-6af26da283dc.mp4

[AureRita]

Thank you @okom3pom ,

Now I see where the issue come. For me, yes, we have to withdraw this part of code, because it haven't to be here, but currently I'm not a developper and I don't know if it correct maybe some issue with cart rules. So we just have to wait them, sorry

[ghost]

We could replace it by :arrow_down: to keep the cache removal because cart rules is cart rules :rofl:

    public function processAdd()
    {
        Tools::clearSmartyCache();

        return parent::processAdd();
    }

    public function processUpdate()
    {
        Tools::clearSmartyCache();

        return parent::processUpdate();
    }  

let's wait for a dev :)

[ghost]

@AureRita good news

I asked if a committer could validate an issue with the label Waiting for dev

It's ok

[FabienPapet]

I think the the cache "needs" to be cleared for frontend if you add / update / remove rules to avoid issue with outdated data for customers.

@okom3pom 's solution looks ok for me (did not tested), if we handle correctly add / update / delete, then I think this code can be removed from postProcess

[gennaris]

@okom3pom solution only partially mitigates the problem, now the cache is not cleared when the page loads but it does after a cart rule save/update action, resulting in the same issue (in the case of my customer he generates GB of smarty cache every day).

From my verifications it does not make any sense to perform a Tools::clearSmartyCache(); at all after a backoffice action, the only change caused by a cart rule editing action are product prices, but even commenting out the line and applying a cart rule, I find that the product prices at front office are immediatly OK so I assume they are not cached - maybe back in the days of PS 1.4 (when commit was introduced) there was a need to do it for other unknown reasons ?

[ghost]

I agree, the possible impact is the cache of the modules ( ps_specials for example ) and normally they are hook on updateProduct to clear the cache.

And when a specific price expires there is no cache cleaning :interrobang:

But PrestaShop cart rules are on the dark side of the force.

[Gipielle]

Thank you @gennaris for report, i also have this problem in many ps versions