Guides Tutoriel

Faire tourner PrestaShop sur votre propre machine

Guide complet pour configurer un environnement de développement local PrestaShop : XAMPP, WAMP, MAMP, Docker, Linux natif et comparatif Windows vs Linux.

Pourquoi nous ne modifions jamais les fichiers PrestaShop sur un serveur en production

Chaque développeur de notre équipe a, à un moment de sa carrière, « corrigé vite fait » quelque chose sur une boutique en production et fait tomber le tunnel de commande au passage. Nous voyons des clients faire exactement la même chose tous les mois. Un environnement local est l'élément d'infrastructure qui vous évite d'être la personne qui a cassé la production à 23 h un vendredi soir.

Nous avons livré plus de 140 modules avec ce flux de travail depuis 2013, et la règle que nous nous imposons est simple : rien n'atteint la boutique d'un client sans être d'abord passé par une installation locale de la version exacte de PrestaShop qu'il utilise. Voici comment nous le mettons en place, ce que nous recommandons réellement, et les pièges dans lesquels nous avons vu des gens tomber.

  • Sécurité. Essayez une modification de thème, un changement de module ou un passage à une autre version de PHP sans mettre les commandes en péril.
  • Rapidité. Enregistrez le fichier, actualisez le navigateur. Pas de SFTP, pas de gestionnaire de fichiers cPanel, pas de « laissez-moi vider le cache depuis le panneau ».
  • Hors ligne. Nous avons débogué dans des trains et pendant des coupures de WiFi d'hôtel. Les installations locales s'en moquent.
  • Tests multi-versions. Nous faisons actuellement tourner PS 1.6, 1.7, 8.x et 9.x côte à côte. Soit un module fonctionne sur toutes les versions sur lesquelles un client peut se trouver, soit il n'est pas prêt.
  • De vrais outils de débogage. Pas-à-pas avec Xdebug, rapport d'erreurs complet, journaux des requêtes lentes. Un hébergement mutualisé ne vous donnera rien de tout cela.
Si vous modifiez du PHP directement sur le serveur en production, vous finirez par faire tomber la boutique. Nous avons nettoyé assez d'incidents de ce genre pour être francs à ce sujet : trente minutes à configurer un environnement local coûtent moins cher qu'un seul retour arrière d'urgence.

Windows, Linux ou macOS : réponse sans détour

Nous développons sous Linux. Toute notre stack repose sur Docker sur TrueNAS, et cela ne changera pas. Mais beaucoup de marchands avec qui nous travaillons sont sous Windows, et nous ne ferons pas semblant que XAMPP ne fasse pas le travail pour ce dont ils ont besoin.

Windows

XAMPP et WAMP vous permettent de démarrer rapidement. Pour un propriétaire de boutique qui veut prévisualiser une modification de thème ou tester l'installation d'un module, c'est très bien. La friction apparaît dès que vous essayez de livrer du code de Windows vers un serveur Linux, ce que fait tourner chaque hébergeur PrestaShop de la planète :

  • Sensibilité à la casse. MyModule.php et mymodule.php sont le même fichier sous Windows et deux fichiers différents sous Linux. Nous avons vu cela casser des modules au déploiement plus de fois que nous ne pouvons les compter, fonctionne parfaitement en local, erreurs 500 dès que cela arrive sur le serveur.
  • Permissions de fichiers. PrestaShop attend des permissions Unix de type 755/644. XAMPP n'applique pas vraiment les permissions, donc les bugs qui surviennent sous Linux (répertoire censé être accessible en écriture qui ne l'est pas, fichiers de cache appartenant au mauvais propriétaire) sont invisibles en local.
  • Fins de ligne. Des CRLF dans les fichiers PHP ou les scripts shell vous donneront des « headers already sent » et des tâches cron cassées. Configurez votre éditeur pour utiliser des LF.
  • Surcharge de Defender. Windows Defender analyse chaque fichier PHP que PrestaShop charge. Sur une page de back-office qui touche 800 fichiers, vous le sentirez passer.

Linux

Même système de fichiers, mêmes permissions, même build de PHP que votre serveur. Docker s'exécute nativement sans VM entre les deux, donc les entrées/sorties de fichiers sont réelles et le démarrage des conteneurs est instantané.

  • Aucune surcharge de virtualisation.
  • PHP, MySQL, Apache, Nginx, Composer, Node, Git, VS Code, tout gratuit, tout empaqueté.
  • Si cela fonctionne en local, cela fonctionne généralement en production. Si cela casse en production, vous pouvez presque toujours le reproduire en local.

macOS

De l'Unix en dessous, donc les permissions et les chemins se comportent correctement. Docker s'exécute dans une petite VM, ce qui signifie que les entrées/sorties des volumes montés sont plus lentes que sous Linux, perceptible sur les installations PrestaShop qui chargent des centaines de fichiers par requête. Homebrew gère le reste proprement : brew install php@8.2 mysql composer.

Ce que nous choisirions réellement

Si PrestaShop est votre métier, utilisez Linux. Nous utilisons Arch avec KDE Plasma sur les machines de développement, Debian sur notre serveur. Si vous ne voulez pas changer de système d'exploitation, XAMPP sous Windows est assez honnête pour les tests d'un propriétaire de boutique, rappelez-vous simplement que c'est une prévisualisation, pas une copie fidèle de votre serveur de production.

Le meilleur environnement de développement est celui que vous utilisez vraiment tous les jours. Une installation XAMPP brouillonne que vous lancez quotidiennement vaut mieux qu'une configuration Linux parfaite qui attend encore d'être configurée dans votre dossier Documents.

Option 1 : XAMPP (Windows, macOS, Linux)

XAMPP regroupe Apache, MariaDB, PHP et phpMyAdmin dans un seul programme d'installation. C'est le moyen le plus rapide de faire tourner PrestaShop sur une machine de bureau, et pour les clients qui n'ont besoin que de prévisualiser des choses, c'est ce que nous leur conseillons d'utiliser.

Installation

1. Récupérez-le sur apachefriends.org. Faites correspondre la version de PHP à votre PrestaShop : 7.2-7.4 pour PS 1.7, 8.0-8.2 pour PS 8.x, 8.1-8.3 pour PS 9.x.

2. Installez-le (Windows utilise par défaut C:\xampp, macOS /Applications/XAMPP). Démarrez Apache et MySQL depuis le panneau de contrôle.

3. Ouvrez http://localhost/phpmyadmin, créez une base de données nommée prestashop avec l'interclassement utf8mb4_general_ci.

4. Téléchargez PrestaShop depuis les versions GitHub et extrayez-le dans C:\xampp\htdocs\prestashop\.

5. Rendez-vous sur http://localhost/prestashop, suivez le programme d'installation (hôte : localhost, utilisateur : root, mot de passe : vide), puis supprimez le répertoire install/ ensuite.

Les modifications de php.ini dont vous aurez besoin

Ouvrez php.ini depuis le panneau de contrôle XAMPP (Apache > Config). Les valeurs par défaut ne vous feront pas passer une installation PrestaShop :

memory_limit = 512M              ; la valeur par défaut de 128M ne suffit pas
max_execution_time = 300         ; 30s par défaut, trop court pour les imports
upload_max_filesize = 64M        ; 2M par défaut, trop petit pour les ZIP de modules
post_max_size = 64M
max_input_vars = 20000           ; 1000 par défaut : critique pour les formulaires d'admin PS

Décommentez intl, gd, zip, curl et mbstring en supprimant le ; en début de ligne. Redémarrez Apache. Sauter l'un d'entre eux est la raison la plus fréquente pour laquelle une installation XAMPP fraîche refuse de faire tourner PrestaShop, intl en particulier piège presque tout le monde.

Là où XAMPP vous mord

Le port 80 est pris. Skype, IIS ou Windows lui-même l'a accaparé. Changez Listen 80 en Listen 8080 dans httpd.conf et utilisez http://localhost:8080.

Les réglages ne s'enregistrent pas, les combinaisons disparaissent. Le fameux problème de max_input_vars. La valeur par défaut est 1000 ; les formulaires d'admin PS peuvent envoyer plus de 5000 variables sur un produit comportant de nombreuses combinaisons. Réglez-la sur 20000 dans php.ini.

Page blanche. Consultez toujours d'abord C:\xampp\apache\logs\error.log. C'est presque toujours une extension PHP manquante ou la mémoire épuisée.

Option 2 : WAMP (Windows uniquement)

La seule chose que WAMP fait mieux que XAMPP, c'est le changement de version de PHP à l'échelle du serveur depuis l'icône de la barre des tâches. Utile si vous bidouillez une version de PS cette semaine et une autre la semaine suivante.

Mise en place

1. Téléchargez le programme d'installation 64 bits depuis wampserver.aviatechno.net. Installez les redistribuables Visual C++ qu'il réclame, sinon il ne démarrera pas.

2. Installez-le dans C:\wamp64. L'icône de la barre des tâches passe au vert quand Apache et MySQL sont tous les deux actifs.

3. Ajoutez des versions de PHP supplémentaires depuis la page des extensions de WAMP ; elles s'intègrent automatiquement au sélecteur de versions.

Hôtes virtuels

WAMP inclut un gestionnaire d'hôtes virtuels (icône de la barre des tâches > Vos hôtes virtuels > Gestion des hôtes virtuels). Pointez ps17.local et ps8.local vers des répertoires différents, WAMP gère pour vous le fichier hosts et la configuration d'Apache.

WAMP change la version de PHP à l'échelle du serveur, pas par hôte virtuel. Vous ne pouvez pas faire tourner PHP 7.4 pour une boutique et PHP 8.2 pour une autre en même temps. Dès que vous en avez besoin, il vous faut Docker.

Option 3 : MAMP (macOS)

L'équivalent Mac de XAMPP. Version gratuite : une seule racine de document, Apache, PHP, MySQL. MAMP Pro à 59 $ débloque plusieurs hôtes, le SSL, des versions de PHP par hôte et Nginx.

Installez depuis mamp.info, déposez PrestaShop dans /Applications/MAMP/htdocs/prestashop/, ouvrez http://localhost:8888/prestashop. Si les montages de volumes Docker vous semblent péniblement lents sur votre Mac (une plainte courante), tournez-vous vers Homebrew à la place, PHP et MySQL natifs sans VM entre les deux.

Option 4 : Installation Linux native

Installez Apache, PHP et MySQL directement sur le système d'exploitation. Le plus de contrôle, le plus rapide, le plus proche de ce que fait tourner votre hébergeur.

Ubuntu / Debian

sudo apt update
sudo apt install apache2
sudo apt install php8.2 php8.2-fpm php8.2-mysql php8.2-gd php8.2-intl \\
  php8.2-curl php8.2-zip php8.2-xml php8.2-mbstring php8.2-bcmath
sudo apt install mysql-server
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Arch Linux : sudo pacman -S apache php php-fpm php-gd php-intl php-sodium mariadb composer, puis initialisez MariaDB et lancez les services avec systemctl.

Hôte virtuel Apache

Créez /etc/apache2/sites-available/ps8.local.conf avec un VirtualHost pointant ServerName ps8.local vers votre répertoire PrestaShop. Réglez AllowOverride All, confiez le PHP à FPM. Activez avec sudo a2ensite ps8.local.conf && sudo a2enmod rewrite proxy_fcgi && sudo systemctl reload apache2. Ajoutez 127.0.0.1 ps8.local à /etc/hosts.

Permissions de fichiers

Faites de www-data le propriétaire de tout, répertoires en 755, fichiers en 644, et les répertoires accessibles en écriture (var/, cache/, img/, upload/, config/) en 775. Nous avons débogué des pages blanches sous Linux une centaine de fois et la réponse était les permissions dans 90 d'entre elles. Vérifiez le journal d'erreurs d'Apache pour « Permission denied » avant toute autre chose.

Option 5 : Docker : ce que nous utilisons réellement

Chaque version de PrestaShop a son propre conteneur avec son propre PHP et MySQL. Rien n'entre en conflit, rien ne fuit entre les boutiques. Nous faisons tourner notre flotte entière de 25 conteneurs de cette façon. Il existe un guide Docker complet couvrant les configurations multi-versions, mais le point de départ est celui-ci :

Un docker-compose.yml fonctionnel

services:
  prestashop:
    image: prestashop/prestashop:8.2
    ports: ["8085:80"]
    environment:
      DB_SERVER: db
      DB_USER: prestashop
      DB_PASSWD: prestashop
      DB_NAME: prestashop
      PS_DOMAIN: localhost:8085
      ADMIN_MAIL: admin@yourshop.com
      ADMIN_PASSWD: your_secure_password
    volumes: [ps-files:/var/www/html]
    depends_on: [db]
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root_pass
      MYSQL_DATABASE: prestashop
      MYSQL_USER: prestashop
      MYSQL_PASSWORD: prestashop
    volumes: [db-data:/var/lib/mysql]
volumes:
  ps-files:
  db-data:

Lancez-le avec docker compose up -d, ouvrez http://localhost:8085.

Nous faisons tourner plus de 25 conteneurs PrestaShop sur un seul hôte TrueNAS (de PS 1.6 à 9.1) pour le test des modules. Tenter de gérer cela avec autre chose que Docker serait un travail à plein temps. Même avec deux ou trois versions, Docker se rentabilise dès la première fois où vous auriez sinon rencontré un conflit de version de PHP.

Configuration valable pour toutes les méthodes

Les extensions PHP sans lesquelles PrestaShop ne tournera pas

  • intl : devises, paramètres régionaux, formatage des dates. La plus fréquemment manquante.
  • gd : traitement d'images, miniatures, filigranes.
  • curl : passerelles de paiement, API webservice, tout ce qui est sortant.
  • mbstring : gestion des chaînes UTF-8. Sans elle, le texte multioctet se casse silencieusement.
  • zip : les installations de modules lisent les ZIP à travers elle.
  • xml : import/export et le webservice.
  • pdo_mysql : connectivité à la base de données.
  • opcache : techniquement optionnelle, mais sur une vraie boutique la différence se mesure en secondes par requête.

Vérifiez avec php -m | grep intl, ou déposez un fichier phpinfo() temporaire et supprimez-le dès que vous avez terminé.

URL simplifiées

Apache : sudo a2enmod rewrite, réglez AllowOverride All dans votre vhost. Nginx : try_files $uri $uri/ /index.php?$args;. Activez ensuite le réglage dans Paramètres de la boutique > Trafic & SEO.

Test des e-mails avec Mailpit

Capturez chaque e-mail sortant en local au lieu d'écrire par accident à un client depuis votre poste de développement :

docker run -d --name mailpit -p 8025:8025 -p 1025:1025 axllent/mailpit

Dans les réglages SMTP de PrestaShop : serveur localhost, port 1025, pas de chiffrement, pas d'authentification. Lisez le courrier capturé sur http://localhost:8025.

Configuration de l'IDE

VS Code (gratuit) : les extensions PHP Intelephense et PHP Debug. Xdebug sur le port 9003 avec un pathMappings du chemin du conteneur vers votre espace de travail. PHPStorm (payant) : prise en charge de PHP intégrée, Xdebug, outils de base de données et intégration Docker. Nous utilisons les deux. PHPStorm se rentabilise si le PHP est votre gagne-pain.

Importer une boutique en production en local

Tester contre une installation PrestaShop fraîche n'attrape que les bugs faciles. Les vrais bugs vivent dans les surcharges de thème, les 80 modules installés et le catalogue de 12 000 produits. Rapatriez-le et reproduisez-le en local. Si la base de données de production est trop lourde à déplacer confortablement, élaguez d'abord les journaux, les paniers obsolètes et autres données jetables avec Database Cleanup, puis exportez.

Export et import de la base de données

# Export depuis la production (via SSH : phpMyAdmin expire sur les grosses BDD)
mysqldump -u db_user -p database_name > prestashop_backup.sql

# Créer la base de données locale
mysql -u root -p -e "CREATE DATABASE prestashop_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"

# Import
mysql -u root -p prestashop_local < prestashop_backup.sql

Copier les fichiers et réécrire les URL

Rapatriez les répertoires qui comptent vraiment, img/, modules/, themes/, config/, override/, upload/ : rsync -avz user@server:/path/to/prestashop/ /local/prestashop/

-- Changer le domaine vers le local
UPDATE ps_shop_url SET domain = 'localhost:8080', domain_ssl = 'localhost:8080' WHERE id_shop_url = 1;

-- Désactiver le SSL
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SSL_ENABLED';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SSL_ENABLED_EVERYWHERE';

Modifiez app/config/parameters.php (PS 1.7/8.x) ou config/settings.inc.php (PS 1.6) avec les identifiants de la BDD locale, puis videz le cache : rm -rf var/cache/*.

Une fois l'import effectué, créez un tout nouveau compte d'administration pour l'usage local et ne vous connectez pas avec les identifiants de production. Nous avons vu des gens oublier quel onglet était lequel et modifier une description de catégorie sur la boutique en production. Nouveau compte local, nouveau mot de passe, facile à garder séparés.

Les problèmes que nous voyons les clients rencontrer le plus souvent

Écran blanc après l'installation

Lisez toujours le journal d'abord. La réponse y est presque toujours en une ligne :

# Apache : tail -50 /var/log/apache2/error.log
# XAMPP : C:\\xampp\\apache\\logs\\error.log
# PrestaShop : tail -50 var/logs/dev.log

Extension manquante : Call to undefined function dans le journal vous indique laquelle. Mémoire : Allowed memory size exhausted, augmentez memory_limit. Mauvais PHP : PS 8.x sur PHP 7.4 déclenche des erreurs de type ; php -v ne ment pas.

Le panneau d'administration renvoie des 404 sur chaque URL sauf le tableau de bord

mod_rewrite n'est pas activé, ou le .htaccess n'est pas lu. sudo a2enmod rewrite, AllowOverride All dans le vhost. Pour XAMPP, changez AllowOverride None en AllowOverride All dans httpd.conf.

Pénible de lenteur sous Windows

Antivirus : ajoutez vos répertoires XAMPP et PrestaShop aux exclusions de Windows Defender. La différence est spectaculaire. Docker sur WSL2 : gardez les fichiers PrestaShop à l'intérieur du système de fichiers propre à WSL2, dans /home/you/prestashop/, jamais sur /mnt/c/.... Les volumes Windows montés à travers WSL2 sont assez lents pour rendre PrestaShop inutilisable.

Les images ne se chargent pas

Pas de GD : installez php-gd. Permissions : chown -R www-data:www-data img/. Boutique importée : régénérez les miniatures depuis Apparence > Réglages des images, sans cela, le front-office référence des fichiers qui n'ont jamais été créés en local.

L'installation du module échoue

« Cannot upload » : augmentez upload_max_filesize et post_max_size à 64M. « Cannot unzip » : installez php-zip. « Permission denied » : chmod 775 modules/. « Class not found » : index de classes obsolète, supprimez var/cache/*/class_index.php et rechargez.

Connexion à la base de données refusée

MySQL ne tourne pas, sudo systemctl status mysql. « Access denied » signifie que les identifiants de votre configuration ne correspondent pas à ce que MySQL a en mémoire.

Habitudes de travail qui valent la peine d'être adoptées

Activez le mode développeur. Dans config/defines.inc.php : define('_PS_MODE_DEV_', true);. Vous obtenez des traces d'appels et des détails SQL au lieu de pages vides. Ne laissez jamais cela activé sur une boutique en production, cela divulgue les chemins et les requêtes.

Désactivez la mise en cache en local. Back-office > Paramètres avancés > Performances, cache Smarty « Non », CCC désactivé. Les templates et les ressources mis en cache masqueront les modifications que vous venez de faire et vous feront perdre une heure de votre vie.

Git, même pour un seul module. git init dans le répertoire du module, validez à chaque état fonctionnel. git diff vous indique ce qui a changé, git checkout -- file.php annule l'expérience qui n'a pas marché. Nous validons des dizaines de fois par jour sur l'ensemble de notre flotte de modules.

Référence rapide : quel PHP pour quel PrestaShop

  • PS 1.6.1.x : PHP 5.6-7.1, MySQL 5.0-5.7
  • PS 1.7.0-1.7.6 : PHP 7.1-7.3, MySQL 5.5-5.7
  • PS 1.7.7-1.7.8 : PHP 7.2-7.4, MySQL 5.6-8.0
  • PS 8.0-8.1 : PHP 8.0-8.1, MySQL 5.7-8.0
  • PS 8.2 : PHP 8.1-8.2, MySQL 5.7-8.0 / MariaDB 10.x
  • PS 9.x : PHP 8.1-8.3, MySQL 8.0 / MariaDB 10.11+
Recoupez avec la configuration système requise officielle pour la version corrective exacte sur laquelle vous vous trouvez, les versions mineures resserrent la plage de PHP prise en charge étonnamment souvent.

Lectures associées

Questions liées

Retour en haut