Pour installer un module PrestaShop, envoyez son fichier ZIP depuis le back-office : allez dans Modules → Module Manager → Upload a module, déposez le ZIP téléchargé, et PrestaShop le décompresse puis l’installe pour vous. Dans le cas standard, aucun FTP n’est nécessaire.

Quelques points utiles avant de commencer :

• Envoyez le ZIP tel quel, ne le décompressez pas d’abord. PrestaShop lit directement l’archive.
• Si l’envoi échoue sur un module volumineux, la limite vient généralement de upload_max_filesize ou post_max_size sur votre serveur, augmentez-la dans les paramètres PHP, ou envoyez le dossier par FTP dans /modules/ puis installez-le depuis Module Manager.
• Après l’installation, ouvrez l’écran Configure du module pour le paramétrer. Installer seul suffit rarement à terminer le travail.

Tous nos modules s’installent de cette façon. Vous pouvez récupérer le dernier ZIP de chaque module que vous possédez depuis votre compte, puis consulter toute la gamme sur la boutique mypresta.rocks.

Le détail technique important est qu’un module PrestaShop est identifié par son dossier interne et son nom de classe, pas par le nom du fichier téléchargé. Dans le code source du module, les paquets déclarent un nom technique comme mprcanonicalmanager, une version, un onglet, une plage de compatibilité et un nom affiché. Gardez intact ce dossier de premier niveau ; ne le renommez pas et n’envoyez pas par erreur un dossier imbriqué comme module.zip/mprcanonicalmanager/.

L’installation exécute aussi le code du module. Selon le module, ce code peut créer des tables de base de données, enregistrer des hooks, installer des entrées de menu admin et initialiser des réglages par défaut. Par exemple, un module SEO ou de maillage interne peut créer ses propres tables de règles, enregistrer des hooks de sortie et ajouter ses écrans de configuration pendant install(). Copier les fichiers dans /modules/ n’est donc que la première moitié d’une installation FTP ; le module doit encore être installé depuis Module Manager pour que sa routine de configuration s’exécute.

Une checklist sûre :

1. Téléchargez le ZIP le plus récent depuis votre compte.
2. Envoyez le ZIP via Module Manager si votre serveur l’autorise.
3. Si les limites d’envoi PHP bloquent le ZIP, décompressez-le localement et envoyez le seul dossier du module dans /modules/.
4. Trouvez le module dans Module Manager, cliquez sur Install, puis ouvrez Configure et enregistrez les options nécessaires.

C’est généralement une limite d’envoi PHP, pas un problème avec le ZIP du module. PrestaShop reçoit le ZIP via le flux normal de fichier téléversé de PHP ; si PHP rejette le fichier en premier, le back-office ne peut afficher qu’une erreur "file too large" ou d’envoi incomplet.

Demandez à votre hébergeur d’augmenter upload_max_filesize et post_max_size. Définissez post_max_size plus haut que upload_max_filesize, car tout le HTTP POST a son propre overhead. Pour les modules plus gros ou les hébergements mutualisés lents, augmentez aussi max_execution_time pour laisser à PHP le temps de copier et d’extraire l’archive.

; php.ini or .user.ini example
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300
memory_limit = 256M

# Apache + mod_php only, not PHP-FPM
php_value upload_max_filesize 64M
php_value post_max_size 80M
php_value max_execution_time 300

Après avoir changé les paramètres PHP, redémarrez PHP-FPM ou Apache si votre hébergeur l’exige, puis rechargez le back-office PrestaShop et réessayez. Si vous ne pouvez pas modifier ces valeurs, utilisez plutôt FTP/SFTP : décompressez le module localement, copiez le dossier du module dans /modules/, puis installez-le depuis Modules > Module Manager. Le résultat installé est le même qu’après un envoi ZIP réussi.

Toujours bloqué ? Contactez notre équipe support avec le nom du ZIP, la taille du fichier, la version PrestaShop, la version PHP et l’erreur exacte de téléversement.

Quand vous utilisez FTP/SFTP, assurez-vous d’envoyer le dossier qui contient le fichier PHP principal du module. Par exemple, un module dont la source déclare $this->name = 'mprinternallinking' doit se trouver dans /modules/mprinternallinking/, avec mprinternallinking.php et ses dossiers vendor/, controllers/, views/ ou src/ dans ce même dossier. Un dossier wrapper supplémentaire est une cause fréquente d’absence du module dans Module Manager.

Une fois les fichiers en place, ne vous arrêtez pas là. La routine d’installation est ce qui crée les tables du module, enregistre les hooks et ajoute les contrôleurs admin. Dans les modules inspectés, le code d’installation peut aussi réinitialiser opcache, installer le stockage partagé de configuration admin et initialiser des valeurs par défaut. Si vous copiez seulement les fichiers sans jamais cliquer sur Install, ces tables et hooks de base de données manquent.

Si un ancien téléversement échoué a laissé un dossier à moitié créé, supprimez seulement ce dossier de module incomplet avant de réessayer, puis envoyez une copie propre. Ne supprimez pas des caches PrestaShop ou des dossiers de modules sans rapport simplement parce que le téléversement a échoué ; l’échec s’est généralement produit avant même que le code d’installation du module ne s’exécute.

Non, pour la plupart des modules, vous ne touchez jamais au FTP PrestaShop. Le chemin standard est le back-office : Modules → Module Manager → Upload a module, glissez le ZIP, terminé. Le FTP n’est qu’un repli pour deux cas bien connus.

• Le ZIP dépasse votre limite d’envoi PHP. Les hébergements mutualisés limitent souvent upload_max_filesize et post_max_size à quelques mégaoctets, donc les ZIP de modules plus gros échouent dans le navigateur. Augmentez ces deux valeurs PHP dans votre panneau d’hébergement, ou envoyez le module par FTP.
• Erreurs de droits ou d’envoi partiel. Si le back-office signale une erreur de permission ou un module à moitié installé, le FTP vous donne une façon propre de récupérer.

Pour installer un module par FTP : décompressez-le localement, envoyez le dossier obtenu (par exemple mprseorevolution/) dans /modules/ à la racine de votre boutique, assurez-vous que les fichiers sont lisibles par l’utilisateur du serveur web (votre hébergeur peut confirmer), puis ouvrez Module Manager, cherchez le nom du module et cliquez sur Install.

La plupart de nos modules sont assez petits pour être envoyés directement via Module Manager, donc le FTP reste un secours, pas une exigence. Voir aussi : installer un module sur PrestaShop.

Le nom du dossier compte. Les classes de module déclarent un nom technique comme mprcanonicalmanager, mprinternallinking ou mprcheckoutrevolution. C’est ce dossier que PrestaShop attend sous /modules/. Gardez le fichier PHP principal du module, l’autoloader Composer, les contrôleurs, les vues et les classes source ensemble dans ce dossier.

Le FTP ne contourne pas la configuration du module. Il contourne seulement la limite d’envoi du navigateur. Vous devez encore cliquer sur Install pour que le module crée ses tables, enregistre ses hooks et ajoute ses écrans back-office. Par exemple, un module peut déclarer des tables de base de données pour des groupes de liens ou des statuts de devis, puis créer ces tables et enregistrer les hooks pendant sa méthode d’installation.

Utilisez le FTP comme outil de récupération, pas comme flux quotidien. Si l’envoi back-office fonctionne, il est plus propre, car PrestaShop gère l’archive, le placement du dossier et le flux d’installation au même endroit. Si le FTP est nécessaire, envoyez une fois, installez une fois, puis configurez le module depuis sa page admin plutôt que d’écraser répétitivement des fichiers pendant qu’il est actif.

Oui. L'utilisation au quotidien de chaque module passe par le back office PrestaShop, panneaux clairs, libellés explicites, textes d'aide intégrés. Pas besoin de toucher au code, d'éditer des templates ni d'exécuter des commandes.

Concrètement :

• Installation. Téléversez le ZIP du module via Modules → Module Manager. Si votre hébergement bloque le téléversement, le FTP est une alternative documentée.
• Configuration. Chaque module s'ouvre sur un panneau de réglages avec des valeurs par défaut sensées. La plupart des boutiques fonctionnent immédiatement ; les interrupteurs et listes déroulantes couvrent le reste.
• Bloqué ? Si quelque chose vous bloque pendant l'installation, écrivez-nous en décrivant ce que vous voyez et nous vous aiderons.

Si vous savez installer un thème ou changer le logo de la boutique depuis le back office PrestaShop, vous savez installer et faire tourner nos modules. Pour de la personnalisation graphique vraiment poussée, un développeur reste utile, mais le flux standard installation et configuration se fait sans. Voir notre guide de dépannage PrestaShop en cas de souci.

Dans la très grande majorité des cas, non. Nos modules suivent les bonnes pratiques PrestaShop : classes PHP avec namespaces, CSS et JavaScript isolés, et aucun fichier déposé dans /override/classes/. C'est de là que viennent presque tous les conflits de modules sur PrestaShop.

Là où des conflits peuvent quand même apparaître :

• Ordre des hooks. Deux modules attachés au même hook (ex. displayHeader ou actionCartSave) peuvent s'exécuter dans un ordre qui surprend l'un d'eux. La vue Hooks du Gestionnaire de modules permet de réordonner en quelques secondes.
• Surcharges de template du thème. Si votre thème embarque une copie d'un template de module sous /themes/<nom>/modules/<module>/, c'est cette copie qui prend le pas, et qui peut ne pas refléter de nouvelles fonctionnalités après une mise à jour. Re-synchroniser le template règle le problème.
• Autres overrides. Un module tiers déposant une classe dans /override/classes/ peut casser le nôtre (et bien d'autres). PrestaShop permet de désactiver les overrides un par un, ce qui identifie généralement le coupable.

En cas de conflit réel, nous l'analysons et le résolvons dans le cadre de votre période de support, sans coût supplémentaire, sur des boutiques qui respectent la compatibilité indiquée du module. Pour la méthode pas à pas, voir notre guide de dépannage PrestaShop.

Pour installer un module sur PrestaShop 9, allez dans Modules → Module Manager, cliquez sur Upload a module dans le coin supérieur droit, puis déposez le ZIP téléchargé depuis votre compte. Le chemin est le même que celui que vous connaissez déjà depuis PrestaShop 8.x.

Deux points méritent d’être vérifiés d’abord sur PrestaShop 9 :

• Récupérez la dernière build. Les anciens ZIP de modules antérieurs à PrestaShop 9 peuvent dépendre de services supprimés. Téléchargez toujours la version la plus récente depuis votre compte avant l’envoi.
• Vérifiez votre version PHP. PrestaShop 9 exige au minimum PHP 8.1 ; PHP 8.2 ou 8.3 est un choix raisonnable si vos modules et votre thème le supportent.

Si l’envoi échoue silencieusement ou renvoie une erreur 500, ne supprimez pas brutalement var/cache/prod/ sur PrestaShop 9. Cela peut effacer le conteneur Symfony du back-office et vous bloquer l’accès. Videz plutôt le cache depuis Advanced Parameters → Performance, ou demandez à votre hébergeur d’exécuter php bin/console cache:clear --env=prod. Pas de FTP ? Voir notre guide d’installation sans FTP.

La raison pour laquelle le ZIP le plus récent compte est visible dans le code source des modules : les modules déclarent leur propre plage de compatibilité PrestaShop. Certains paquets supportent explicitement de larges plages jusqu’à 9.99 ou 9.99.99, tandis que d’autres définissent une version minimale de PrestaShop comme 1.7.6. Un ZIP construit avant l’ajout du support PrestaShop 9 peut installer des fichiers techniquement présents, mais incompatibles avec les services, hooks ou runtime PHP utilisés par votre boutique actuelle.

Après l’envoi, ouvrez la page de configuration du module et enregistrez ses réglages. PrestaShop 9 peut afficher le module comme installé alors que la partie utile dépend encore de valeurs de configuration telles que clés API, bascules SEO, statuts de devis par défaut, options de sitemap, sélecteurs, IDs de tracking ou tokens cron. Beaucoup de modules initialisent des valeurs par défaut à l’installation, mais les valeurs propres au marchand doivent toujours être définies dans l’écran Configure.

Si l’envoi ZIP échoue à cause de la taille, utilisez le même repli FTP que sur PrestaShop 8 : décompressez localement, envoyez le seul dossier du module dans /modules/, puis installez-le depuis Module Manager. Gardez le nom de dossier exactement tel qu’il est livré, car le nom de classe du module et la valeur interne $this->name sont liés à ce répertoire.

Oui, sur trois niveaux indépendants selon jusqu'où vous voulez aller.

• Réglages intégrés. La plupart des modules exposent couleurs, espacements, densité de mise en page et interrupteurs de fonctionnalité dans le back office. Commencez là, cela couvre la majorité des ajustements de marque sans écrire de CSS.
• CSS dans votre thème. Les styles front du module se surchargent depuis le custom.css de votre thème, sans toucher aux fichiers du module. Les mises à jour préservent vos overrides.
• Surcharges de template. Pour des changements HTML structurels, copiez le .tpl du module dans /themes/<votre-theme>/modules/<module>/templates/ et éditez la copie. PrestaShop charge automatiquement la version du thème.

Ne modifiez pas les fichiers dans /modules/<module>/, ils sont écrasés à la mise à jour. Pour une personnalisation hors panneau et CSS, nous proposons un service payant ; contactez-nous avec une capture.

C'est presque toujours l'une de ces quatre causes, par ordre de probabilité :

• Il reste à configurer. Beaucoup de modules n'affichent rien tant que leur configuration n'est pas terminée, ouvrez la page de paramètres du module et complétez-la.
• Votre thème n'utilise pas le hook du module. Allez dans Design > Positions, trouvez le module et greffez-le sur un hook que votre thème affiche réellement (par ex. un autre hook d'accueil ou de pied de page).
• Il est limité à certaines pages ou produits. Certains modules ne s'affichent que sur des types de pages précis ou pour des produits remplissant une condition, vérifiez les paramètres du module.
• Le cache sert l'ancienne page. Videz le cache PrestaShop (Paramètres avancés > Performances) et celui du navigateur, puis rechargez.

Si rien n'apparaît après ces quatre points, le module ne s'enregistre peut-être pas du tout sur la page consultée, consultez sa documentation pour ses hooks. Parcourez notre catalogue de modules pour les notes de configuration.

Oui. Vous pouvez exécuter n'importe lequel de nos modules sur un environnement de développement local PrestaShop, Docker, WAMP, MAMP ou un simple localhost, sans que cela soit décompté de votre licence. Votre licence couvre un domaine de production plus un sous-domaine de développement/staging (ex. : dev.exemple.com) ; un conteneur ou une VM locale reste toujours libre pour vos tests.

Un environnement local sous Docker est donc l'endroit sûr pour essayer un module, rejouer une mise à jour ou reproduire un bug avant qu'il n'atteigne votre boutique en production.

Pour une mise en place pas à pas, consultez notre guide sur la création d'un environnement de développement local PrestaShop avec Docker.

Nos modules n'imposent aucune exigence PHP propre, ils fonctionnent avec la version de PHP que votre installation PrestaShop prend déjà en charge. Si votre boutique tourne aujourd'hui, le module tourne.

En pratique : utilisez la version de PHP recommandée pour votre version de PrestaShop. Chaque fiche produit indique les versions de PrestaShop prises en charge, ce qui détermine l'exigence PHP.

Si vous utilisez une version de PHP plus ancienne et avez un doute, envoyez-nous vos versions exactes de PrestaShop et de PHP : nous confirmons avant l'achat. Voir aussi nos guides d'installation & configuration.

Un écran blanc dans PrestaShop (le « page blanche » ou white screen of death) signifie presque toujours une erreur fatale PHP masquée. Activez le mode debug pour voir le vrai message : éditez /config/defines.inc.php, mettez _PS_MODE_DEV_ à true, puis rechargez la page.

Les causes habituelles après l'installation d'un module : une version PHP ou une extension PHP manquante dont le module a besoin, une limite mémoire trop basse, ou un conflit avec un autre module. Envoyez-nous la ligne d'erreur exacte et nous vous dirons d'où vient le problème.

Pour aller plus loin : guide de dépannage PrestaShop.

Pour mettre à jour un module PrestaShop, téléchargez le dernier ZIP depuis votre compte, puis allez dans Modules → Gestionnaire de modules → Téléverser un module et envoyez le nouveau fichier. PrestaShop détecte l'installation existante, écrase les fichiers du module et exécute les scripts de mise à niveau livrés avec la nouvelle version. Vos réglages sont conservés. La configuration du module est en base de données, pas dans les fichiers remplacés.

Deux précautions avant le téléversement évitent la plupart des soucis :

• Sauvegardez fichiers et base de données. Certaines mises à jour ajoutent des colonnes ou migrent des lignes de configuration ; une sauvegarde complète permet un retour arrière en quelques minutes.
• Notez la version actuelle. Le gestionnaire affiche la version installée à côté du module, notez-la avant d'écraser.

Après le téléversement, videz le cache dans Paramètres avancés → Performance → Vider le cache. Sur les versions de PrestaShop basées sur Symfony, utilisez ce même panneau plutôt que de supprimer var/cache/prod/ à la main. Si quelque chose paraît anormal ensuite, l'action Réinitialiser du gestionnaire réinstalle hooks et fichiers en conservant la configuration.

Ce flux de téléversement ZIP est identique pour tous nos modules, y compris les plus lourds comme Performance Revolution, dont les scripts de mise à niveau rafraîchissent aussi la configuration du cache.

Non. Les mises à jour de modules sont conçues pour conserver vos paramètres existants. Votre configuration vit dans la base de données PrestaShop (la table ps_configuration et les tables propres au module), et une mise à jour n'efface pas ces lignes, ses scripts d'upgrade ajoutent de nouvelles colonnes ou options sans toucher à l'existant.

Une procédure sûre :

1. Faire d'abord une sauvegarde complète de la base (panneau d'hébergement ou outil DB Backup de PrestaShop).
2. Déposer le nouveau ZIP du module dans le Module Manager, PrestaShop détecte le changement de version et exécute les scripts d'upgrade.
3. Vider le cache et ouvrir la page de configuration du module pour vérifier que tout est intact.

Si quelque chose paraît anormal, la sauvegarde est votre retour arrière en une étape. Voir notre guide de sauvegarde PrestaShop.

Oui. Chaque achat de module inclut l'installation initiale gratuite par nos soins, comprise dans la période de support incluse. Nous installons le module, ouvrons l'écran de configuration et vérifions le bon fonctionnement sur votre boutique.

Après l'achat, ouvrez un ticket avec :

• L'URL de votre boutique.
• Les identifiants admin du back-office (ou un utilisateur admin temporaire) et FTP/SSH si un envoi de fichiers est nécessaire.
• Une phrase sur ce que vous voulez que le module fasse, pour que nous le configurions selon votre cas d'usage réel, pas sur les valeurs par défaut.

Nous répondons en général sous un jour ouvré. L'installation ne couvre pas les personnalisations lourdes ni les conflits avec des modules tiers, ceux-ci relèvent de notre politique de support.

Non, vous devez mettre le PHP de votre serveur au moins au niveau demandé par le module. Exécuter une version PHP plus ancienne que celle requise provoque des erreurs de syntaxe ou des échecs silencieux pendant l’installation.

Comment corriger :

1. Vérifiez votre version PHP actuelle dans PrestaShop Back Office → Advanced Parameters → Information, ou avec un fichier d’une ligne <?php phpinfo(); ?>.
2. Changez PHP dans votre panneau d’hébergement. Sur cPanel c’est MultiPHP Manager ; sur Plesk c’est Domains → PHP Settings ; sur les hébergeurs managés, le sélecteur se trouve dans les paramètres du domaine ou du site.
3. Choisissez la version supportée par votre PrestaShop et vos modules. Le message d’installation du module indique le minimum requis, respectez-le ou prenez une version plus récente, dans la plage acceptée par votre édition PrestaShop.
4. Videz le cache PrestaShop (Advanced Parameters → Performance) après le changement de PHP, puis relancez l’installation.

Si votre hébergeur ne peut pas proposer une version PHP assez récente, c’est le moment de migrer. Exécuter PrestaShop sur un PHP obsolète est aussi un risque de sécurité. Voir notre guide d’hébergement PrestaShop pour savoir quoi rechercher.

Ce message n’est pas un avertissement que vous pouvez ignorer sans risque. Dans les modules inspectés, les exigences PHP sont appliquées dans le code ou les métadonnées du paquet. La classe d’intégrité de Checkout Revolution, par exemple, définit une version PHP minimale et compare le PHP_VERSION exécuté à celle-ci. Le paquet partagé Internal Linking déclare aussi une exigence PHP Composer. Si le serveur est sous la version requise, le module peut échouer avant même que son écran admin ne puisse s’afficher.

Ne corrigez pas cela en modifiant le fichier du module pour abaisser l’exigence. Cela retire seulement le garde-fou ; cela ne rend pas l’ancien PHP capable de comprendre une syntaxe plus récente, des déclarations de type ou le code de bibliothèques. La vraie correction consiste à exécuter une version PHP supportée à la fois par votre cœur PrestaShop et par les modules installés sur la boutique.

Quand vous changez PHP, vérifiez toute la boutique, pas seulement le nouveau module. Votre thème, vos modules de paiement, modules de livraison et overrides utilisent tous le même interpréteur PHP. Après le changement, videz le cache, ouvrez le front-office, ouvrez le back-office, passez une petite commande de test si des modules liés au checkout sont concernés, et consultez les logs d’erreur PHP pour détecter les fatals avant de considérer la mise à jour terminée.

Dans la plupart des cas, oui. Nos modules utilisent des hooks PrestaShop standard et ne modifient pas les fichiers du cœur, ce qui limite les conflits. Nous ne pouvons cependant pas garantir la compatibilité avec chaque module tiers, surtout ceux qui :

• Livrent des fichiers dans override/ (la couche de personnalisation la plus risquée de PrestaShop).
• Modifient les mêmes tables de la base (par ex. ps_product, ps_order) via des hooks comme actionObjectUpdateAfter.
• Remplacent le même template Smarty via views/templates/hook/ sur un hook que nous utilisons aussi.

Le test le plus rapide : installer sur une copie de staging, activer les deux modules, naviguer dans les pages concernées avec le mode Debug actif (define('_PS_MODE_DEV_', true); dans config/defines.inc.php) et surveiller var/logs/. En cas de conflit réel, envoyez-nous le nom de l'autre module et le message d'erreur, nous étudierons. Notre guide de dépannage PrestaShop détaille les mêmes vérifications.

L'installation d'un module échoue généralement parce que PrestaShop ne peut pas lire l'archive, ne peut pas écrire les fichiers du module, ou parce que le module ne peut pas fonctionner sur le serveur actuel.

Vérifiez d'abord la structure du ZIP. L'archive doit contenir un seul dossier de module au premier niveau, avec le fichier PHP principal du module à l'intérieur, par exemple mymodule/mymodule.php. Une erreur courante consiste à envoyer un ZIP de type GitHub contenant un dossier enveloppe supplémentaire, un dossier de documentation, ou un dossier de module imbriqué au lieu du vrai répertoire installable du module.

zip=module.zip
unzip -Z1 "$zip" | sed -n '1,20p'
unzip -Z1 "$zip" | awk -F/ 'NF{print $1}' | sort -u
find modules -maxdepth 0 -writable -print
php -v
php -m | grep -Ei '^(zip|curl|dom|fileinfo|json|mbstring|openssl|intl)$'
ls -lt var/logs/* 2>/dev/null | head

• Vérifiez les limites d'upload : la limite effective est contrôlée par upload_max_filesize et post_max_size. Si le ZIP dépasse l'une de ces valeurs, l'upload depuis le back-office peut échouer avant même que PrestaShop n'installe le module.
• Vérifiez les permissions : le répertoire modules/ doit être accessible en écriture par l'utilisateur du serveur web, et les répertoires de cache/logs doivent aussi être inscriptibles.
• Vérifiez la compatibilité PHP : une mauvaise version de PHP ou des extensions PHP manquantes comme zip, curl, dom, fileinfo, json, mbstring, openssl ou intl peuvent casser l'installation ou les écrans de configuration.
• Vérifiez les logs PrestaShop : regardez dans var/logs/, sur la page d'erreur du back-office et dans le log d'erreurs du serveur web/PHP-FPM pour trouver la vraie exception.
• Videz le cache après avoir corrigé une installation échouée, car PrestaShop peut avoir mis en cache une classe de module partiellement chargée.

Si le module apparaît dans la liste des modules mais refuse de s'installer, l'archive a probablement été extraite correctement et l'échec se situe dans la routine d'installation du module. S'il n'apparaît jamais, concentrez-vous d'abord sur la structure du ZIP, les limites d'upload et les permissions du système de fichiers.

Si la routine d'installation échoue après que le dossier a déjà été extrait, supprimez d'abord le module partiellement installé depuis le Module Manager s'il est visible, puis videz var/cache/ avant de réessayer. Si la ligne du module existe dans la base de données mais que le back-office ne peut pas charger la page du module, ne relancez pas l'opération à l'aveugle ; restaurez la sauvegarde des fichiers/de la base de données ou demandez au support de vérifier l'étape install() qui a échoué.

Lorsque vous contactez le support, envoyez le nom et la version du ZIP du module, votre version de PrestaShop, la version de PHP, le texte exact de l'erreur, les dernières lignes de var/logs/prod.log ou var/logs/dev.log, ainsi que l'information indiquant si le dossier du module existe désormais sous modules/. Cela permet au support de savoir si l'échec s'est produit pendant l'envoi/l'extraction ou dans l'installateur propre au module.

Oui. Au moment de choisir le bon hébergement pour PrestaShop, nos modules ne posent aucun souci : ce sont des modules PrestaShop standard et ils fonctionnent sur tout hébergement faisant tourner PrestaShop. Les plateformes managées comme Cloudways, RunCloud ou GridPane se chargent simplement de l'administration du serveur, vous installez les modules via le back office PrestaShop comme d'habitude.

Le seul point d'attention est un hébergeur managé avec des limites PHP inhabituelles ou des règles de sécurité (par exemple un max_execution_time bas, un memory_limit serré, ou des règles qui bloquent les envois de fichiers ZIP). Si une installation ou un envoi échoue, signalez-le au support de l'hébergeur, c'est un réglage serveur, pas le module.

Pour savoir ce qui fait un bon hébergement PrestaShop, version PHP, mémoire, OPcache, base de données, etc., consultez notre guide d'hébergement PrestaShop.

MPR Cron stocke les tâches enregistrées, logs d’exécution, hits de déclenchement, durées, statuts, contexte, nombres de tâches dues et résumés module. L’espace admin vous permet de voir ce qui est enregistré, quand cela a tourné pour la dernière fois, quand c’est prochainement dû, si les exécutions récentes ont échoué, et si le déclencheur externe touche bien la boutique.

Le module possède des zones admin séparées pour tâches planifiées, modules, hits, logs et paramètres. Les lignes de tâche incluent type, statut personnalisé, planning, indicateur enabled, contexte, priorité, timeout, dernière exécution, prochaine exécution et statut d’enregistrement. Les résumés module incluent modules détectés, nombres de tâches, nombres activés, tâches dues, échecs des dernières 24 heures, dernière exécution et prochaine exécution. Le monitoring de hit enregistre source, libellé, dernier hit, âge, contexte, nombre de tâches, durée, statut et si le hit est récent.

Le point d’entrée cron peut tourner en CLI ou HTTP avec un token, un nombre maximal de tâches, un nombre maximal de secondes et un contexte. Le runner valide le token, vérifie si cron est activé, trouve les tâches dues, les exécute, enregistre les données heartbeat, et journalise statut de tâche, durée, contexte et résultat. Les types de tâches URL, command et callable sont pris en charge, et le runner enregistre échecs, timeouts et aperçus de réponse afin que le back-office montre plus que le simple fait qu’une URL cron ait été visitée.

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 :

1. Définir le propriétaire en www-data:www-data (ou votre utilisateur de serveur web)
2. Utiliser 755 pour les répertoires et 644 pour les fichiers
3. 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 marche à suivre 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 :

1. Vérifiez sous quel utilisateur le serveur web s'exécute : ps aux | grep -E "apache|nginx|httpd"
2. Vérifiez la propriété des fichiers : ls -la /var/www/html/prestashop/
3. Corrigez la propriété : sudo chown -R www-data:www-data /chemin/vers/repertoire
4. 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 correctifs 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.

Pour des étapes détaillées aux erreurs de permissions et de serveur, consultez notre guide de dépannage PrestaShop.

PrestaShop n'a pas de bouton d'annulation intégré pour une mise à jour de module, donc une rétrogradation est un rollback contrôlé des fichiers, de l'état de la base de données et du cache. Allez lentement ; un mauvais rollback peut être pire que la mauvaise mise à jour.

1. Mettez la boutique en mode maintenance depuis Shop Parameters > General > Maintenance, surtout si le module touche au checkout, paiement, stock, prix, URL ou tracking.
2. Faites d'abord une sauvegarde complète. Sauvegardez tout l'arbre de fichiers PrestaShop, la base de données et le dossier actuel /modules/module_name/. Gardez aussi la version cassée ; le support peut en avoir besoin pour comparer la mise à niveau.
3. Notez l'état actuel. Relevez le nom du module, la nouvelle version, la version précédente fonctionnelle, l'erreur exacte, les pages touchées et les IDs de commandes récents si le checkout était concerné.
4. Récupérez le ZIP précédent exact. Utilisez votre historique de commandes, l'archive des releases ou le support. Ne mélangez pas des fichiers de deux versions.

Le rollback de fichiers le plus sûr consiste généralement à renommer le dossier actuel, extraire proprement l'ancien ZIP et replacer l'ancien dossier du module sous /modules/. Exemple : renommez /modules/examplemodule en /modules/examplemodule.bad-update, uploadez l'ancien dossier examplemodule, puis vérifiez la version du module dans Module Manager. Évitez de cliquer sur Delete. Soyez aussi prudent avec Uninstall : beaucoup de modules conservent leurs données, mais certaines routines de désinstallation suppriment volontairement la configuration ou des tables personnalisées.

Si la mise à jour a modifié des tables de base de données, les fichiers seuls peuvent ne pas suffire. Restaurez les tables et clés de configuration affectées du module depuis la sauvegarde pré-mise à jour, ou demandez au support le SQL exact de rétrogradation. Ne devinez jamais les changements de schéma sur une boutique en production.

Après le rollback des fichiers et de la base de données, videz le cache PrestaShop sous var/cache/prod et var/cache/dev, videz le cache Smarty si applicable, réinitialisez OPcache en rechargeant PHP-FPM ou Apache, et purgez le CDN/Varnish/cache pleine page si utilisé. Testez ensuite la fonctionnalité du module, les pages front-office pertinentes, l'enregistrement de configuration back-office et le checkout de bout en bout.

Pour les modules achetés chez nous, le ZIP précédent est normalement disponible depuis l'historique de commandes, et le support peut fournir un ancien build si nécessaire. Pour préparer les sauvegardes, consultez notre guide de sauvegarde PrestaShop.

Installer un module non testé sur une boutique en production est une cause fréquente de pannes, de paiement cassé et de ventes perdues. Un environnement de staging, une copie privée de votre boutique, vous permet de valider chaque module avant qu'il ne touche la production. Voici le déroulé complet.

Pourquoi le staging compte

Le staging reflète la base de données, les fichiers, le thème et les modules de production mais n'est pas public. Il intercepte les problèmes qui toucheraient autrement vos clients : conflits de modules (écrans blancs, erreurs JavaScript), incompatibilité de thème, régressions de performance, corruption de base par des modules mal écrits, et interruptions de paiement.

Option 1, Staging par sous-domaine (sur tout hébergeur)

Créez un sous-domaine comme staging.votreboutique.com pointant vers un nouveau répertoire, puis :

# Copier les fichiers de production
cp -r /home/votreuser/public_html/* /home/votreuser/staging.votreboutique.com/

# Exporter et importer la base de données
mysqldump -u dbuser -p production_db > /tmp/dump.sql
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u dbuser -p staging_db < /tmp/dump.sql

# Pointer la copie staging vers la base et le domaine staging
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url SET domain='staging.votreboutique.com', domain_ssl='staging.votreboutique.com';
  UPDATE ps_configuration SET value='staging.votreboutique.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');"

# Vider les caches
rm -rf var/cache/prod/* var/cache/dev/* var/cache/smarty/compile/*

Ensuite, bloquez l'accès : ajoutez une authentification HTTP basique et un en-tête X-Robots-Tag : noindex, nofollow dans le .htaccess pour garder le staging privé et hors des résultats de recherche.

Option 2, Staging Docker (au plus proche de la production)

Docker permet de reproduire exactement vos versions PHP et MySQL :

# docker-compose.yml (réglez le tag de l'image sur votre version PrestaShop)
services:
  prestashop:
    image: prestashop/prestashop
    ports: ["8080:80"]
    volumes: ["./html:/var/www/html"]
    depends_on: [db]
  db:
    image: mysql
    environment:
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=votre_mot_de_passe
      - MYSQL_ROOT_PASSWORD=mot_de_passe_root

Importez votre dump de production dans le conteneur, puis mettez ps_shop_url et PS_SHOP_DOMAIN sur localhost:8080 et désactivez le SSL pour l'accès local.

Liste de contrôle pour un nouveau module

• Avant l'installation : lisez la doc, décompressez et survolez le code à la recherche d'appels suspects (eval(), base64_decode(), URL externes inconnues), faites une sauvegarde de la base.
• Installez via le Back Office (Gestionnaire de modules > Téléverser), vérifiez la liste des modules installés et le log d'erreurs PHP, notez les tables créées.
• Fonctionnel : ouvrez et enregistrez la page de configuration ; vérifiez le front office sur l'accueil, la catégorie, le produit, le panier et le checkout ; testez le mobile, chaque langue et le multiboutique le cas échéant.
• Conflits : surveillez la console pour les erreurs JavaScript, passez une commande test complète avec chaque moyen de paiement et confirmez que vos modules critiques fonctionnent toujours.
• Performance : chronométrez quelques pages clés avec curl -o /dev/null -s -w "%{time_total}" avant et après, un module bien écrit ajoute peu.
• Désinstallation : retirez-le et confirmez que ses tables, hooks et assets sont nettoyés.

Passer en production

Déployez en période creuse, faites d'abord une nouvelle sauvegarde de production, téléversez exactement le même ZIP testé, reproduisez la même configuration, repassez une checklist abrégée, puis surveillez les logs d'erreurs et la conversion pendant un jour ou deux.

Pièges courants

• ps_shop_url / PS_SHOP_DOMAIN non mis à jour, le staging redirige alors vers la production.
• Passerelles de paiement en mode live, passez-les en sandbox.
• E-mails envoyés aux vrais clients, désactivez l'envoi ou redirigez vers une boîte de test.
• Staging indexé par les moteurs, bloquez-le.
• Tâches cron copiées de la production, désactivez celles qui envoient des e-mails ou contactent des services externes.

Pour diagnostiquer les problèmes rencontrés, voir notre guide de dépannage PrestaShop.

Non. Redis Cache Manager & Monitor n’installe pas le serveur Redis. Redis doit déjà exister sur votre hébergement - fourni par votre prestataire, VPS, stack Docker ou service de cache managé - et l’extension PHP redis doit être chargée. Si l’extension manque, le module vous le dit et le tableau de bord affiche un avertissement au lieu d’échouer silencieusement.

Ce qu’il fait, c’est connecter PrestaShop à ce Redis existant et vous permettre de le gérer depuis le back-office. Vous définissez l’hôte, le port, le mot de passe, le numéro de base et un préfixe de clé (utile quand plusieurs boutiques partagent la même instance Redis), puis vous activez le cache objet et le stockage de session basés sur Redis, surveillez le monitoring live et parcourez les clés - sans toucher à des fichiers de configuration en SSH.

Les valeurs de connexion par défaut sont volontairement prudentes :

REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_DB=0
REDIS_PREFIX=ps_

Le module teste la connexion avec l’hôte, le port, le mot de passe optionnel et la base sélectionnée configurés, puis lit les informations du serveur Redis comme version, uptime, usage mémoire, clients connectés et nombre total de clés. Les interrupteurs object cache, session cache et full-page cache existent mais sont désactivés par défaut, donc installer le module ne déplace pas soudainement chaque couche de cache tant que vous ne choisissez pas de l’activer.

Le préfixe de clé compte lorsque plusieurs boutiques partagent un même serveur Redis. Le navigateur de clés et les outils de vidage par préfixe travaillent à l’intérieur de ce préfixe, et le vidage par préfixe retourne volontairement sans rien effacer si le préfixe est vide. Une sauvegarde de configuration normale peut aussi vider le préfixe configuré lorsque Flush on save est activé, ce qui aide à éviter les données en cache obsolètes après modification de la connexion ou des réglages de cache.

Donc la séparation honnête : votre hébergeur (ou vous) fournit le service Redis ; Redis Cache Manager & Monitor gère côté PrestaShop en sécurité depuis l’admin. Une erreur fréquente est de l’acheter en pensant obtenir une installation Redis en un clic - confirmez d’abord que Redis et l’extension PHP sont disponibles, puis ce module gère le reste.