Installation et configuration

Comprendre les permissions de fichiers Linux

Chaque fichier et répertoire sur un serveur Linux possède trois ensembles de permissions : un pour le propriétaire, un pour le groupe, et un pour les autres (tous les autres utilisateurs). Chaque ensemble contrôle trois actions : lecture (r), écriture (w), et exécution (x). Ces permissions sont représentées numériquement en notation octale, où la lecture vaut 4, l'écriture vaut 2 et l'exécution vaut 1. Les valeurs sont additionnées pour chaque ensemble, produisant un nombre à trois chiffres comme 755 ou 644.

Par exemple, une permission de 755 signifie que le propriétaire peut lire, écrire et exécuter (7 = 4+2+1), tandis que le groupe et les autres ne peuvent que lire et exécuter (5 = 4+0+1). Une permission de 644 signifie que le propriétaire peut lire et écrire (6 = 4+2+0), tandis que le groupe et les autres ne peuvent que lire (4 = 4+0+0). Comprendre ce système est fondamental pour gérer une boutique PrestaShop sécurisée et fonctionnelle.

Au-delà des permissions numériques, chaque fichier a un propriétaire et un groupe qui lui sont associés. Sur un serveur web, le processus du serveur web (Apache ou Nginx) s'exécute sous un utilisateur spécifique, généralement www-data sur Debian/Ubuntu ou apache/nobody sur CentOS/RHEL. Le serveur web a besoin de lire vos fichiers PrestaShop pour les servir, et il a besoin d'un accès en écriture à certains répertoires pour les téléchargements, la mise en cache et la configuration.

Permissions correctes pour les répertoires et fichiers PrestaShop

La règle générale pour PrestaShop est simple : les répertoires doivent être en 755 et les fichiers en 644. Cela donne au propriétaire un contrôle total, tandis que le groupe et les autres peuvent lire (et exécuter/traverser dans le cas des répertoires) mais ne peuvent rien modifier. L'utilisateur du serveur web doit être le propriétaire de tous les fichiers PrestaShop, ou au minimum appartenir au groupe qui les possède.

Pour définir ces permissions sur l'ensemble de votre installation PrestaShop, connectez-vous à votre serveur via SSH et exécutez :

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Remplacez /var/www/html/prestashop par le chemin réel de votre installation PrestaShop. La première commande trouve tous les répertoires et les met en 755. La seconde trouve tous les fichiers et les met en 644.

Cependant, certains répertoires nécessitent un accès en écriture par le serveur web. Ces répertoires demandent une attention particulière car PrestaShop y écrit pendant son fonctionnement normal :

/var/cache/ — Templates Smarty compilés et cache Symfony
/var/logs/ — Fichiers de journalisation de l'application
/upload/ — Fichiers téléchargés par les clients
/download/ — Fichiers de produits virtuels
/img/ — Images produits, images de catégories, images CMS
/modules/ — Installation et mises à jour des modules
/themes/ — Fichiers de cache du thème
/translations/ — Fichiers d'export de traductions
/config/ — Fichiers de configuration (parameters.php)
/app/config/ — Configuration Symfony
/app/Resources/translations/ — Traductions Symfony

Si l'utilisateur du serveur web est le propriétaire de ces fichiers (ce qui est la configuration recommandée), alors les permissions 755/644 sont suffisantes. Si le serveur web s'exécute sous un utilisateur différent, vous devrez peut-être ajuster les permissions de groupe ou la propriété.

Définir la bonne propriété avec chown

La propriété est tout aussi importante que les permissions. La commande chown modifie le propriétaire et le groupe des fichiers. Pour un serveur Debian/Ubuntu typique exécutant Apache ou Nginx, l'utilisateur du serveur web est www-data :

sudo chown -R www-data:www-data /var/www/html/prestashop

Le flag -R applique le changement récursivement à tous les fichiers et sous-répertoires. Sur les systèmes CentOS ou RHEL, remplacez www-data par apache ou nginx selon votre serveur web.

Une approche alternative courante consiste à définir le propriétaire comme votre utilisateur SSH/FTP et le groupe comme l'utilisateur du serveur web. Cela vous permet de modifier les fichiers via FTP ou SSH tout en permettant au serveur web de les lire :

sudo chown -R votreutilisateur:www-data /var/www/html/prestashop

Dans ce cas, les répertoires nécessitant un accès en écriture par le serveur web doivent être mis en 775 (écriture de groupe) et les fichiers accessibles en écriture en 664 :

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Hébergement mutualisé vs VPS vs Serveur dédié

L'environnement d'hébergement affecte considérablement le fonctionnement des permissions de fichiers en pratique. Comprendre les différences est essentiel pour configurer correctement les permissions.

Hébergement mutualisé

Sur un hébergement mutualisé, vous accédez généralement aux fichiers via FTP ou un gestionnaire de fichiers dans cPanel/Plesk. Le modèle d'exécution PHP varie selon l'hébergeur, mais la plupart des hébergeurs mutualisés modernes utilisent PHP-FPM ou suPHP, ce qui signifie que PHP s'exécute sous votre compte utilisateur plutôt que sous l'utilisateur global du serveur web. Cela simplifie considérablement les permissions : puisque PHP s'exécute sous votre utilisateur, il peut déjà lire et écrire dans vos fichiers avec les permissions standard 755/644. Vous avez rarement besoin de changer la propriété sur un hébergement mutualisé car tout appartient déjà à votre compte.

Si vous rencontrez des erreurs de permissions sur un hébergement mutualisé, vérifiez auprès de votre hébergeur s'il utilise suPHP ou PHP-FPM. S'il utilise l'ancien modèle mod_php, vous devrez peut-être mettre temporairement certains répertoires en 777 (bien que cela ne soit pas recommandé pour des raisons de sécurité). La plupart des hébergeurs réputés ont abandonné mod_php précisément en raison de ces complications de permissions.

VPS (Serveur Privé Virtuel)

Sur un VPS, vous avez un contrôle total. C'est la configuration la plus courante pour les boutiques PrestaShop sérieuses. Vous devez vous assurer que l'utilisateur du serveur web possède les fichiers PrestaShop ou, au minimum, appartient à un groupe ayant un accès en lecture. La configuration recommandée est :

Définir le propriétaire en www-data:www-data (ou votre utilisateur de serveur web)
Utiliser 755 pour les répertoires et 644 pour les fichiers
Utiliser SSH avec sudo pour effectuer des modifications, ou ajouter votre utilisateur SSH au groupe www-data

Pour ajouter votre utilisateur SSH au groupe du serveur web :

sudo usermod -a -G www-data votreutilisateur

Puis définissez le bit d'écriture de groupe sur les répertoires que vous devez modifier :

chmod g+w /var/www/html/prestashop/themes/votre-theme/

Serveur dédié

Les serveurs dédiés suivent les mêmes principes que les configurations VPS. La principale différence est la performance : vous disposez de plus de ressources, ce qui vous permet d'exécuter PHP-FPM avec des pools dédiés par site. Chaque pool peut s'exécuter sous un utilisateur différent, offrant une meilleure isolation si vous hébergez plusieurs boutiques PrestaShop sur le même serveur.

Modèles d'exécution PHP : suPHP vs mod_php vs PHP-FPM

La manière dont PHP est exécuté sur votre serveur détermine directement quel utilisateur écrit les fichiers et donc quelles permissions sont nécessaires.

mod_php (module Apache)

C'est le modèle le plus ancien et le plus simple. PHP s'exécute comme partie intégrante du processus Apache, ce qui signifie que tout le code PHP s'exécute sous l'utilisateur Apache (généralement www-data ou apache). Le problème est que les fichiers créés par PHP (cache, téléchargements, etc.) appartiennent à l'utilisateur du serveur web, pas à votre compte. Cela peut rendre la gestion FTP difficile et crée des préoccupations de sécurité sur les hébergements mutualisés car tous les sites s'exécutent sous le même utilisateur.

Avec mod_php, les fichiers PrestaShop doivent appartenir à l'utilisateur Apache, et les permissions 755/644 fonctionnent correctement. Cependant, ce modèle est largement obsolète sur les serveurs modernes.

suPHP

suPHP exécute PHP en tant que propriétaire du fichier plutôt qu'en tant qu'utilisateur du serveur web. Cela signifie que si vos fichiers appartiennent à votreutilisateur, PHP s'exécute également sous votreutilisateur. C'est plus sécurisé sur l'hébergement mutualisé car chaque compte est isolé. Les permissions standard 755/644 fonctionnent parfaitement avec suPHP car le processus PHP et le propriétaire du fichier sont le même utilisateur.

Un point important à noter : suPHP rejette en fait les fichiers avec des permissions 777 ou les fichiers appartenant à d'autres utilisateurs. Si vous mettez 777 sur un serveur suPHP, PHP refusera d'exécuter ces fichiers, affichant à la place une erreur 500 Internal Server Error.

PHP-FPM (FastCGI Process Manager)

PHP-FPM est le standard moderne. Il exécute PHP comme un processus séparé du serveur web, avec un utilisateur/groupe configurable par pool. Sur un VPS, PHP-FPM s'exécute généralement sous www-data. Sur un hébergement mutualisé avec CloudLinux ou similaire, chaque compte obtient son propre pool PHP-FPM s'exécutant sous l'utilisateur de ce compte.

PHP-FPM combiné avec Nginx est la configuration recommandée pour les performances PrestaShop. Le schéma de permissions standard 755/644 fonctionne bien. Assurez-vous que l'utilisateur du pool PHP-FPM correspond au propriétaire des fichiers ou dispose d'un accès de groupe approprié.

Pourquoi les permissions 777 sont dangereuses

Mettre les permissions à 777 signifie que n'importe qui sur le système peut lire, écrire et exécuter le fichier. Sur un hébergement mutualisé, cela signifie que d'autres comptes sur le même serveur pourraient potentiellement lire vos identifiants de base de données depuis parameters.php ou injecter du code malveillant dans vos fichiers PHP.

Même sur un VPS où vous êtes le seul utilisateur, 777 est inutile et indique une mauvaise configuration. Si le serveur web ne peut pas écrire dans un répertoire avec les permissions 755, la solution est de corriger la propriété, pas d'ouvrir les permissions au monde entier. Voici ce que vous devriez faire au lieu d'utiliser 777 :

Vérifiez sous quel utilisateur le serveur web s'exécute : ps aux | grep -E "apache|nginx|httpd"
Vérifiez la propriété des fichiers : ls -la /var/www/html/prestashop/
Corrigez la propriété : sudo chown -R www-data:www-data /chemin/vers/repertoire
Définissez les permissions correctes : chmod 755 /chemin/vers/repertoire

Si vous trouvez un tutoriel ou un message de forum recommandant 777 pour PrestaShop, c'est un conseil obsolète et dangereux. Le seul usage légitime de 777 est pour les répertoires /tmp qui ont le sticky bit activé (affiché comme 1777), ce qui est une configuration au niveau système, pas quelque chose que vous appliquez aux fichiers PrestaShop.

Considérations Docker pour PrestaShop

Exécuter PrestaShop dans Docker introduit une complexité supplémentaire pour les permissions de fichiers. À l'intérieur du conteneur, le serveur web s'exécute sous www-data avec un UID spécifique (souvent 33 sur les images basées sur Debian). Sur le système hôte, votre utilisateur a un UID différent. Lorsque vous utilisez des montages bind Docker pour monter vos fichiers PrestaShop dans le conteneur, la propriété des fichiers est déterminée par l'UID numérique, pas par le nom d'utilisateur.

Cela signifie que les fichiers créés sur l'hôte sous votre utilisateur (par ex., UID 1000) apparaîtront à l'intérieur du conteneur comme UID 1000, qui n'est pas www-data (UID 33). Le serveur web à l'intérieur du conteneur pourrait ne pas être en mesure d'écrire dans ces fichiers.

Les solutions pour les problèmes de permissions Docker incluent :

Faire correspondre les UIDs : Créez un utilisateur à l'intérieur du conteneur avec le même UID que votre utilisateur hôte, ou changez le serveur web pour qu'il s'exécute sous votre UID.
Utiliser chown dans l'entrypoint : Ajoutez une commande de démarrage qui exécute chown -R www-data:www-data /var/www/html au démarrage du conteneur. C'est simple mais peut être lent pour les installations volumineuses.
Définir les permissions de groupe : Ajoutez votre utilisateur hôte et www-data au même groupe (par GID), puis utilisez les permissions 775/664.
Volumes nommés : Utilisez des volumes nommés Docker au lieu des montages bind. Docker gère les permissions automatiquement, mais vous perdez l'accès direct au système de fichiers depuis l'hôte.

Pour les environnements de développement avec des montages bind, l'approche la plus pratique est d'exécuter une commande chown après la synchronisation ou le déploiement des fichiers :

docker exec votre-conteneur chown -R www-data:www-data /var/www/html/modules/votre-module/

Soyez conscient que les opérations à l'intérieur du conteneur (comme l'installation d'un module) peuvent créer des fichiers sous www-data, tandis que les opérations sur l'hôte créent des fichiers sous votre utilisateur hôte. Cette inadéquation constante d'UID est la source la plus courante de problèmes de permissions dans les configurations PrestaShop dockerisées.

Dépannage des erreurs de permissions courantes

"Failed to open stream: Permission denied"

Cette erreur signifie que PHP ne peut pas lire ou écrire dans un fichier. Vérifiez la propriété et les permissions du fichier mentionné dans l'erreur. La cause la plus courante est que l'utilisateur du serveur web ne possède pas le fichier ou le répertoire. Corrigez cela avec :

sudo chown www-data:www-data /chemin/vers/fichier
sudo chmod 644 /chemin/vers/fichier

"Unable to write to cache directory"

Le moteur de templates Smarty et le framework Symfony de PrestaShop écrivent tous deux des fichiers de cache. Si le répertoire var/cache/ n'est pas accessible en écriture, vous verrez cette erreur. Le répertoire de cache doit appartenir à l'utilisateur du serveur web :

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

Après avoir corrigé les permissions, videz le cache existant en supprimant le contenu des répertoires de cache :

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" ou "Cannot install module"

Les téléchargements d'images vont dans le répertoire img/, et les installations de modules écrivent dans le répertoire modules/. Les deux doivent être accessibles en écriture par l'utilisateur du serveur web. De plus, vérifiez que les paramètres PHP upload_max_filesize et post_max_size sont suffisamment grands pour vos fichiers, car ils peuvent produire des erreurs au libellé similaire.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" pendant les mises à jour

L'outil de mise à jour automatique de PrestaShop a besoin d'un accès en écriture à quasiment tous les fichiers de l'installation. Avant de lancer une mise à jour, définissez la propriété de l'ensemble de l'installation pour l'utilisateur du serveur web. Une fois la mise à jour terminée, vous pouvez restaurer une propriété plus restrictive si vous le souhaitez.

Page blanche après modification des permissions

Si vous voyez une page blanche après avoir modifié les permissions, vous avez peut-être accidentellement supprimé la permission d'exécution des répertoires. Les répertoires ont besoin du bit d'exécution pour être traversés. Un répertoire avec la permission 644 (sans exécution) est effectivement inaccessible. Utilisez toujours 755 pour les répertoires, jamais 644.

Vous pouvez également consulter le journal d'erreurs PHP pour plus de détails :

sudo tail -50 /var/log/apache2/error.log
# ou pour Nginx :
sudo tail -50 /var/log/nginx/error.log

Permissions réinitialisées après un téléchargement FTP

Certains clients FTP définissent leurs propres permissions par défaut lors du téléchargement de fichiers. Vérifiez les paramètres de votre client FTP pour une option « permissions par défaut » ou « umask ». Configurez-le pour créer les fichiers en 644 et les répertoires en 755. Alternativement, exécutez les commandes de correction des permissions après chaque téléchargement FTP.

Bonnes pratiques de sécurité au-delà des permissions

Les permissions de fichiers correctes ne sont qu'une couche de sécurité. Considérez ces mesures supplémentaires :

Restreindre l'accès aux fichiers de configuration : Le fichier app/config/parameters.php contient vos identifiants de base de données. Assurez-vous qu'il n'est lisible que par l'utilisateur du serveur web (permission 640), pas par tout le monde.
Désactiver le listing de répertoires : Ajoutez Options -Indexes à votre configuration Apache ou autoindex off; à Nginx pour empêcher les visiteurs de parcourir le contenu des répertoires.
Protéger les fichiers .htaccess : PrestaShop place des fichiers .htaccess dans les répertoires sensibles. Ne les supprimez pas.
Supprimer le répertoire d'installation : Après l'installation, supprimez complètement le répertoire /install/. PrestaShop vous en avertit, mais il est important de le souligner.
Définir un umask approprié : Configurez votre serveur web et PHP-FPM avec un umask de 0022 pour que les nouveaux fichiers soient créés avec les permissions 644/755 par défaut.

En comprenant les permissions Linux, en les adaptant à votre environnement d'hébergement et en suivant les recommandations de cet article, vous éviterez les problèmes de permissions PrestaShop les plus courants tout en maintenant une configuration serveur sécurisée.

Lire la réponse complète

Quand les mises à jour de modules tournent mal

Vous avez mis à jour un module PrestaShop et maintenant quelque chose ne fonctionne plus. Peut-être que le checkout a cessé de fonctionner, la page d'accueil affiche des erreurs, ou le panneau d'administration ne répond plus. Les mises à jour de modules peuvent échouer pour de nombreuses raisons - versions PHP incompatibles, conflits avec d'autres modules, erreurs de migration de base de données, ou simplement des bugs dans la nouvelle version. Quelle que soit la cause, vous devez revenir en arrière rapidement pour restaurer la fonctionnalité de votre boutique.

Malheureusement, PrestaShop n'inclut pas de bouton "annuler" intégré pour les mises à jour de modules. Il n'existe pas d'historique de versions natif ni de mécanisme de rollback automatique pour les modules individuels. Cela signifie que vous devez gérer la rétrogradation manuellement.

Avant de commencer - Sécurité d'abord

Mettez votre boutique en mode maintenance
Créez une sauvegarde de la base de données
Documentez l'erreur actuelle

Méthode 1 - Réinstaller la version précédente via le Back Office

Naviguez vers Modules > Gestionnaire de modules
Trouvez le module problématique et cliquez sur Désinstaller (PAS "Supprimer")
Cliquez sur Téléverser un module
Téléversez le ZIP de la version précédente fonctionnelle
Installez et configurez le module

Où obtenir la version précédente

Votre email - La plupart des vendeurs envoient des liens de téléchargement avec chaque achat
Compte marketplace - Sur PrestaShop Addons et les marketplaces tiers comme mypresta.rocks, vous pouvez télécharger les versions précédentes
Vos sauvegardes - Extrayez le dossier du module d'une archive de sauvegarde
Contacter le développeur - Les développeurs peuvent généralement fournir les anciennes versions

Méthode 2 - Remplacement de fichiers FTP/SFTP

Connectez-vous à votre serveur via FTP/SFTP
Naviguez vers /modules/
Trouvez le dossier du module
Renommez le dossier actuel - ex: mymodule en mymodule_cassé
Téléversez les fichiers de la version précédente
Réglez les permissions - répertoires à 755, fichiers à 644
Videz le cache PrestaShop

Méthode 3 - En ligne de commande

# Se connecter en SSH
ssh user@votreserveur.com

# Naviguer vers la racine PrestaShop
cd /var/www/html/prestashop

# Sauvegarder le module cassé
mv modules/mymodule modules/mymodule_cassé_$(date +%Y%m%d)

# Extraire la version précédente
unzip /chemin/vers/mymodule_v1.2.3.zip -d modules/

# Régler les permissions
find modules/mymodule -type d -exec chmod 755 {} \;
find modules/mymodule -type f -exec chmod 644 {} \;
chown -R www-data:www-data modules/mymodule

# Vider le cache
rm -rf var/cache/prod/* var/cache/dev/*

Méthode 4 - Rollback complet de la base de données

Si la mise à jour du module incluait des migrations de base de données, vous devrez restaurer une sauvegarde.

Quand vous avez besoin d'un rollback de base de données

Le module a créé de nouvelles tables
Le module a modifié des structures de tables existantes
Le module a inséré ou modifié des valeurs de configuration

Attention - Une restauration complète de la base de données annule TOUTES les modifications depuis la sauvegarde, y compris les nouvelles commandes et inscriptions clients.

Méthode 5 - Nettoyage manuel de la base de données

Examinez les méthodes d'upgrade du module pour comprendre les changements -

// Cherchez des fichiers comme:
// modules/mymodule/upgrade/upgrade-2.0.0.php

public function upgrade($version)
{
    if (version_compare($version, '2.0.0', '<')) {
        Db::getInstance()->execute('ALTER TABLE `' . _DB_PREFIX_ . 'mymodule` 
            ADD COLUMN `new_field` VARCHAR(255)');
    }
}

Après la rétrogradation - Nettoyage essentiel

Vider tous les caches

Cache Smarty
OPcache - Redémarrer PHP-FPM ou Apache
Cache CDN
Cache navigateur - Tester en navigation privée

Vérifier la version du module

Après la rétrogradation, vérifiez que PrestaShop reconnaît la bonne version.

Tester minutieusement

La fonctionnalité spécifique du module
Le processus de checkout
Les pages admin
Vues mobile et desktop
Performance

Prévenir les futurs problèmes de mise à jour

Toujours sauvegarder avant de mettre à jour
Tester les mises à jour sur un environnement de staging
Lire le changelog
Conserver les versions précédentes
Vérifier la compatibilité

Quand contacter le développeur du module

Si aucune des méthodes ci-dessus ne résout le problème, contactez le développeur avec votre version PrestaShop, version PHP, les versions du module concernées et les messages d'erreur exacts.

Lire la réponse complète

Comment tester un module PrestaShop sur un environnement de staging

Installer un module non testé sur une boutique PrestaShop en production est l'une des causes les plus courantes de temps d'arrêt, de processus de paiement défaillants et de pertes de chiffre d'affaires. Un environnement de staging vous offre un bac à sable sécurisé pour valider chaque module avant qu'il ne touche votre boutique de production. Ce guide vous accompagne à travers le processus complet - de la création d'une copie staging de votre boutique aux tests approfondis du module et au déploiement sécurisé en production.

Pourquoi vous avez besoin d'un environnement de staging

Un environnement de staging est une copie exacte de votre boutique en ligne qui n'est pas accessible au public. Il reflète votre base de données de production, vos fichiers, votre thème, votre configuration et vos modules installés. Tester en staging vous permet de détecter les problèmes qui autrement toucheraient vos clients.

Voici ce qui peut mal tourner quand vous sautez le staging :

Conflits de modules - Le nouveau module peut entrer en conflit avec un module existant, causant des écrans blancs, des erreurs JavaScript ou des fonctionnalités défaillantes sur certaines pages.
Incompatibilité de thème - Les templates du module peuvent ne pas s'afficher correctement avec votre thème, surtout si vous utilisez un thème personnalisé ou fortement modifié.
Dégradation des performances - Certains modules ajoutent des requêtes de base de données lourdes, des fichiers CSS/JS supplémentaires ou des appels API externes qui ralentissent les temps de chargement des pages.
Corruption de la base de données - Des modules mal écrits peuvent modifier les tables principales, ajouter des colonnes sans gestion de migration appropriée, ou créer des triggers qui interfèrent avec les données existantes.
Interruption des paiements - Si un module casse le processus de commande ou interfère avec votre passerelle de paiement, vous perdez des ventes depuis le moment de l'installation jusqu'à ce que vous découvriez et corrigiez le problème.

Option 1 - Configuration manuelle du staging (sous-domaine)

C'est l'approche la plus courante qui fonctionne avec tout fournisseur d'hébergement. Vous créez un sous-domaine comme staging.votreboutique.com et vous y copiez vos fichiers et base de données de production.

Étape 1 - Créer le sous-domaine

Dans votre panneau de contrôle d'hébergement (cPanel, Plesk ou DirectAdmin), créez un nouveau sous-domaine. Pointez-le vers un nouveau répertoire, par exemple /home/votreuser/staging.votreboutique.com.

Étape 2 - Copier les fichiers de production

Connectez-vous à votre serveur via SSH ou FTP et copiez tous les fichiers de production dans le répertoire staging :

# Via SSH (méthode la plus rapide)
cp -r /home/votreuser/public_html/* /home/votreuser/staging.votreboutique.com/

# Ou créez d'abord une archive compressée
cd /home/votreuser/public_html
tar czf /tmp/prestashop-backup.tar.gz --exclude='var/cache' --exclude='var/logs' .
cd /home/votreuser/staging.votreboutique.com
tar xzf /tmp/prestashop-backup.tar.gz

Étape 3 - Exporter et importer la base de données

Créez une nouvelle base de données pour le staging, puis copiez les données de production :

# Exporter la base de données de production
mysqldump -u dbuser -p production_db > /tmp/production_dump.sql

# Créer la base de données staging
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p -e "GRANT ALL ON staging_db.* TO 'dbuser'@'localhost';"

# Importer dans le staging
mysql -u dbuser -p staging_db < /tmp/production_dump.sql

Étape 4 - Mettre à jour la configuration PrestaShop

Éditez les fichiers de configuration pour pointer vers la base de données et le domaine staging :

# Éditer app/config/parameters.php (PrestaShop 1.7+/8.x)
# Changez ces valeurs :
'database_name' => 'staging_db',

# Mettre à jour l'URL de la boutique dans la base de données
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url 
  SET domain = 'staging.votreboutique.com', 
      domain_ssl = 'staging.votreboutique.com' 
  WHERE id_shop_url = 1;"

# Mettre à jour les valeurs de configuration
mysql -u dbuser -p staging_db -e "
  UPDATE ps_configuration 
  SET value = 'staging.votreboutique.com' 
  WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');"

Étape 5 - Vider les caches

rm -rf var/cache/prod/* var/cache/dev/*
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

Étape 6 - Restreindre l'accès

Empêchez les moteurs de recherche et les utilisateurs non autorisés d'accéder à votre site staging. Ajoutez au .htaccess à la racine de votre répertoire staging :

# Protéger le staging par mot de passe
AuthType Basic
AuthName "Accès Staging"
AuthUserFile /home/votreuser/.htpasswd
Require valid-user

# Bloquer les moteurs de recherche
Header set X-Robots-Tag "noindex, nofollow"

Option 2 - Staging basé sur Docker (Recommandé pour les développeurs)

Docker fournit l'environnement de staging le plus fiable car vous pouvez reproduire exactement votre version PHP de production, votre version MySQL et votre configuration serveur.

Configuration Docker Compose basique

# docker-compose.yml
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.1
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=prestashop
      - DB_PASSWD=votre_mot_de_passe
    depends_on:
      - db
      
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=mot_de_passe_root
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=votre_mot_de_passe
    volumes:
      - db_data:/var/lib/mysql
      
volumes:
  db_data:

Liste de contrôle des tests pour les nouveaux modules

Une fois votre environnement de staging prêt, suivez ce processus de test systématique pour chaque nouveau module.

Phase 1 - Vérifications pré-installation

Lire la documentation du module - Comprenez ce que fait le module, quels hooks il utilise et quelles sont ses exigences.
Vérifier le contenu des fichiers - Avant l'installation, décompressez le module et examinez le code. Recherchez des patterns suspects comme eval(), base64_decode() ou des appels URL vers des domaines inconnus.
Créer une sauvegarde de la base de données - Même en staging, faites une sauvegarde avant l'installation.

Phase 2 - Test d'installation

Installer le module via le Back Office (Modules > Gestionnaire de modules > Télécharger un module).
Vérifier les erreurs d'installation - Après l'installation, vérifiez que le module apparaît dans la liste des modules installés et qu'il n'y a pas de messages d'erreur.
Vérifier les modifications de la base de données - Comparez les tables avant et après l'installation.

Phase 3 - Tests fonctionnels

Testez chaque aspect de la fonctionnalité du module :

Page de configuration - Pouvez-vous accéder et sauvegarder tous les paramètres sans erreur ?
Affichage front office - Le module s'affiche-t-il correctement sur toutes les pages pertinentes ?
Responsivité mobile - Testez sur les viewports mobiles.
Support multilingue - Si votre boutique utilise plusieurs langues, vérifiez l'affichage correct dans chaque langue.
Compatibilité multiboutique - Si vous utilisez la fonctionnalité multiboutique, testez le comportement sur différentes boutiques.

Phase 4 - Tests de conflits

C'est la phase la plus critique. Testez les conflits avec votre configuration existante :

Vérifier la console du navigateur - Ouvrez les outils de développement (F12) et recherchez des erreurs JavaScript.
Tester le processus de commande - Ajoutez un produit au panier, parcourez chaque étape et finalisez une commande test.
Tester le traitement des paiements - Passez des commandes test avec chaque méthode de paiement que vous proposez.
Vérifier la fonctionnalité des modules existants - Assurez-vous que vos modules critiques fonctionnent toujours.

Phase 5 - Tests de performance

Mesurez l'impact du module sur les temps de chargement des pages :

# Avant l'installation, mesurer la baseline
curl -o /dev/null -s -w "Temps: %{time_total}s\n" https://staging.votreboutique.com/

# Après l'installation, mesurer à nouveau et comparer
curl -o /dev/null -s -w "Temps: %{time_total}s\n" https://staging.votreboutique.com/

Un module bien écrit devrait ajouter moins de 100ms aux temps de chargement. Si vous constatez une augmentation de 500ms ou plus, investiguez les requêtes SQL et le chargement des assets du module.

Phase 6 - Test de désinstallation

Testez que le module peut être proprement supprimé :

Désinstallez le module depuis le Back Office
Vérifiez que toutes les tables spécifiques au module sont supprimées
Vérifiez qu'aucun hook, fichier CSS ou fichier JavaScript orphelin ne reste
Vérifiez que le front office revient à son état pré-module

Déplacer un module testé vers la production

Étape 1 - Planifier le déploiement

Choisissez une période de faible trafic. Consultez vos Google Analytics pour identifier quand votre boutique a le moins de visiteurs.

Étape 2 - Créer une sauvegarde de production

mysqldump -u dbuser -p production_db > /tmp/production_backup_$(date +%Y%m%d_%H%M%S).sql

Étape 3 - Installer en production

Téléchargez exactement le même fichier ZIP du module que vous avez testé en staging. N'utilisez pas un fichier différent.

Étape 4 - Appliquer la même configuration

Configurez le module avec exactement les mêmes paramètres que sur le staging.

Étape 5 - Surveiller pendant 24-48 heures

Après le déploiement, surveillez activement les logs d'erreurs PHP, Google Analytics et le taux de conversion des commandes.

Pièges courants du staging à éviter

Oubli de mise à jour des URLs - Si vous copiez la base de données mais oubliez de mettre à jour ps_shop_url, votre site staging redirigera vers la production.
Passerelles de paiement en mode live - Passez toujours les passerelles de paiement en mode sandbox/test sur le staging.
Notifications email envoyées aux clients - Désactivez l'envoi d'emails sur le staging ou redirigez tous les emails vers une adresse de test.
Indexation par les moteurs de recherche - Bloquez toujours le staging pour les moteurs de recherche.
Tâches cron s'exécutant sur le staging - Désactivez les tâches cron copiées de la production.

Lire la réponse complète

Cookie	Fournisseur	Finalité	Durée
PrestaShop-*	PrestaShop	Gestion de session et fonctionnalité du panier	Session
PHPSESSID	PHP	Identifiant de session PHP	Session
mprcr_consent	MPR Cookies Revolution	Enregistre les préférences de consentement des cookies	365 jour(s)
mprcr_version	MPR Cookies Revolution	Suit la version de la configuration du consentement	365 jour(s)

Cookie	Fournisseur	Finalité	Durée
TawkConnectionTime	Tawk.to	Sleduje dobu pripojenia chatovej relacie	Session
__tawkuuid	Tawk.to	Identifikuje vracajucich sa navstevnikov chatu	6 mois

Cookie	Fournisseur	Finalité	Durée
_ga	Google Analytics	Distingue les utilisateurs uniques en attribuant un numéro généré aléatoirement	2 année(s)
_ga_*	Google Analytics	Utilisé pour maintenir la session entre les requêtes de pages	2 année(s)
_gid	Google Analytics	Distingue les utilisateurs uniques pendant 24 heures	24 heure(s)

Installation et configuration

Comprendre les permissions de fichiers Linux

Permissions correctes pour les répertoires et fichiers PrestaShop

Définir la bonne propriété avec chown

Hébergement mutualisé vs VPS vs Serveur dédié

Hébergement mutualisé

VPS (Serveur Privé Virtuel)

Serveur dédié

Modèles d'exécution PHP : suPHP vs mod_php vs PHP-FPM

mod_php (module Apache)

suPHP

PHP-FPM (FastCGI Process Manager)

Pourquoi les permissions 777 sont dangereuses

Considérations Docker pour PrestaShop

Dépannage des erreurs de permissions courantes

"Failed to open stream: Permission denied"

"Unable to write to cache directory"

"Cannot upload image" ou "Cannot install module"

"index.php is not writable" pendant les mises à jour

Page blanche après modification des permissions

Permissions réinitialisées après un téléchargement FTP

Bonnes pratiques de sécurité au-delà des permissions

Quand les mises à jour de modules tournent mal

Avant de commencer - Sécurité d'abord

Méthode 1 - Réinstaller la version précédente via le Back Office

Où obtenir la version précédente

Méthode 2 - Remplacement de fichiers FTP/SFTP

Méthode 3 - En ligne de commande

Méthode 4 - Rollback complet de la base de données

Quand vous avez besoin d'un rollback de base de données

Méthode 5 - Nettoyage manuel de la base de données

Après la rétrogradation - Nettoyage essentiel

Vider tous les caches

Vérifier la version du module

Tester minutieusement

Prévenir les futurs problèmes de mise à jour

Quand contacter le développeur du module

Comment tester un module PrestaShop sur un environnement de staging

Pourquoi vous avez besoin d'un environnement de staging

Option 1 - Configuration manuelle du staging (sous-domaine)

Étape 1 - Créer le sous-domaine

Étape 2 - Copier les fichiers de production

Étape 3 - Exporter et importer la base de données

Étape 4 - Mettre à jour la configuration PrestaShop

Étape 5 - Vider les caches

Étape 6 - Restreindre l'accès

Option 2 - Staging basé sur Docker (Recommandé pour les développeurs)

Configuration Docker Compose basique

Liste de contrôle des tests pour les nouveaux modules

Phase 1 - Vérifications pré-installation

Phase 2 - Test d'installation

Phase 3 - Tests fonctionnels

Phase 4 - Tests de conflits

Phase 5 - Tests de performance

Phase 6 - Test de désinstallation

Déplacer un module testé vers la production

Étape 1 - Planifier le déploiement

Étape 2 - Créer une sauvegarde de production

Étape 3 - Installer en production

Étape 4 - Appliquer la même configuration

Étape 5 - Surveiller pendant 24-48 heures

Pièges courants du staging à éviter

Autres catégories

Vous avez encore des questions ?