Problèmes et solutions sous Prestashop

A force de résoudre des soucis, bugs, inconvénients ou problèmes sous différentes versions de Prestashop (et comme je dis souvent que mon cerveau n’est pas une database), j’ai décidé ici de recenser chacun de ces éléments et les solutions que j’ai apporté de manière à les résoudre.

N’hésitez pas à apporter votre contribution en commentaires. Je trierai l’ensemble selon la version de Prestashop, mais cela pourra toucher aussi bien une version qu’une autre, selon le bug rencontré. Toute version non supportée ou suivie par Prestashop ne sera pas abordée.

Si vous désirez disposer d’aide, nous avons développé un module de demande d’aide pour Prestashop, mais vous pouvez très bien passer par notre formulaire de contact.

J’ai positionné le niveau requis de cet article en « Intermédiaire », mais il est évident que selon les soucis rencontrés et leurs résolutions, vous aurez besoin de plus ou moins de compétences en HTML, CSS, Smarty, POO, etc.

Pour chaque erreur rencontrée, il est bon de passer en premier lieu votre Prestashop en mode maintenance, puis d’afficher les erreurs si vous avez droit à une page blanche.

Le but de cet article n’est donc pas de poser vos problèmes depuis les commentaires, mais de lister des solutions utiles afin d’aider la majorité des personnes qui ne trouveraient pas aussi facilement de résolution. N’hésitez également pas à demander sur le forum de Prestashop, qui est suivi par des développeurs et intégrateurs compétents (dont je salue encore à la fois la patience, la persévérance et la diplomatie).

Si vous désirez nous laisser un commentaire sur un problème rencontré, veillez bien à nous fournir la version de PHP et l’erreur rencontrée (donc pas juste « erreur 500 » mais le message qui s’affiche lorsque vous activez les erreurs sur votre site).

Sous Prestashop 1.7, vous pouvez désormais afficher le message d’erreur en vous rendant dans « Paramètres avancés » puis « Performances » pour passer la case « Mode debug » à « Oui ».

N’oubliez jamais de sauvegarder avant toute modification !

Problèmes sous Prestashop 1.6

Atos : impossible d’exécuter les binaires

Rendez-vous sur votre FTP dans /modules/atos et faites un clic droit sur le répertoire /bin. Sélectionnez l’option « droits d’accès aux fichiers » et saisissez la valeur 777, pour tous les fichiers se trouvant dans le répertoire.

Attention aussi au mode d’envoi FTP des fichiers d’un module de paiement ATOS pour Prestashop, vérifiez bien que vous envoyez les fichiers binaires en mode automatique ou binaire, FileZilla peut les corrompre sur un envoi mal configuré. Conservez dans un coin de votre ordinateur les fichiers du module, afin de pouvoir réagir rapidement si le souci se présente (et puis, si vous l’avez eu une fois, ne vous faites pas avoir une seconde fois !)

Le client n’a pas choisi son point relais avec Mondial Relay

En premier lieu, mettez le module Mondial Relay à jour. Installez également le module Ever Mondial Relay disponible gratuitement en cliquant ici.

Vérifiez que vous ne faites pas de double appel à Google Map au sein de votre Search Console, que vous disposez bien d’une clé associée à Google Map, et que votre site ne souffre pas d’erreurs javascript bloquantes dans le tunnel de commande.
Envisagez également le passage à Open Street Map, qui résoudra bon nombre de conflits sur le module de livraison Mondial Relay.

Impossible de traduire les mails d’un module

Vérifiez les droits d’accès au répertoire, et vérifiez que les mails ne soient pas dupliqués à la fois dans le coeur de Prestashop (répertoire /mails) et dans le thème (répertoire /themes/VotreTheme/mails)

Pour modifier les droits d’accès à un répertoire ou un fichier sous Filezilla, faites simplement un clic droit dessus, puis sélectionnez l’option « droits d’accès aux fichiers ». Ces répertoires doivent être en 755, soit donner la possibilité à Prestashop d’écrire dedans. Les fichiers sont généralement en 644. A noter que ces réglages peuvent varier selon votre hébergeur (comme Infomaniak par exemple).

Le prix des déclinaisons passe à zéro

Souci récurrent sur Prestashop 1.6, cela provient de votre thème !

Editez le fichier product.tpl et trouvez la ligne faisant référence à

var group_reduction = '{$group_reduction}';

Et remplacez-la par

var group_reduction = '{1-$group_reduction}';

Un vieux ce bug, connu du forum de Prestashop !

Fatal error: Class ‘PrestaShopAutoload’ not found in /config/autoload.php

Cette erreur provient souvent suite à une mise à jour de Prestashop ou à un upload sur serveur. Un fichier est manquant, tronqué, ou corrompu.

Régulièrement, lorsque je rencontre cette erreur, cela est dû à un upload de fichiers que l’on croit complet, mais qui en réalité sont corrompus, chose difficile à voir (et l’on peut penser à des soucis de droits d’accès aux fichiers).

La solution est des plus simples :

Téléchargez la version de Prestashop correspondant à celle que vous essayez de déboguer. Récupérez les répertoires /classes et /controllers, et réuploadez-les sur votre serveur FTP, avec une bonne connexion et en envoyant les fichiers petit à petit (non d’un bloc ou dix par dix, comme peut le proposer FileZilla). L’idée est de recharger vos fichiers de manière à ce qu’ils soient tous bien en place, complets et non corrompus.

Eventuellement, vérifiez les droits d’accès aux fichiers, mais ceux-ci ne devraient pas bouger. Il n’est pas évident de savoir si un upload est tronqué ou pas, prévoyez deux passes plutôt qu’une, on ne sait jamais.

Bons de livraisons et factures sans produit

Ce problème a été rencontré avec le système de cache par fichier. Lors de l’enregistrement des commandes, il apparaît que parfois, cela génère des latences qui passent les commandes en doublon, à surveiller donc…

Dans le cas présent et expliqué dans le titre, il va falloir corriger une table en base de données. Rendez-vous donc dans PhpMyAdmin et regardez dans la table ps_order_detail.

Basez-vous sur l’identifiant de commande pour trouver celle qui pose souci. Ne manque-t-il pas une valeur dans id_order_invoice ? Allez cherchez cette information dans la table correspondante et ajoutez-là à la table ps_order_detail. Sauvegardez, c’est corrigé !

Impossible de récupérer le média d’une commande personnalisée

Ce bug a été contourné en modifiant le thème admin de Prestashop. En effet, ici le site disposait d’un module autorisant pas mal d’extensions de fichiers (comme .ai pour Illustrator par exemple).

Dans le fichier suivant :

httpdocs/admin/themes/default/template/controllers/orders/_customized_data.tpl

Repérez la ligne suivante :

<div class="col-lg-8"><a class="_blank" href="displayImage.php?img={$data['value']}&name={$order->id|intval}-file{$data@iteration}"> <figure><img class="img-thumbnail" src="{$smarty.const._THEME_PROD_PIC_DIR_}{$data['value']}_small" alt=""></figure> </a></div>

Et remplacez-la par celle-ci :

<div class="col-lg-8"><a class="_blank" href="{$smarty.const._THEME_PROD_PIC_DIR_}{$data['value']}"> <figure><figure><figure><img class="img-thumbnail" src="{$smarty.const._THEME_PROD_PIC_DIR_}{$data['value']}" alt=""></figure></figure></figure> </a></div>

Spam sur le formulaire d’inscription d’un client

Déjà, pour éviter d’avoir à subir des formulaires validés par des bots, nous avions développé et amélioré le module Ever PS Captcha pour Prestashop, permettant ainsi d’utiliser la clé Captcha V3, qui sécurise la totalité de votre boutique. Nous parlions à l’origine du spam sur le formulaire de contact Prestashop ici.

Doekia & Eolia, toujours très présents sur le forum de Prestashop et de bon conseil, ont proposés la correction suivante pour bloquer ce type de spam. Il s’agit simplement de vérifier si le nom ou le prénom du client ne sont pas des URL.

Retrouvez ici leur tutoriel sur le forum de Prestashop.

La boutique de Eolia se trouve ici :
https://eoliashop.com/

Celle de Doekia se trouve là :
https://store.enter-solutions.com/

Editez le fichier /class/Validate.php et ajoutez ceci :

    public static function isCustomerName($name)
    {
        if (preg_match(Tools::cleanNonUnicodeSupport('/www|http/ui'),$name)) {
            return false;
        }

        return preg_match(Tools::cleanNonUnicodeSupport('/^[^0-9!\[\]<>,;?=+()@#"°{}_$%:\/\\\*\^]*$/u'), $name);
    }

Vous pouvez également utiliser un override, ce qui donne ce code :

<?php

class Validate extends ValidateCore
{
    public static function isCustomerName($name)
    {
        if (preg_match(Tools::cleanNonUnicodeSupport('/www|http/ui'),$name)) {
            return false;
        }

        return preg_match(Tools::cleanNonUnicodeSupport('/^[^0-9!\[\]<>,;?=+()@#"°{}_$%:\/\\\*\^]*$/u'), $name);
    }
}

Sauvegardez, et éditez à présent le fichier /classes/Customer.php. Repérez la méthode public static $definition, dans laquelle se trouve la validation des champs.

Par défaut, les variables name et lastname sont vérifiés avec la simple méthode isName, qui ne suffit pas. Remplacez donc ceci :

        'lastname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),
        'firstname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),

Par cela :

            'lastname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isCustomerName', 'required' => true, 'size' => 32),
            'firstname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isCustomerName', 'required' => true, 'size' => 32),

Problèmes sous Prestashop 1.7

Le tableau de bord est bloqué à une date précise

Désinstallez et réinstallez les modules suivants:

• StatsForecast
• Dashtrends
• Statsdata
• DashGoals

Sachez que ce bug survient d’une part lors d’une mise à jour Prestashop qui n’a pas été fiable, ou parce que ces modules ne sont pas à jour.

Je ne dispose plus de la liste des fournisseurs sur une fiche produit en admin

Les tables ps_supplier, ps_supplier_lang, etc, recensent la liste des suppliers d’un Prestashop. Si une seule donnée est en erreur, ou une structure de table modifiée par un tiers, alors non seulement vous rencontrerez des soucis à l’enregistrement de vos fiches produits (tout comme si vous aviez du HTML au sein d’une meta_description) mais également les données affichées seront entièrement en erreur, voire invisibles.

Il est dans ce cas préférable de recréer entièrement ces tables, et de réinsérer proprement les données de suppliers, cela réglera le souci. Sachez que la moindre modification erronée en base de données peut se révéler extrêmement problématique, il est donc essentiel de ne pas y toucher sans avoir une expertise poussée et des compétences avancées en base de données Prestashop.

« Aucun mode de livraison pour l’adresse sélectionnée »

Plusieurs choses à vérifier dans ce cas.

Tout d’abord, vérifiez les pays, qu’ils soient bien actifs, et que le format des adresses soit également proprement renseigné.

Ensuite, remontez jusqu’aux zones. Celles-ci doivent être proprement configurées (rien de compliqué) et surtout actives.

Enfin, finissez par les transporteurs, afin de voir s’ils sont eux aussi bien configurés, qu’il s’agisse des groupes autorisés à y accéder ou des zones, tranches de prix, tranches de poids, etc.

Mes favicons disparaissent à chaque fois

Créez un thème enfant Prestashop 1.7, placez-y dans un répertoire /assets/img les médias que vous pouvez récupérer en téléchargeant une liste complète de favicons ici :

Favicons Generator

Ajouter dans le head de votre site, via le thème enfant, le code suivant :

{block name='head_icons'}
<link rel="apple-touch-icon" sizes="57x57" href="{$urls.img_url}apple-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="{$urls.img_url}apple-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="{$urls.img_url}apple-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="{$urls.img_url}apple-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="{$urls.img_url}apple-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="{$urls.img_url}apple-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="{$urls.img_url}apple-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="{$urls.img_url}apple-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="{$urls.img_url}apple-icon-180x180.png">
<link rel="icon" type="image/png" sizes="192x192"  href="{$urls.img_url}android-icon-192x192.png">
<link rel="icon" type="image/png" sizes="32x32" href="{$urls.img_url}favicon-32x32.png">
<link rel="icon" type="image/png" sizes="96x96" href="{$urls.img_url}favicon-96x96.png">
<link rel="icon" type="image/png" sizes="16x16" href="{$urls.img_url}favicon-16x16.png">
<link rel="manifest" href="{$urls.img_url}manifest.json">
<meta name="msapplication-TileColor" content="#ffffff">
<meta name="msapplication-TileImage" content="{$urls.img_url}ms-icon-144x144.png">
<meta name="theme-color" content="#ffffff">
{/block}

Placez donc tous les médias dans votre thème enfant, dans le répertoire /assets/img/. Pensez à y mettre également un fichier index.php vide, ou un que vous auriez copié d’un répertoire précédent.

Videz le cache de votre site, vous avez fini. De cette manière, vous disposez non seulement de meilleurs favicons que ceux natifs, mais par-dessus le marché ceux-ci ne changeront plus jamais car désormais ils ont beaucoup moins de dépendances avec une interface comme un back-office. Attention au fait qu’idéalement, il faudrait vérifier les favicons qui passent en 404 (chose détectée notamment par l’outil d’auto-404 de notre module de référencement Prestashop Ever SEO)

Google dit que mon thème par défaut n’est pas responsive

Réduisez la taille de votre logo, tout simplement 🙂 Dans la majorité des cas il semble que les logos uploadés sont régulièrement trop gros, mais on ne s’en rend pas forcément compte depuis un ordinateur.

Pensez à vider le cache de votre site et testez à présent sur smartphone. Repérez ensuite en navigant sur les pags de votre site pour bien vérifier si un autre élément ne dépasse pas de la largeur autorisée, il s’agit très souvent de médias.

Aucune méthode de paiement disponible

Dans le cas présent, partons du principe qu’aucune méthode de paiement par carte bleue ne fonctionne, comme Stripe ou Paypal.

Contactez dans ce cas votre hébergeur, il vous manque quelque chose sur votre serveur. Demandez-lui d’activer ou de réactiver l’extension curl_exec, nécessaire pour le bon fonctionnement des modes de paiement par carte en ligne.. Cela devrait résoudre le souci. Réinitialisez intégralement les modules de paiement suite à cela, afin de parer à toute éventualité. Réduire les risques, c’est aussi réduire le débogage, non ?

Une autre solution provient sous Prestashop 1.7 de la nouveauté permettant de restreindre les modes de paiement selon les pays, les transporteurs, etc. Ces options se trouvent dans l’onglet « Paiement » puis « Préférences ». Je me doute qu’il est fastidieux de tout cocher, mais ces options étaient demandées de longue date sur Prestashop, et en un sens répondent par exemple à la problématique qui forçait un développement parfois spécifique, comme ça a été le cas pour le module gratuit de paiement en magasin pour Prestashop.

La propriété Address->id_country est vide

Il s’agit probablement d’une suite de mises à jour que vous avez effectué sur la version 1.7 de Prestashop.

Connectez-vous à votre FTP, et éditez le fichier classes\form\CustomerAddressPersister.php

Repérez la méthode public function save(Address $address, $token) et remplacez-la totalement par ceci :

public function save(Address $address, $token)
{
    if (!$this->authorizeChange($address, $token)) {
        return false;
    }

    $address->id_customer = $this->customer->id;
    $address->save();    // <-- Add this

    if ($address->isUsed()) {
        $old_address = new Address($address->id);
        $address->id = $address->id_address = null;

        return $address->save() && $old_address->delete();
    }

    return $address->save();
}

Validez, le souci est résolu. Ce bug n’apparaît que lors de mises à jour depuis des versions antérieures à la 1.7.4.2

Le téléphone n’est plus obligatoire

Bon là ça n’est pas du tout un bug, mais je peux tout-à-fait comprendre que vous ayez du mal à visualiser où paramétrer cela.

Rendez-vous dans l’onglet « Clients » puis « Adresses », et descendez tout en bas de la liste des adresses affichées. Vous y verrez un bouton « Définir les champs requis pour cette section ». Cliquez dessus pour afficher le formulaire qui permet de préciser quels sont les champs requis. Cochez simplement ceux qui sur votre site doivent l’être et enregistrez, ce qui rechargera la page.

Si vous avez une erreur 500 à ce niveau, contactez le développeur de votre thème, il y a de fortes chances que celui-ci ne soit pas conforme !

[PrestaShopException] la propriété Address->date_add n’est pas valide

Sous Prestashop 1.7, cela signifie que vous utilisez un système de base de données un peu plus performant et récent qu’un simple MySQL, comme MariaDb par exemple.

La donnée de type date avec la valeur ‘0000-00-00 00:00:00’ n’est plus supportée sur les version récentes de MySQL. Pour corriger ça, remplaçons la valeur de date_add par la valeur de date_upd avec une requête SQL :

UPDATE ps_address SET date_add = date_upd WHERE date_add = '0000-00-00 00:00:00'

Pensez à sauvegarder la table au préalable, et validez. Ce souci est désormais corrigé, il provient d’une mise à jour de Prestashop.

Obligé de laisser le mode debug

Typique de Prestashop 1.7, notamment suite à une migration. Ce qu’il faut faire est plutôt simple, mais au préalable il faut veiller à ce que les modules installés soient bien compatibles avec cette version (j’ai notamment rencontré une erreur avec le module whatisthismodule, qui par-dessus le marché se greffait de partout et sortait pas mal d’erreurs bloquantes).

Dans le répertoire /var/cache de votre site, vous devez avoir deux autres répertoires nommés /dev et /prod. Sauvegardez-les puis supprimez-les.

Retournez à présent en back-office et repasser le mode de débogage à false, puis videz le cache. Le ou les répertoires concernés se recréeront tout seuls.

Si les répertoires n’existent pas, ce qui est probablement le cas si vous avez une « vieille » version de Prestashop 1.7, regardez dans le répertoire /app/cache. Sur des versions 1.7.3 de Prestashop, ils s’y trouvent, la procédure demeure la même.

Les messages du SAV dans l’admin ne sont pas en UTF-8

Pour celui-ci, vous allez devoir modifier l’administration de votre site, plus exactement un template.

Celui-ci se trouve dans /admin/themes/default/template/controllers/customer_threads/helpers/view/message.pl

Repérez en fin de fichier la ligne suivante :

<p class="message-item-text">{$message.message|escape:'html':'UTF-8'|nl2br}</p>

Et remplacez-la par ceci :

<p class="message-item-text">{$message.message nofilter}</p>

Enregistrez, c’est fait !

Mon Prestashop est lent !

Bon, là, nous avons carrément un tutoriel à ce sujet. Déjà pensez à supprimer le module gamification qui vous posera plus de soucis qu’autre chose, et pensez à regarder notre tutoriel concernant la vitesse de chargement d’un site Prestashop

Lenteur avec un produit au panier ou sur un ajout au panier

Activez le mode de débogage et rendez-vous dans votre interface d’administration dans les paniers. Tout cela sent à plein nez la grosse mise à jour 🙂

Videz les paniers, tout simplement, ou recréez manuellement les adresses manquantes (et qui sont liées au panier sous Prestashop 1.7)

Afin d’éviter trop de soucis, privilégiez la suppression de paniers jusqu’à un an et demi, voire deux ans en arrière, pour des raisons de données et de comptabilité.

Il existait un module de suppression de paniers sur d’anciennes versions de Prestashop, personnellement je le trouve super intéressant à partir du moment où il n’entre pas en contradiction avec la célèbre loi RGPD pour e-commerce. Si quelqu’un en détient une vieille version, je suis plutôt pour l’adapter et ne pas partir de zéro, contactez-nous si tel est votre cas !

Le total des remises (règles paniers) est TTC :

Pour ce coup, il va falloir créer un override de la class Cart. Par défaut, Prestashop affiche la réduction issue d’une remise avec un calcul de taxes, alors que celle-ci devrait s’appliquer sur le montant hors taxes du ou des produits

Afin de corriger cela, ajoutons un fichier d’override Cart.php dans le répertoire /override/classes de votre Prestashop 1.7

Voici le code à insérer dedans :

/**
 * Override CartCore
 */
class Cart extends CartCore
{
    /**
     * @return float
     */
    public function getDiscountSubtotalWithoutGifts()
    {
        $discountSubtotal = $this->excludeGiftsDiscountFromTotal()
            ->getOrderTotal(false, self::ONLY_DISCOUNTS);
        $this->includeGiftsDiscountInTotal();

        return $discountSubtotal;
    }
}

Validez le tout et pensez à vider votre cache. Le total des remises est à présent HT.

Fatal error: Class ‘Tools’ not found

Ce souci se présente aussi parfois sous Prestashop 1.6, la solution est peu ou prou la même

Sous Prestashop 1.6, renvoyez les fichiers du répertoire /classes via FTP, supprimez le fichier cache/class_index.php, et videz votre cache.

Sous Prestashop 1.7, commencez également par renvoyer le contenu du répertoire /classes depuis une base saine, téléchargée depuis le site de Prestashop.

Par la suite, supprimez intégralement le contenu du répertoire /var/cache. Videz ensuite le cache depuis l’administration de votre boutique.

Fatal error allowed memory size sur CategoryDataProvider

Éditez le fichier /httpdocs/src/Adapter/Category/CategoryDataProvider.php changez la méthode getBreadCrumb et repérez la méthode suivante :

    /**
     * Construct the breadcrumb using the already constructed list of all categories.
     *
     * @param int $categoryId
     * @param string $delimiter
     *
     * @return string
     */
    public function getBreadCrumb($categoryId, $delimiter = ' > ')
    {
        $categories = $this->getParentNamesFromList($categoryId);
        $categories = array_reverse($categories, true);

        return implode($delimiter, $categories);
    }

Nous allons simplement désactiver le fil d’ariane des catégories en back-office.
Ce qui nous donne à présent ceci :

    /**
     * Construct the breadcrumb using the already constructed list of all categories.
     *
     * @param int $categoryId
     * @param string $delimiter
     *
     * @return string
     */
    public function getBreadCrumb($categoryId, $delimiter = ' > ')
    {
        return false;
        $categories = $this->getParentNamesFromList($categoryId);
        $categories = array_reverse($categories, true);

        return implode($delimiter, $categories);
    }

Commande payée mais non validée depuis un module

Le souci provient du module. Celui-ci a un fichier validation.php qui est totalement hors contexte Prestashop. Ce problème Prestashop a surgi sur la version 1.7.6.

Il faut savoir que le fait de disposer d’un tel fichier est plus que non recommandé, ce depuis Prestashop 1.5. Il va donc falloir l’adapter, ou racheter le module en contactant le développeur afin d’être certain que ce dernier a bien rendu son module conforme.

Sinon, vous pouvez appliquer un « pansement » au fichier, ce n’est pas l’idéal mais le « fix » fonctionnera, notamment sur le module CIC de Ta Boutique Web. Nous ne reproduisions pas le bug sur notre propre module de paiement Monetico-CIC, car celui-ci est totalement conforme aux prérequis de Prestashop.

Au plus haut du fichier de validation.php de votre module, ajoutez ceci :

<?php
/* Fix 1.7.6 context */
$controller = new FrontController();
$controller->init();

Context::getContext()->controller = $controller;

Ainsi, vous aurez appliqué le contexte de Prestashop (le controller surtout) au module, ce qui le rendra opérationnel. Notez bien cependant que le module devra être intégralement mis à jour et adapté, et dans le cadre d’un paiement Monetico-CIC, il vous faudra également contacter le CIC de manière à ce que – suite à la correction du module et en conséquence modification des URL CGI – ceux-ci fassent la modification sur leur interface. Nous avons à ce sujet un tutoriel de mise en place d’un mode de paiement Monetico-CIC pour Prestashop.

An exception occured in driver (…) Access denied for user

Nous avons constaté ce problème sur une récente installation de Prestashop 1.7. Toute l’installation s’était pourtant bien déroulée, mais lors de la première tentative de connexion à l’administration de la boutique, erreur 500 avec ce message :

An exception occured in driver: SQLSTATE[HY000] [1045] Access denied for user 'demops'@'localhost' (using password: YES)

La solution s’est révélée très simple : il faut simplement remettre au propre le mot de passe de la base de données dans le fichier /app/config/parameters/parameters.php. Dans le cas présent, certains caractères spéciaux avaient été réécrits. Dans le doute, recontrôlez les informations de connexion à la base de données pour résoudre le problème sur votre Prestashop.

 Imprimer