[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"theme-db":3,"$fKnz2vuX4bZz1LbUTiuFsvSZ3e07l5_5fqNYp4Tzdhi8":22,"$f-rB5NHQxc6Um1kpcroqRxCmmq-o7nMwP88rQgVGZa1g":103,"megamenu":171,"footer-db":227,"header-db":245,"$fFJL5viqUGHZEbnCK9_shlNgdbHw6gVW3Lzl4m-R3J7w":256},{"theme":4},{"colors":5,"typography":13,"ui":17,"defaultColorMode":21},{"primary":6,"secondary":7,"background":8,"foreground":9,"muted":10,"headerBg":11,"footerBg":12,"topBarBg":9,"topBarText":11},"#4F46E5","#0D9488","#F9FAFB","#111827","#6B7280","#ffffff","#020617",{"fontFamily":14,"fontUrl":15,"baseFontSize":16},"Inter, system-ui, sans-serif","https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter:wght@400;500;600;700&family=Playfair+Display:ital,wght@0,400;0,700;0,800;0,900;1,400;1,700&display=swap","16px",{"borderRadius":18,"contentWidth":19,"shadow":20},"lg","7xl",true,"light",{"columns":23},[24,40,70,91],{"title":25,"links":26},"Plateforme",[27,31,34,37],{"label":28,"href":29,"external":30},"Offre Starter (2 500 €)","\u002Foffre-starter",false,{"label":32,"href":33,"external":30},"Devenir Ambassadeur","\u002Fambassadeur",{"label":35,"href":36,"external":30},"Modules PrestaShop","\u002Fmodules",{"label":38,"href":39,"external":20},"CodeMyShop.com","https:\u002F\u002Fcodemyshop.com",{"title":41,"links":42},"Le Synedre",[43,46,49,52,55,58,61,64,67],{"label":44,"href":45,"external":30},"L'histoire","\u002Fsynedre",{"label":47,"href":48,"external":30},"Constitution","\u002Fsynedre\u002Fconstitution",{"label":50,"href":51,"external":30},"L'équipe","\u002Fequipe",{"label":53,"href":54,"external":30},"Le réacteur en direct","\u002Freacteur",{"label":56,"href":57,"external":30},"Le Drill (entraînement)","\u002Fdrill",{"label":59,"href":60,"external":30},"Protocole de réunion","\u002Fsynedre\u002Freunion",{"label":62,"href":63,"external":30},"Les agents IA","\u002Fagents-ia",{"label":65,"href":66,"external":30},"La Conduite","\u002Fsynedre\u002Fconduite",{"label":68,"href":69,"external":30},"Charte plateforme","\u002Fsynedre\u002Fcharte",{"title":71,"links":72},"Ressources",[73,76,79,82,85,88],{"label":74,"href":75,"external":30},"Blog","\u002Fblog",{"label":77,"href":78,"external":30},"Academy","\u002Facademy",{"label":80,"href":81,"external":30},"Dictionnaire","\u002Fdictionnaire",{"label":83,"href":84,"external":30},"Expertise PrestaShop","\u002Fexpertise",{"label":86,"href":87,"external":30},"Flywheel","\u002Fflywheel",{"label":89,"href":90,"external":30},"Manifeste","\u002Fmanifeste",{"title":92,"links":93},"À propos",[94,97,100],{"label":95,"href":96,"external":30},"Alexandre Carette","\u002Fa-propos",{"label":98,"href":99,"external":30},"Dossier de presse","\u002Fpresse",{"label":101,"href":102,"external":30},"Contact","\u002Fcontact",{"title":104,"slug":105,"metaDescription":106,"category":107,"tags":108,"difficulty":115,"psVersions":116,"content":119,"faq":120,"tldr":166,"readingTime":167,"generatedAt":168,"publishDate":168,"relatedArticles":169,"sourceCategory":170},"Migration PrestaShop vers un nouveau serveur : résoudre les erreurs courantes","migration-prestashop-nouveau-serveur-erreurs-courantes","Guide complet pour migrer PrestaShop sans erreur : cache Symfony, permissions fichiers, .htaccess et back-office inaccessible. Solutions testées PS 1.7 à 8.x.","migration",[109,110,111,112,113,114],"migration serveur","cache symfony","permissions fichiers","htaccess","back-office prestashop","erreur 500","intermediaire",[117,118],"1.7","8.x","\u003Ch2>Introduction\u003C\u002Fh2>\n\u003Cp>Migrer un site PrestaShop vers un nouveau serveur est une opération délicate qui peut provoquer des erreurs en cascade si l'on ne respecte pas un ordre précis. Page blanche, back-office inaccessible, erreur 500 sur certaines pages… Ces symptômes sont quasi systématiques lors d'une migration mal préparée.\u003C\u002Fp>\n\u003Cp>Dans cet article, je détaille la méthodologie complète pour diagnostiquer et corriger les problèmes post-migration, du plus simple au plus complexe.\u003C\u002Fp>\n\u003Ch2>Étape 1 : vérifier l'accès de base au back-office\u003C\u002Fh2>\n\u003Cp>Avant toute investigation avancée, il faut déterminer \u003Cstrong>quel niveau d'accès fonctionne encore\u003C\u002Fstrong>. Testez ces URLs dans l'ordre :\u003C\u002Fp>\n\u003Col>\n\u003Cli>**Page de login du back-office** : `https:\u002F\u002Fvotre-site.com\u002Fadmin-xxx\u002F`\u003C\u002Fli>\n\u003Cli>**Dashboard legacy** : `https:\u002F\u002Fvotre-site.com\u002Fadmin-xxx\u002Findex.php?controller=AdminDashboard`\u003C\u002Fli>\n\u003Cli>**Une page Symfony** (ex. Produits dans PS 1.7.7+) : `https:\u002F\u002Fvotre-site.com\u002Fadmin-xxx\u002Findex.php\u002Fsell\u002Fcatalog\u002Fproducts`\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Interpréter les résultats\u003C\u002Fh3>\n\u003Ctr>\u003Cth>Résultat\u003C\u002Fth>\u003Cth>Diagnostic probable\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Cth>Aucun accès, page blanche ou 500\u003C\u002Fth>\u003Cth>Problème .htaccess ou permissions serveur\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Cth>Login OK, dashboard OK, pages Symfony KO\u003C\u002Fth>\u003Cth>Cache Symfony corrompu ou incompatible\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Cth>Tout le BO KO sauf les controllers legacy\u003C\u002Fth>\u003Cth>Problème Symfony (cache, routes, configuration PHP)\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Cth>Login OK mais menu vide\u003C\u002Fth>\u003Cth>Table `ps_tab` vide ou corrompue dans la base de données\u003C\u002Fth>\u003C\u002Ftr>\n\u003Cp>Cette distinction entre \u003Cstrong>pages legacy\u003C\u002Fstrong> (anciens controllers PHP classiques) et \u003Cstrong>pages Symfony\u003C\u002Fstrong> (introduites progressivement depuis PS 1.7.4) est fondamentale. Si les pages legacy fonctionnent mais pas les pages Symfony, le problème vient du framework Symfony embarqué dans PrestaShop, et non de PrestaShop lui-même.\u003C\u002Fp>\n\u003Ch2>Étape 2 : le fichier .htaccess\u003C\u002Fh2>\n\u003Cp>Le \u003Ccode>.htaccess\u003C\u002Fcode> est souvent la première cause de dysfonctionnement après migration. Les règles de réécriture d'URL contiennent des chemins qui peuvent ne plus correspondre au nouveau serveur.\u003C\u002Fp>\n\u003Ch3>Solution rapide\u003C\u002Fh3>\n\u003Cp>Renommez le \u003Ccode>.htaccess\u003C\u002Fcode> à la racine pour le désactiver temporairement :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">\nmv .htaccess .htaccess.bak\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Si le site redevient accessible, le problème est confirmé. Régénérez alors un \u003Ccode>.htaccess\u003C\u002Fcode> propre :\u003C\u002Fp>\n\u003Col>\n\u003Cli>Connectez-vous au back-office\u003C\u002Fli>\n\u003Cli>Allez dans **Paramètres de la boutique → Trafic et SEO**\u003C\u002Fli>\n\u003Cli>Désactivez l'option **URL simplifiée** puis enregistrez\u003C\u002Fli>\n\u003Cli>Réactivez-la et enregistrez à nouveau\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>PrestaShop regénère automatiquement le \u003Ccode>.htaccess\u003C\u002Fcode> avec les bons chemins.\u003C\u002Fp>\n\u003Ch3>Pour PrestaShop 8.x\u003C\u002Fh3>\n\u003Cp>Sur PS 8.x avec Apache, vérifiez également que le module \u003Ccode>mod_rewrite\u003C\u002Fcode> est bien activé sur le nouveau serveur :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">\napache2ctl -M | grep rewrite\n# Doit afficher : rewrite_module (shared)\n\n# Si absent :\nsudo a2enmod rewrite\nsudo systemctl restart apache2\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Si vous utilisez \u003Cstrong>Nginx\u003C\u002Fstrong> (de plus en plus courant en 2025-2026), le \u003Ccode>.htaccess\u003C\u002Fcode> est ignoré. Il faut transposer les règles dans la configuration Nginx. PrestaShop fournit un fichier d'exemple dans \u003Ccode>docs\u002Fnginx.conf.dist\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2>Étape 3 : vérifier la base de données\u003C\u002Fh2>\n\u003Cp>Après migration, certaines tables peuvent être incomplètes ou corrompues. Un point de contrôle essentiel : la table \u003Ccode>ps_tab\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Cette table contient la \u003Cstrong>structure complète du menu du back-office\u003C\u002Fstrong>. Si elle est vide ou partiellement importée, le back-office affichera un menu vide ou des erreurs sur chaque page.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">\nSELECT COUNT(*) FROM ps_tab;\n-- PrestaShop 1.7 : environ 170-180 lignes attendues\n-- PrestaShop 8.x : environ 180-200 lignes attendues\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Si le résultat est 0 ou anormalement bas, votre import SQL est incomplet. Réimportez la base en vérifiant :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>L'encodage est bien **utf8mb4** (et non latin1)\u003C\u002Fli>\n\u003Cli>Le fichier SQL n'a pas été tronqué lors du transfert\u003C\u002Fli>\n\u003Cli>La taille maximale d'import de phpMyAdmin n'a pas coupé le fichier (utilisez la ligne de commande pour les bases volumineuses) :\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode class=\"language-bash\">\nmysql -u utilisateur -p nom_base < dump_complet.sql\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Étape 4 : permissions et propriétaire des fichiers\u003C\u002Fh2>\n\u003Cp>C'est le problème le plus fréquent et le plus sous-estimé lors d'une migration. Les fichiers transférés par FTP, rsync ou tar héritent souvent du mauvais propriétaire.\u003C\u002Fp>\n\u003Ch3>Vérifier le propriétaire actuel\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">\nls -la \u002Fvar\u002Fwww\u002Fprestashop\u002F\n# Le propriétaire doit correspondre à l'utilisateur du serveur web\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Corriger les permissions\u003C\u002Fh3>\n\u003Cp>Pour un serveur Apache (utilisateur \u003Ccode>www-data\u003C\u002Fcode> sous Debian\u002FUbuntu) :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">\n# Propriétaire : utilisateur du serveur web\nsudo chown -R www-data:www-data \u002Fvar\u002Fwww\u002Fprestashop\u002F\n\n# Permissions recommandées\nsudo find \u002Fvar\u002Fwww\u002Fprestashop\u002F -type d -exec chmod 755 {} \\;\nsudo find \u002Fvar\u002Fwww\u002Fprestashop\u002F -type f -exec chmod 644 {} \\;\n\n# Répertoires nécessitant l'écriture\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fvar\u002F\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fimg\u002F\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fupload\u002F\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fdownload\u002F\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fconfig\u002F\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fcache\u002F\nsudo chmod -R 775 \u002Fvar\u002Fwww\u002Fprestashop\u002Fthemes\u002F\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cblockquote>\u003Cp>\u003Cstrong>Astuce de diagnostic\u003C\u002Fstrong> : en cas de doute, passez temporairement tout en 777 (\u003Ccode>chmod -R 777 \u002Fvar\u002Fwww\u002Fprestashop\u002F\u003C\u002Fcode>) pour confirmer que le problème vient bien des permissions. \u003Cstrong>Ne laissez jamais 777 en production\u003C\u002Fstrong> — c'est une faille de sécurité majeure. Revenez aux permissions correctes dès que le diagnostic est confirmé.\u003C\u002Fp>\u003C\u002Fblockquote>\n\u003Cp>Pour \u003Cstrong>PHP-FPM\u003C\u002Fstrong> (courant avec Nginx), l'utilisateur peut être différent. Vérifiez dans votre pool de configuration :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">\ngrep -E '^(user|group)' \u002Fetc\u002Fphp\u002F8.2\u002Ffpm\u002Fpool.d\u002Fwww.conf\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Étape 5 : purger le cache Symfony\u003C\u002Fh2>\n\u003Cp>Le cache Symfony est la cause numéro un des pages Symfony inaccessibles après migration. Le cache contient des \u003Cstrong>chemins absolus\u003C\u002Fstrong> compilés qui pointent encore vers l'ancien serveur.\u003C\u002Fp>\n\u003Ch3>Méthode recommandée : ligne de commande\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">\n# En production\nphp .\u002Fbin\u002Fconsole cache:clear --env=prod\n\n# Si vous êtes en mode debug\nphp .\u002Fbin\u002Fconsole cache:clear --env=dev\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Si la commande échoue\u003C\u002Fh3>\n\u003Cp>Il arrive que le cache soit tellement corrompu que même la commande \u003Ccode>cache:clear\u003C\u002Fcode> plante. Dans ce cas, supprimez manuellement les répertoires de cache :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">\nrm -rf var\u002Fcache\u002Fprod\u002F\nrm -rf var\u002Fcache\u002Fdev\u002F\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Puis rechargez une page du back-office : PrestaShop reconstruira automatiquement le cache.\u003C\u002Fp>\n\u003Ch3>Pour PrestaShop 8.x\u003C\u002Fh3>\n\u003Cp>PS 8.x utilise Symfony 4.4. La commande reste identique, mais assurez-vous d'utiliser la bonne version de PHP :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">\n# Vérifier la version PHP CLI\nphp -v\n\n# Si plusieurs versions coexistent, spécifiez le chemin\n\u002Fusr\u002Fbin\u002Fphp8.2 .\u002Fbin\u002Fconsole cache:clear --env=prod\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>PS 8.x exige PHP 8.1 minimum. Une migration depuis un serveur en PHP 7.4 nécessite de recompiler entièrement le cache avec la bonne version.\u003C\u002Fp>\n\u003Ch2>Étape 6 : mettre à jour les URLs en base de données\u003C\u002Fh2>\n\u003Cp>Étape souvent oubliée : la table \u003Ccode>ps_configuration\u003C\u002Fcode> contient les URLs du site en dur.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">\nSELECT name, value FROM ps_configuration \nWHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL', 'PS_SSL_ENABLED');\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Mettez à jour si nécessaire :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">\nUPDATE ps_configuration SET value = 'nouveau-domaine.com' \nWHERE name = 'PS_SHOP_DOMAIN';\n\nUPDATE ps_configuration SET value = 'nouveau-domaine.com' \nWHERE name = 'PS_SHOP_DOMAIN_SSL';\n\nUPDATE ps_configuration SET value = '1' \nWHERE name = 'PS_SSL_ENABLED';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Vérifiez aussi la table \u003Ccode>ps_shop_url\u003C\u002Fcode> :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">\nSELECT * FROM ps_shop_url;\n-- Mettez à jour domain et domain_ssl si nécessaire\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Checklist complète de migration\u003C\u002Fh2>\n\u003Cp>Voici l'ordre optimal pour migrer PrestaShop sans accroc :\u003C\u002Fp>\n\u003Col>\n\u003Cli>**Transférer les fichiers** (rsync ou tar, éviter le FTP pour les gros volumes)\u003C\u002Fli>\n\u003Cli>**Importer la base de données** (en ligne de commande, pas phpMyAdmin)\u003C\u002Fli>\n\u003Cli>**Mettre à jour `PS_SHOP_DOMAIN`** et `PS_SHOP_DOMAIN_SSL` en base\u003C\u002Fli>\n\u003Cli>**Corriger le propriétaire** des fichiers (`chown www-data:www-data`)\u003C\u002Fli>\n\u003Cli>**Appliquer les permissions** (755 dossiers, 644 fichiers, 775 pour var\u002Fimg\u002Fupload)\u003C\u002Fli>\n\u003Cli>**Supprimer le cache** (`rm -rf var\u002Fcache\u002Fprod\u002F var\u002Fcache\u002Fdev\u002F`)\u003C\u002Fli>\n\u003Cli>**Régénérer le .htaccess** via le back-office ou renommer l'ancien\u003C\u002Fli>\n\u003Cli>**Vérifier la version PHP** et les extensions requises\u003C\u002Fli>\n\u003Cli>**Tester le front-office ET le back-office** (pages legacy et Symfony)\u003C\u002Fli>\n\u003Cli>**Activer le mode production** (`define('_PS_MODE_DEV_', false);` dans `config\u002Fdefines.inc.php`)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Conclusion\u003C\u002Fh2>\n\u003Cp>La migration d'un site PrestaShop se résume à trois piliers : \u003Cstrong>permissions correctes\u003C\u002Fstrong>, \u003Cstrong>cache purgé\u003C\u002Fstrong>, et \u003Cstrong>URLs à jour en base de données\u003C\u002Fstrong>. En respectant la checklist ci-dessus dans l'ordre, vous éviterez 95 % des problèmes post-migration. En cas de doute, procédez toujours par élimination : un diagnostic structuré vaut mieux que des modifications à l'aveugle.\u003C\u002Fp>",[121,124,127,130,133,136,139,142,145,148,151,154,157,160,163],{"q":122,"a":123},"Pourquoi mon back-office PrestaShop affiche une page blanche après migration ?","Une page blanche après migration provient généralement d'un cache Symfony corrompu contenant les chemins absolus de l'ancien serveur. Supprimez les répertoires var\u002Fcache\u002Fprod\u002F et var\u002Fcache\u002Fdev\u002F, puis vérifiez que le propriétaire des fichiers correspond à l'utilisateur du serveur web (www-data pour Apache). Si le problème persiste, renommez le .htaccess pour isoler un éventuel conflit de réécriture d'URL.",{"q":125,"a":126},"Comment corriger les permissions de fichiers PrestaShop après un transfert serveur ?","Appliquez chown -R www-data:www-data sur la racine du site pour corriger le propriétaire. Les dossiers doivent être en 755 et les fichiers en 644. Les répertoires var\u002F, img\u002F, upload\u002F, download\u002F, config\u002F, cache\u002F et themes\u002F nécessitent un chmod 775 pour permettre l'écriture. Ne laissez jamais les permissions en 777 en production, c'est une faille de sécurité critique.",{"q":128,"a":129},"Quelle est la différence entre les pages legacy et Symfony dans le back-office PrestaShop ?","Les pages legacy utilisent les anciens controllers PHP de PrestaShop (URLs avec ?controller=AdminXxx). Les pages Symfony, introduites depuis PrestaShop 1.7.4, utilisent le framework Symfony embarqué (URLs avec \u002Fadmin\u002Findex.php\u002F...). Lors d'une migration, si les pages legacy fonctionnent mais pas les pages Symfony, le problème vient du cache Symfony qui contient des chemins compilés de l'ancien serveur. La commande php .\u002Fbin\u002Fconsole cache:clear --env=prod résout ce problème.",{"q":131,"a":132},"Faut-il modifier la base de données lors d'une migration PrestaShop ?","Oui. La table ps_configuration contient les valeurs PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL qui doivent pointer vers le nouveau domaine ou la nouvelle adresse. La table ps_shop_url doit également être mise à jour. Sans cette étape, PrestaShop peut générer des redirections en boucle ou des liens cassés sur l'ensemble du site.",{"q":134,"a":135},"Comment vider le cache Symfony de PrestaShop en ligne de commande ?","Exécutez php .\u002Fbin\u002Fconsole cache:clear --env=prod depuis la racine de votre installation PrestaShop. Si la commande échoue car le cache est trop corrompu, supprimez manuellement les dossiers var\u002Fcache\u002Fprod\u002F et var\u002Fcache\u002Fdev\u002F avec rm -rf. PrestaShop reconstruira le cache automatiquement au prochain chargement de page. Sur PrestaShop 8.x, assurez-vous d'utiliser PHP 8.1 ou supérieur.",{"q":137,"a":138},"Peut-on migrer PrestaShop avec phpMyAdmin ou faut-il utiliser la ligne de commande ?","Pour les petites bases de données (moins de 50 Mo), phpMyAdmin convient. Pour les bases volumineuses, utilisez impérativement la ligne de commande (mysql -u utilisateur -p nom_base \u003C dump.sql) car phpMyAdmin impose une limite de taille d'upload qui peut tronquer silencieusement votre fichier SQL, causant des tables incomplètes — notamment ps_tab qui gère le menu du back-office.",{"q":140,"a":141},"Pourquoi le menu du back-office PrestaShop est vide après migration ?","Un menu vide signifie que la table ps_tab n'a pas été correctement importée. Cette table contient la structure complète du menu d'administration. Vérifiez avec SELECT COUNT(*) FROM ps_tab : vous devez avoir environ 170 à 200 lignes selon votre version. Si le résultat est 0, réimportez votre dump SQL en vérifiant qu'il n'a pas été tronqué et que l'encodage est bien utf8mb4.",{"q":143,"a":144},"Comment migrer PrestaShop d'un serveur avec PHP 7.4 vers PHP 8.2 ?","Si vous migrez vers PrestaShop 8.x, PHP 8.1+ est obligatoire. Après le transfert des fichiers, supprimez intégralement var\u002Fcache\u002F car le cache compilé sous PHP 7.4 est incompatible avec PHP 8.2. Lancez ensuite php8.2 .\u002Fbin\u002Fconsole cache:clear --env=prod en spécifiant explicitement le binaire PHP 8.2 si plusieurs versions coexistent. Vérifiez aussi que les extensions PHP requises (intl, gd, curl, zip, mbstring) sont installées pour la nouvelle version.",{"q":146,"a":147},"La migration PrestaShop est-elle différente sur Nginx vs Apache ?","Oui. Sur Apache, PrestaShop utilise un fichier .htaccess pour la réécriture d'URL. Sur Nginx, le .htaccess est ignoré : les règles doivent être transposées dans la configuration Nginx du vhost. PrestaShop fournit un fichier d'exemple dans docs\u002Fnginx.conf.dist. Hormis cette différence, les étapes de migration (base de données, permissions, cache) restent identiques.",{"q":149,"a":150},"Comment vérifier que ma migration PrestaShop est complète et fonctionnelle ?","Testez dans cet ordre : 1) le front-office (page d'accueil, fiche produit, panier), 2) la page de login du back-office, 3) le dashboard, 4) une page Symfony comme le catalogue produits, 5) un passage de commande test. Vérifiez aussi que les images produits s'affichent, que les emails transactionnels partent correctement, et que le cron PrestaShop fonctionne (les tâches planifiées comme la mise à jour du taux de change).",{"q":152,"a":153},"Que faire si l'erreur 500 persiste après avoir tout vérifié ?","Activez le mode debug en modifiant config\u002Fdefines.inc.php : define('_PS_MODE_DEV_', true). Rechargez la page pour obtenir le message d'erreur détaillé. Consultez aussi les logs Apache (tail -f \u002Fvar\u002Flog\u002Fapache2\u002Ferror.log) ou PHP (le chemin est dans php.ini, directive error_log). Sur PrestaShop 8.x, les logs Symfony se trouvent dans var\u002Flogs\u002Fprod.log. Ne patchéz jamais à l'aveugle : identifiez d'abord l'erreur exacte.",{"q":155,"a":156},"Comment éviter les problèmes de migration PrestaShop à l'avenir ?","Trois bonnes pratiques : 1) Utilisez rsync plutôt que FTP pour le transfert de fichiers (il préserve les permissions et gère les interruptions). 2) Faites un dump SQL en ligne de commande avec mysqldump --single-transaction pour éviter les incohérences. 3) Testez la migration sur un sous-domaine temporaire avant de basculer le DNS. Cette approche vous permet de valider chaque étape sans impacter le site en production.",{"q":158,"a":159},"Les modules PrestaShop fonctionnent-ils automatiquement après une migration serveur ?","Pas toujours. Les modules qui stockent des chemins absolus dans leur configuration ou dans le cache peuvent dysfonctionner. Après migration, purgez le cache complet, puis désactivez et réactivez les modules problématiques depuis le back-office. Certains modules commerciaux vérifient aussi le domaine pour leur licence : contactez l'éditeur pour mettre à jour le domaine autorisé si nécessaire.",{"q":161,"a":162},"Comment transférer les fichiers PrestaShop efficacement vers un nouveau serveur ?","Privilégiez la méthode tar + rsync : créez une archive compressée sur l'ancien serveur (tar czf prestashop-backup.tar.gz \u002Fvar\u002Fwww\u002Fprestashop\u002F), transférez-la via rsync ou scp, puis décompressez sur le nouveau serveur. Cette méthode est plus fiable que le FTP qui peut corrompre silencieusement certains fichiers et ne préserve pas les permissions ni les liens symboliques.",{"q":164,"a":165},"Faut-il régénérer les .htaccess de PrestaShop après chaque migration ?","Oui, c'est recommandé. Le .htaccess principal et celui du dossier admin contiennent des règles de réécriture qui peuvent inclure des chemins spécifiques à l'ancien serveur. La méthode la plus sûre : renommez l'ancien .htaccess, accédez au back-office, puis régénérez-le via Paramètres de la boutique → Trafic et SEO en désactivant puis réactivant les URL simplifiées.","Lors d'une migration PrestaShop, les problèmes les plus fréquents sont le cache Symfony corrompu, les permissions fichiers incorrectes et le .htaccess obsolète. Diagnostiquez en distinguant pages legacy et Symfony, puis suivez la checklist : permissions (chown www-data), purge cache (rm -rf var\u002Fcache\u002F), régénération .htaccess et mise à jour des URLs en base de données.",6,"2026-03-21T13:51:36.000Z",[],"Rapports de bugs",{"items":172},[173,182,188,194,202,210,216,221],{"id":174,"type":175,"label":176,"href":84,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":179,"children":180,"psChildren":181},41,"link",{"fr":177},"Expertise",null,0,[],[],{"id":183,"type":175,"label":184,"href":75,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":185,"children":186,"psChildren":187},42,{"fr":74},1,[],[],{"id":189,"type":175,"label":190,"href":36,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":191,"children":192,"psChildren":193},43,{"fr":35},2,[],[],{"id":195,"type":175,"label":196,"href":198,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":199,"children":200,"psChildren":201},44,{"fr":197},"Outils IA","\u002Foutils-ia",3,[],[],{"id":203,"type":175,"label":204,"href":29,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":206,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":207,"children":208,"psChildren":209},45,{"fr":205},"Offre Starter ✨",{"highlight":20},4,[],[],{"id":211,"type":175,"label":212,"href":78,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":213,"children":214,"psChildren":215},46,{"fr":77},5,[],[],{"id":217,"type":175,"label":218,"href":96,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":167,"children":219,"psChildren":220},47,{"fr":92},[],[],{"id":222,"type":175,"label":223,"href":102,"icon":178,"description":178,"badge":178,"groupTitle":178,"style":178,"gridColumns":178,"cssClass":178,"psCategoryId":178,"showPsChildren":30,"position":224,"children":225,"psChildren":226},48,{"fr":101},7,[],[],{"footer":228},{"theme":229,"description":178,"hours":178,"logo":230,"contact":233,"social":234,"bottomBar":244},"dark",{"src":231,"href":232,"alt":95},"\u002Flogo-ac.svg","\u002F",{"email":178,"phone":178,"address":178,"cta":178},[235,238,241],{"platform":236,"href":237,"label":236},"linkedin","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Falexandre-carette\u002F",{"platform":239,"href":240,"label":239},"malt","https:\u002F\u002Fwww.malt.fr\u002Fprofile\u002Falexandrecarette",{"platform":242,"href":243,"label":242},"github","https:\u002F\u002Fgithub.com\u002Fprest4cafe",{"copyright":178},{"header":246},{"logo":247,"topBar":250,"contactEmail":253,"features":254,"navBar":178},{"src":231,"alt":248,"text":95,"href":232,"class":249},"Alexandre Carette — Architecte E-commerce Souverain","h-10 w-10",{"message":178,"showLanguages":30,"align":251,"languages":252},"left",[],"contact@alexandrecarette.fr",{"showSearch":30,"showWishlist":30,"showLogin":20,"showContact":30,"showCart":30,"stickyHeader":20,"headerLayout":255},"inline",{"academy":257,"blog":258,"expertise":269},[],[259,263,266],{"title":260,"url":261,"score":185,"type":262},"PrestaShop headless avec Nuxt 3 : pourquoi séparer back et front","\u002Fblog\u002Fprestashop\u002Farchitecture\u002Fprestashop-headless-nuxt-separation-front-back","blog",{"title":264,"url":265,"score":185,"type":262},"PrestaShop headless : Nuxt 3, pas Next.js — le choix souverain","\u002Fblog\u002Fprestashop\u002Farchitecture\u002Fprestashop-headless-nuxt-nextjs-souverainete",{"title":267,"url":268,"score":185,"type":262},"Sylius rachète PrestaShop : ce que ça change pour vous","\u002Fblog\u002Fprestashop\u002Farchitecture\u002Fsylius-rachat-prestashop-headless-souverainete",[]]