Connexion base de données PrestaShop : modifier en toute sécurité

Après une migration d’hébergeur ou un changement d’identifiants, PrestaShop lit toujours ses paramètres MySQL depuis un fichier de configuration – pas depuis le Back Office. Si l’hôte, le nom de la base, l’utilisateur ou le mot de passe ne correspondent plus au serveur, la boutique et l’administration cessent de charger. Ce guide explique comment modifier en toute sécurité la connexion base de données PrestaShop, vider le cache qui peut conserver d’anciennes valeurs, et vérifier les messages d’erreur habituels.

À partir de PrestaShop 1.7 (y compris les versions 8 et 9), les paramètres de connexion base de données PrestaShop se trouvent dans app/config/parameters.php. Les boutiques 1.5 – 1.6 utilisent config/settings.inc.php. La documentation officielle sur ce fichier figure dans la documentation développeur PrestaShop 9 (parameters.php). Des valeurs incorrectes mettent la boutique hors ligne – effectuer une sauvegarde complète de PrestaShop avant toute modification.

Quand modifier la connexion base de données PrestaShop

Modifier ces paramètres est généralement nécessaire lorsque :

• la boutique a été migrée vers un nouvel hébergeur ou un VPS et le fournisseur a fourni un nouvel hôte, un nouveau nom de base, un utilisateur ou un mot de passe ;
• la base a été renommée ou le mot de passe MySQL a été changé dans le panneau ;
• des fichiers ont été restaurés sur un serveur disposant déjà d’une base différente ;
• le front ou le Back Office affiche une erreur de connexion base de données PrestaShop ou d’accès refusé après une migration.

Ne pas modifier ce fichier pour renommer des produits, changer l’e-mail de la boutique ou corriger des URL SEO. Ces actions passent par d’autres écrans. Si la boutique est déjà en ligne et qu’une sauvegarde plus sûre suffit avant une migration, commencer par le guide de sauvegarde lié ci-dessus.

PrestaShop 1.7, 8 et 9 – modifier parameters.php

Pour modifier la connexion BDD PrestaShop sur une boutique récente, utiliser SFTP, SSH ou le gestionnaire de fichiers de l’hébergeur. Travailler sur une copie si possible, puis remplacer le fichier en production en une seule étape.

1. Ouvrir la racine de la boutique et accéder à app/config/parameters.php.
2. Télécharger une copie sur l’ordinateur local (filet de sécurité en cas de retour arrière).
3. Repérer les clés du tableau parameters : database_host, database_port, database_name, database_user et database_password.
4. Remplacer uniquement ces valeurs par celles fournies par le nouvel hébergeur (ou le nouveau mot de passe). Ne pas toucher à database_prefix sauf si chaque préfixe de table a réellement été renommé.
5. Enregistrer et renvoyer le fichier avec les mêmes permissions qu’auparavant.
6. Vider le cache Symfony/PrestaShop (section suivante), puis ouvrir la boutique et le Back Office dans une fenêtre privée.

Les noms d’hôte varient selon le fournisseur : localhost, 127.0.0.1, un nom d’hôte distant, ou parfois un chemin de socket. Copier la chaîne d’hôte depuis le panneau exactement – ne pas deviner. Laisser database_port vide lorsque le panneau ne précise pas de port non standard ; le renseigner (souvent 3306) uniquement si l’hébergeur l’indique.

Exemple de structure (placeholders uniquement – ne jamais coller d’exemples de secrets en production) :

<?php
return array (
  'parameters' =>
  array (
    'database_host' => '127.0.0.1',
    'database_port' => '',
    'database_name' => 'your_database_name',
    'database_user' => 'your_database_user',
    'database_password' => 'your_database_password',
    'database_prefix' => 'ps_',
    'database_engine' => 'InnoDB',
    // … les autres clés restent inchangées - ne pas inventer de nouvelles valeurs secret/cookie
  ),
);

Ne modifier que les clés de base de données fournies. Toucher à secret, cookie_key ou cookie_iv déconnecte tous les utilisateurs et peut casser les sessions – c’est un autre parcours de récupération. Une connexion base de données PrestaShop correcte dans ce fichier ne suffit pas tant que le cache n’est pas vidé (voir ci-dessous).

Vider /var/cache après l’enregistrement

PrestaShop met en cache la configuration compilée. Après modification de la connexion base de données PrestaShop, supprimer le cache sous /var/cache/ – principalement les dossiers dev et prod (et tout autre dossier d’environnement similaire). Supprimer ces dossiers ou leur contenu – pas l’ensemble de la boutique, ni des répertoires sans rapport à côté de var.

Le Back Office fonctionne, mais pas la boutique ? Après un changement de connexion BDD PrestaShop, cette dissociation provient presque toujours d’un cache obsolète – vider var/cache en premier lieu avant d’examiner les thèmes, les modules ou les URL de la boutique.

Les dossiers dev et prod peuvent être volumineux (des dizaines de milliers de petits fichiers). Privilégier le gestionnaire de fichiers de l’hébergeur ou SSH pour les supprimer ou les vider. Un FTP classique parcourt souvent fichier par fichier et peut prendre des heures. Si le FTP est la seule option, renommer prod / dev (par exemple en prod_old / dev_old) pour que PrestaShop recrée immédiatement des dossiers vides, puis supprimer les arbres renommés plus tard lorsque le temps ou un meilleur outil le permet.

1. Depuis la racine de la boutique, ouvrir var/cache/.
2. Supprimer ou renommer prod et dev (et tout autre dossier d’environnement visible).
3. Si l’hébergeur exécute PHP-FPM sous un autre utilisateur, recréer des dossiers prod / dev vides si nécessaire pour que le serveur web puisse à nouveau écrire.
4. Recharger la boutique. Le premier chargement peut être plus lent pendant la reconstruction du cache.

Si Paramètres avancés → Performances est accessible, vider le cache depuis le Back Office est également possible – mais après une mauvaise connexion base de données PrestaShop, la connexion est souvent impossible, d’où l’intérêt du nettoyage au niveau des fichiers.

Si la connexion base de données PrestaShop échoue encore

Parcourir ces vérifications avant de réécrire l’ensemble du fichier :

• Accès refusé. Utilisateur ou mot de passe incorrect, ou l’utilisateur MySQL n’est pas autorisé depuis cet hôte. Réinitialiser le mot de passe dans le panneau et le coller avec soin (pas d’espace superflu ni de guillemets typographiques issus d’une messagerie).
• Base inconnue. database_name ne correspond pas au nom réel du schéma après la migration.
• Impossible de se connecter au serveur. database_host ou port incorrect, pare-feu, ou service de base de données arrêté. Vérifier avec phpMyAdmin ou l’outil MySQL de l’hébergeur en utilisant les mêmes identifiants.
• Préfixe incompatible. Les tables existent mais utilisent un autre préfixe que database_prefix – la boutique se connecte puis apparaît vide ou génère des erreurs de tables manquantes.
• Page blanche / WSOD. Une erreur de syntaxe dans parameters.php (guillemet ou virgule manquant) peut provoquer un écran blanc. Restaurer la copie téléchargée et rééditer. Le guide écran blanc de la mort couvre le mode debug lorsque le fichier est valide mais qu’un autre élément échoue.

Le centre d’aide PrestaShop décrit également ce schéma d’erreur de connexion et les clés à vérifier dans parameters.php – utile lorsque la formulation du panneau diffère : Database connection error for your PrestaShop store.

Anciennes versions PrestaShop 1.5 – 1.6 – settings.inc.php

Si la boutique tourne encore en 1.5 ou 1.6, ouvrir config/settings.inc.php à la place et mettre à jour :

• _DB_SERVER_ (hôte)
• _DB_NAME_
• _DB_USER_
• _DB_PASSWD_

Conserver _DB_PREFIX_ sauf si les tables ont été renommées. Enregistrer, envoyer, puis vider les dossiers de cache utilisés par cette ancienne version (souvent sous cache/). Le même avertissement s’applique : un mauvais mot de passe met la boutique hors ligne – et une connexion base de données PrestaShop incorrecte échouera de la même manière que sur les versions récentes.

Liste de contrôle rapide

1. Sauvegarder les fichiers et la base de données.
2. Modifier la connexion base de données PrestaShop dans app/config/parameters.php (1.7+) ou config/settings.inc.php (1.5 – 1.6).
3. Renseigner hôte, port (si requis), nom, utilisateur et mot de passe conformément au panneau.
4. Vider var/cache (privilégier le gestionnaire de fichiers ou SSH ; renommer en FTP si la suppression prendrait trop de temps).
5. Tester la boutique et le Back Office ; si le Back Office fonctionne mais pas le front, vider à nouveau le cache avant d’examiner d’autres causes. Si les deux échouent, faire correspondre l’erreur à accès refusé / base inconnue / hôte inaccessible avant de modifier d’autres clés.

Une fois la connexion base de données PrestaShop rétablie, finaliser la liste de migration (domaine de la boutique, SSL, e-mail) sur le nouvel hébergeur – les paramètres de connexion seuls ne mettent pas ces éléments à jour.