This is what my client discovered in the early morning at her PrestaShop store a few days before Christmas.
She was right to contact me quickly to solve her problem.
So I immediately activated the Debug mode to discover where the problem was to block his PrestaShop shop.
And this is what I discovered.
So I go on my favorite browser to find the web page giving the solution to this problem which, because of the advanced age of PrestaShop, had to be met by a lot of people.
Imagine, the concern is presented by a lot of people, but I haven't found a solution. So I had to go through the usual investigations.
I checked the tale structures of the ps_shop, ps_shop_url and ps_configuration database with the value of PS_SHOP_DEFAULT and everything was fine.
I'm having fun deleting the famous cache/class_index.php file without any more results.
And there I venture into.htaccess, I check the dates of the files on the FTP, I check the.ovhconfig file since my client is at this host, but still nothing.
So I start analyzing the configuration files in the config directory and reading the settings.inc.php file (we are on version 1.6 of PrestaShop) I test a very simple thing, I pass to 0 the define('_PS_CACHE_ENABLED_','0') line; because, this line, must never be activated since it activates the Cache options at the bottom of the Performance backoffice page and that we have always known that PrestaShop is unable to properly control all the cache proposals here present.
The site is working again.
The moral of this story is that you should never, ever, ever activate the Cache option at the bottom of the Performances in PrestaShop Backoffice page.