Comment choisir, installer et tester les modules PrestaShop

Ce que nous ferions

Nous définirions le résultat métier manquant, vérifierions les paramètres natifs et les modules déjà acquis, puis ne comparerions un nouveau module que si une lacune subsiste. La bonne démarche dépend de votre boutique existante : configuration, versions des modules, intégrations, personnalisations du thème, données du catalogue et des clients, marchés et équipe chargée de la maintenance. Remplacer un outil fonctionnel exige un bénéfice démontrable sur cette boutique.

Effectuez le changement choisi sur une copie de préproduction protégée représentative de la production, répétez sa configuration et son annulation, puis planifiez la bascule. Convenez de qui peut arrêter le déploiement, des preuves autorisant la réouverture et de la manière de rapprocher les commandes ou messages d'intégration si une reprise devient nécessaire. Ne remplacez pas la base d'une boutique en activité par une ancienne base de préproduction pour publier un paramètre de module.

Si vous avez besoin de comparer les candidats et de préparer le déploiement, le PrestaShop Module Selection & Fit Assessment teste les pistes sur une copie contrôlée de la boutique ; pour un module déjà choisi, le PrestaShop Module Installation & Configuration Service l'installe, applique les paramètres convenus et vérifie le parcours concerné.

Rédiger une exigence que vous pouvez accepter ou rejeter

Donnez le même cahier des charges à chaque candidat. Décrivez la tâche qui échoue aujourd'hui, qui la réalise et le résultat qui justifierait le changement. Distinguez les comportements essentiels de la présentation facultative pour qu'une longue liste de fonctions ne masque pas un besoin non couvert.

• Contexte de la boutique : versions exactes du cœur, du PHP web et du thème, modules et personnalisations concernés, langues, devises, boutiques et groupes de clients.
• Périmètre des données et intégrations : champs du catalogue, données clients ou états de commande concernés, destination suivante de ces données et système responsable de chaque valeur.
• Preuves d'acceptation : produit ou panier représentatif, étapes de reproduction, résultats attendus pour le client et le personnel, et comparaison avec la boutique actuelle.
• Contraintes d'exploitation : personne chargée de la configuration, accès nécessaires, surveillance des tâches de fond et responsable de la maintenance après passation.
• Conditions de sortie : paramètres et données à exporter ou conserver, effets attendus de la désactivation et de la désinstallation, et procédure de reprise si le changement échoue.

Par exemple, « améliorer la livraison » est trop vague pour être testé. « Proposer uniquement les transporteurs éligibles et recalculer le total TTC de livraison lorsqu'un client existant change d'adresse, puis exporter le service choisi vers notre système de commandes » fournit au prestataire un parcours concret à démontrer. Une capture d'écran d'un sélecteur de transporteur ne répond qu'à une partie de ce besoin.

Vérifier la compatibilité exacte avec PrestaShop et PHP

Consignez votre version complète de PrestaShop, la version de PHP utilisée par le serveur web, celle du thème et les modules installés sous Paramètres avancés > Informations et dans le gestionnaire de modules. Une mention telle que « compatible 1.7 » est moins utile qu'une version nommée et une combinaison PHP testée.

La déclaration de compatibilité du cœur est $this->ps_versions_compliancy dans la classe PHP principale du module. Par exemple, cette déclaration utilise la version de la boutique en cours d'exécution comme borne supérieure :

$this->ps_versions_compliancy = [
    'min' => '1.6.1.0',
    'max' => _PS_VERSION_,
];

Une plage déclarée constitue une contrainte d'installation, pas un rapport de test. Le PHP du module s'exécute avec les permissions de la boutique et peut accéder à sa base, aux données clients et aux fichiers accessibles en écriture : les seuls contrôles dans le navigateur ne prouvent donc pas la sûreté du code. Lisez séparément les contraintes PHP et de bibliothèques de Composer. L'environnement PHP doit satisfaire à la fois le cœur, le module et ses dépendances. Une nouvelle syntaxe peut échouer avant qu'un module n'affiche une erreur utile. N'abaissez pas une exigence dans le code pour contourner le contrôle.

Fixez chaque environnement de test à des versions exactes du cœur et de PHP. Pour les tests historiques, PrestaShop 1.7.6 ne prend en charge PHP que jusqu'à 7.2 ; 1.7.8 jusqu'à 7.4 ; et PrestaShop 8.0 à 8.2 jusqu'à 8.1. Ces anciennes combinaisons sont des références de compatibilité, pas des recommandations d'hébergement actuelles.

Les prérequis de PrestaShop 9 distinguent 9.0, qui prend en charge PHP 8.1 à 8.4, de 9.1, qui prend en charge PHP 8.1 à 8.5. Vérifiez les prérequis de votre version cible exacte, y compris 9.2, avant de choisir son environnement d'exécution. Exécutez les tests pertinents sur 9.2 ainsi que sur toute version plus ancienne que vous prenez en charge.

Examinez override/, les scripts d'installation et de mise à niveau, les définitions de services et les fichiers copiés hors du module. Un répertoire de surcharges vide indique seulement l'absence de surcharges classiques. Recherchez aussi les enregistrements de hooks, puis comparez-les aux enregistrements réellement installés pour chaque boutique.

Préparer une préproduction et une sauvegarde restaurable

Votre copie de préproduction doit correspondre à la production pour le cœur, PHP et ses extensions, le moteur de base de données, le thème, les modules, les paramètres de boutique et la configuration serveur. Comparez le contexte multiboutique, les langues, devises, caches et connexions sortantes. Une démo vierge est utile pour voir une fonctionnalité ; elle ne reproduit pas les interactions de votre boutique.

Protégez la copie de l'accès public et de l'indexation. Supprimez ou anonymisez les données clients lorsque c'est possible. Désactivez les captures réelles de paiement, les e-mails clients, les webhooks de production et les intégrations planifiées. Utilisez des identifiants de paiement sandbox et une boîte de réception contrôlée.

1. Sauvegardez ensemble tous les fichiers de la boutique et la base de données, y compris les surcharges, personnalisations du thème et la configuration.
2. Conservez le ZIP exact du module actuel, sa version et un export de configuration s'il est disponible.
3. Stockez les sauvegardes hors de la racine web publique et confirmez que vous pouvez les restaurer.
4. Consignez un état de référence des pages et parcours que vous testerez.

Pour une base InnoDB, un développeur peut utiliser un export logique cohérent tel que celui-ci depuis un répertoire privé de sauvegarde. Remplacez la base et le compte par vos vraies valeurs ; coordonnez séparément les écritures et les éventuelles tables non transactionnelles.

mysqldump --single-transaction -u backupuser -p prestashop > before-module.sql

Consultez le guide de préproduction et le guide de sauvegarde pour la préparation globale.

Installer le ZIP et diagnostiquer les échecs de téléversement

Dans PrestaShop 8 et 9, ouvrez Modules > Gestionnaire de modules > Installer un module et téléversez le ZIP installable tel qu'il est fourni. Conservez son nom de dossier technique intact. Par exemple, mprcanonicalmanager/mprcanonicalmanager.php se place sous modules/mprcanonicalmanager/, avec ses dépendances et autres répertoires à côté du fichier principal.

Un téléchargement du dépôt peut contenir un répertoire englobant supplémentaire ou omettre les dépendances préparées. Utilisez le paquet de distribution destiné à l'installation. La copie de fichiers seule n'exécute pas install(), qui peut créer des tables, enregistrer des hooks, ajouter des écrans d'administration et initialiser les valeurs par défaut.

Si le téléversement par navigateur échoue, comparez la taille de l'archive aux valeurs effectives web de upload_max_filesize et post_max_size. La seconde doit aussi accueillir le reste de la requête POST. La page Informations montre certaines valeurs PHP ; obtenez post_max_size depuis les paramètres PHP de votre hébergement ou un diagnostic privé de l'environnement web. La commande CLI php -i peut lire une configuration différente.

; Example limits for a ZIP smaller than 64 MB
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300

Ce sont des exemples, pas des exigences minimales pour chaque module. Vérifiez aussi les limites de taille du corps des requêtes du proxy et du serveur web, le stockage temporaire, l'espace d'extraction, les extensions requises et les permissions d'écriture. Utilisez les directives php_value dans .htaccess uniquement lorsque l'intégration PHP d'Apache les prend en charge ; ce n'est pas une solution générale pour PHP-FPM.

Si nécessaire, extrayez le ZIP localement et téléversez son unique répertoire technique de module par SFTP. Utilisez ensuite le gestionnaire de modules pour l'installer. Confirmez le propriétaire des fichiers et l'accès de l'utilisateur PHP effectif plutôt que d'accorder des droits d'écriture à tous.

Surveillez var/logs/ et les journaux PHP-FPM et du serveur web pendant l'installation. Paramètres avancés > Logs est une autre source possible, mais les échecs précoces peuvent ne jamais atteindre ce journal. Un module visible sur disque peut avoir échoué pendant la création des tables, l'enregistrement des hooks, le chargement des dépendances ou une autre étape d'installation. Conservez l'erreur et vérifiez l'état partiel avant de réessayer. Ne supprimez pas aveuglément les tables du module ou les rôles d'autorisation.

Après la réussite, ouvrez Configurer, renseignez les paramètres marchands nécessaires, enregistrez et rechargez. Vérifiez les permissions, traductions, entrées de menu et le contexte de boutique voulu.

Exécuter les tests fonctionnels et de non-régression

Transformez la liste documentée des fonctions et votre cahier des charges en liste de vérification avec résultats attendus. Testez la persistance de la configuration, les permissions et tous les types de pages concernés. Utilisez les mêmes données avant et après l'installation. Conservez ensemble le ZIP du module, la configuration, les étapes de test, les résultats attendus et obtenus, et les preuves anonymisées pour qu'un fournisseur puisse reproduire un échec.

1. Ajoutez un produit au panier depuis sa fiche, une catégorie et les résultats de recherche. Ces points d'entrée peuvent avoir un balisage et un JavaScript différents, même si la modification du panier atteint le même CartController.
2. Terminez une commande en mode sandbox. Confirmez les produits, déclinaisons, adresses, choix de livraison, taxes, remises, devise et totaux dans la commande et le système de paiement.
3. Inscrivez un client, vérifiez l'e-mail attendu, déconnectez-vous et reconnectez-vous. Vérifiez l'historique du compte.
4. Testez les recherches prises en charge par votre boutique, notamment les noms de produits, références et EAN lorsqu'ils sont indexés.
5. Ouvrez les détails d'une commande dans l'administration. Vérifiez les informations transporteur, les onglets, les notes et les permissions du personnel concerné.
6. Videz le panier et répétez les interactions clés sur mobile, y compris dans une fenêtre étroite, par exemple de 375 pixels.
7. Passez dans chaque langue, devise et boutique concernée. Confirmez que les paramètres et contenus restent dans leur périmètre prévu.

Dans les outils de développement du navigateur, examinez les erreurs de console, requêtes AJAX échouées, erreurs 404 de ressources et hôtes externes inattendus. Visitez les pages où la fonction apparaît et celles où elle ne doit rien faire. Vérifiez les copies de templates de modules du thème sous themes/your-theme/modules/ lorsqu'une fonctionnalité mise à jour n'apparaît pas.

Vérifiez séparément les tâches planifiées et les webhooks. Confirmez leur authentification, leur fréquence, leur destination et leur gestion des échecs. Un chargement de page réussi ne prouve pas que le travail d'arrière-plan réussit.

Tester un module concluant en démonstration mais défaillant sur votre boutique

Supposons que vous testiez un bloc de recommandations produits sur une boutique multilingue avec déclinaisons et export de commandes. La démonstration prouve que les recommandations s'affichent. Votre test d'acceptation doit aussi prouver que les clients achètent toujours l'article voulu et que le personnel reçoit la bonne commande.

Si l'ajout au panier depuis une catégorie fonctionnait avant l'installation et échoue désormais, conservez cette comparaison et arrêtez le déploiement. Isolez l'interaction avec les contrôles de conflit ci-dessous, puis répétez le même jeu de test après correction. La réussite du test d'affichage des recommandations ne compense pas un parcours d'achat cassé.

Mesurer les ressources, requêtes et dépendances externes

Comparez des chargements de page répétés dans les mêmes conditions. Distinguez les résultats avec cache froid et cache chaud. Consignez le temps de réponse serveur, le nombre de requêtes, le volume transféré et les requêtes lentes. Fixez un budget de performance acceptable pour votre boutique plutôt que de considérer un seuil fixe en millisecondes comme universel.

Les modules ont des empreintes différentes. Un outil d'administration peut n'ajouter aucune ressource en boutique ; une fonction conditionnelle peut ne s'exécuter que sur certaines requêtes. Comptez les hooks, requêtes et ressources réellement exécutés. Profilez les appels répétés à la base de données dans les boucles de produits et les requêtes externes synchrones pendant le rendu des pages.

Le mode debug et le profilage sont distincts. L'ancien profileur de requêtes et de durées utilise _PS_DEBUG_PROFILING_ dans config/defines.inc.php. Le profileur Symfony s'applique aux requêtes Symfony éligibles lorsqu'il est configuré. Aucun ne garantit une ventilation des durées pour chaque requête de boutique ou requête échouée. Utilisez le profilage brièvement sur une préproduction protégée.

Préférez registerStylesheet() et l'API de scripts correspondante pour gérer les ressources et l'intégration CCC. Vérifiez aussi le versionnement explicite et l'invalidation au déploiement. L'enregistrement ne garantit pas automatiquement l'invalidation des caches, et un lien brut ne devient pas une erreur 404 simplement parce que vous videz le cache.

Vous pouvez lister les hôtes de ressources observés par la page actuelle avec cet exemple dans la console du navigateur :

const hosts = {};
for (const entry of performance.getEntriesByType('resource')) {
    const host = new URL(entry.name, location.href).host;
    if (host && host !== location.host) {
        hosts[host] = (hosts[host] || 0) + 1;
    }
}
console.table(hosts);

Examinez aussi vos propres sous-domaines CDN, en plus des tiers. Cette liste couvre les ressources observées par le navigateur, pas le trafic entre serveurs ni toutes les formes de transfert de données. Demandez pourquoi un nouvel hôte est nécessaire, quelles données il reçoit et comment la fonction réagit à son indisponibilité. Répétez l'observation avec les états de consentement et de connexion concernés, car une requête peut n'apparaître qu'après une interaction ou un changement d'autorisation.

En préproduction, utilisez le blocage des requêtes du navigateur pour simuler l'indisponibilité d'un hôte externe propre à la fonction, puis testez de nouveau la page. Consignez si la fonction facultative échoue clairement et si la navigation et l'achat restent possibles. Ce test couvre uniquement la dépendance du navigateur ; faites simuler séparément par le développeur les délais d'attente côté serveur et les appels de fond échoués.

Tester les mises à jour et préparer un retour arrière complet

Lisez le journal des modifications et les prérequis avant de remplacer les fichiers. Sauvegardez les fichiers et la base, consignez la version installée et conservez les deux ZIP. Testez une mise à niveau depuis la version réellement en production, pas seulement une installation neuve de la nouvelle version.

Utilisez le parcours de mise à jour ou de téléversement ZIP pris en charge par le gestionnaire de modules. Vérifiez que la version installée en base progresse et que les migrations upgrade/install-X.Y.Z.php applicables aboutissent. La copie de nouveaux fichiers par SFTP seule ne prouve pas que les migrations se sont exécutées.

La configuration réside souvent en base de données, mais le code de mise à niveau peut la modifier ou la supprimer. Comparez les paramètres enregistrés, tables personnalisées, hooks, permissions et copies de templates du thème après la mise à jour. Traitez Réinitialiser séparément : cette action peut désinstaller puis réinstaller un module, avec un traitement des données dépendant de l'implémentation et des options de conservation. Ce n'est pas un remplacement sûr d'une migration.

Testez l'installation initiale, la mise à jour, la désactivation, la réactivation et la désinstallation comme des opérations distinctes sur des copies jetables. Comparez chaque résultat à la politique de conservation documentée. Une désinstallation propre peut volontairement conserver les avis ou données d'intégration ; tout supprimer n'est pas automatiquement correct. Exportez les données nécessaires avant de tester un nettoyage destructif.

Préférez Paramètres avancés > Performances > Vider le cache. Une purge CLI coordonnée peut aussi convenir :

php bin/console cache:clear --env=prod

Exécutez-la depuis la racine de la boutique avec le bon binaire PHP et le bon utilisateur du système de fichiers. Si une récupération par le système de fichiers est nécessaire, arrêtez le trafic entrant et les processus de traitement, confirmez les chemins et propriétaires des caches, reconstruisez le cache et vérifiez la boutique avant de rouvrir. Le cache PrestaShop est régénérable ; les requêtes simultanées, dépendances manquantes et permissions peuvent faire échouer sa reconstruction. Coordonnez séparément l'OPcache web et les éventuels caches de page complète, proxy ou CDN.

Lorsqu'un retour à une version antérieure est nécessaire

1. Mettez la boutique en production concernée en maintenance et arrêtez les tâches pouvant écrire des données liées.
2. Enregistrez l'état défaillant, les journaux et les détails des transactions récentes pour le diagnostic.
3. Restaurez un répertoire propre de l'ancien module sans mélanger les versions. Gardez la copie déplacée hors du répertoire public des modules.
4. Restaurez l'état correspondant de la base ou appliquez une migration inverse fournie par un développeur. Les fichiers seuls ne peuvent pas annuler les changements de schéma ou de données.
5. Rapprochez les commandes, paiements et changements de stock effectués après la sauvegarde. N'écrasez pas les nouvelles transactions réelles avec un ancien instantané complet de la boutique.
6. Videz les caches concernés et répétez les tests de fonctionnalité, de configuration et de commande.

N'utilisez pas Désinstaller ou Supprimer comme étape de retour à une ancienne version, sauf si vous comprenez leur nettoyage. Un module peut supprimer intentionnellement ses tables et paramètres. Obtenez le ZIP exact de l'ancienne version depuis une archive de versions ou le support plutôt que de supposer que chaque compte donne accès aux versions antérieures.

Isoler les échecs et résoudre les personnalisations qui se chevauchent

En préproduction, reproduisez l'échec avec les deux modules suspects, chacun seul et aucun des deux. Consignez l'état après chaque changement. Pour un ensemble plus grand, désactivez un groupe contrôlé, puis réduisez le périmètre. Testez les dépendances et les combinaisons : le dernier module activé peut révéler une interaction sans en être la seule cause.

Plusieurs modules peuvent partager un hook. La position peut compter pour le rendu, mais l'ordre n'est pas une solution universelle. Comparez les modifications de panier, données renvoyées, écouteurs d'événements, sélecteurs CSS, bibliothèques incluses, templates et configurations. Les hooks et services Symfony réduisent le couplage direct au cœur ; ils ne garantissent pas un fonctionnement sans conflit.

Le cœur peut fusionner des surcharges ajoutant des méthodes différentes à une même classe. Les méthodes, propriétés ou constantes communes peuvent déclencher un conflit explicite. Ne fusionnez pas au préalable deux méthodes en supposant que le prochain installateur les acceptera. Organisez un correctif de compatibilité avec un responsable unique de l'implémentation combinée et une procédure documentée d'installation, de mise à niveau et de suppression.

Examinez les fichiers de surcharge, leurs commentaires d'appartenance, les paramètres de surcharge actifs et les entrées de chemin de l'index des classes. Une liste de noms de classes ne suffit pas à identifier les propriétaires ni à prouver qu'un fichier est orphelin. Un fichier sur disque ne s'exécute pas automatiquement sur chaque page ; une surcharge est utilisée lorsque sa classe associée est chargée.

Si le back-office est inaccessible, utilisez si possible l'action normale de désactivation ou la commande console prise en charge. Renommer le répertoire d'un module est une isolation d'urgence des fichiers et nécessite un retour documenté. Cela ne désinstalle pas les surcharges et n'annule pas les services compilés ou les changements en base. Conservez les journaux avant de vider les caches. Pour une réponse vide, examinez le statut HTTP et les journaux serveur ; n'utilisez l'affichage de debug que sur une copie protégée et désactivez-le ensuite, car il peut révéler une configuration sensible.

Consultez le dépannage PrestaShop pour une récupération selon le symptôme.

Automatiser les contrôles du paquet de distribution

Pour le développement de modules, utilisez PHPUnit pour la logique métier testable indépendamment, comme les calculs et le formatage. Ajoutez des tests d'intégration pour l'installation, les migrations, les hooks et le stockage propre à chaque boutique. Utilisez des tests navigateur pour les parcours clients importants, tels que la connexion, l'ajout au panier et la commande.

Construisez une matrice des combinaisons exactes de cœur, PHP, base de données et thème prises en charge. Incluez les versions cibles actuelles et la plus ancienne dont vous revendiquez réellement la prise en charge. Conservez les résultats de test avec le ZIP de distribution ou le commit exact, pas simplement avec une plage de compatibilité du code source.

Un pipeline CI peut construire l'archive, vérifier les dépendances et la syntaxe, l'installer sur des boutiques vierges, effectuer les mises à niveau depuis les versions précédentes du module prises en charge et exécuter des tests navigateur de bon fonctionnement. Les analyses statiques d'API obsolètes complètent les tests d'exécution ; elles ne les remplacent pas. Testez la désinstallation et la conservation documentée des données sur des copies jetables.

Évaluer les offres, vendeurs et conditions d'achat

Utilisez votre cahier des charges pour comparer les fiches. Comparez la même fonction sur votre propre catalogue avec une démonstration ou un essai si disponible. Installez les candidats séparément avant de tester une combinaison prévue. Une démonstration fournisseur montre le comportement attendu ; demandez quelle évaluation contrôlée est possible sur votre boutique réelle et si la licence autorise une installation privée en préproduction.

• Compatibilité : obtenez les prérequis précis du cœur, de PHP et du thème, y compris les limitations connues.
• Maintenance : lisez les versions datées, les réponses aux problèmes et les correctifs de sécurité. Une ancienne date de version nécessite du contexte ; elle ne prouve pas à elle seule l'abandon.
• Documentation : recherchez les prérequis, la configuration, la conservation des données, les tâches d'arrière-plan et les étapes de récupération.
• Avis : préférez les descriptions d'une configuration réelle et du résultat du support à une moyenne d'étoiles.
• Accès au code : vérifiez si votre développeur peut l'examiner et le maintenir. Les modifications non documentées du cœur ou les dépendances opaques méritent un examen.
• Sécurité : recherchez le nom technique exact et la version dans Friends of Presta et les avis du mainteneur. L'absence d'avis publié ne prouve pas la sûreté. Comparez les versions concernées, la gravité et les correctifs disponibles ; un nombre brut d'avis peut refléter l'attention portée à l'examen d'un module.

Les examens de la Marketplace et les programmes qualité sont des signaux utiles, mais votre boutique nécessite toujours des tests en préproduction. Un vendeur direct, un vendeur de marketplace, un projet open source maintenu ou un développeur sur mesure peuvent tous convenir. Comparez le périmètre de licence, le prix TTC, le renouvellement, les mises à jour, le support, les travaux sur mesure et les conditions de litige de l'offre réelle. Évaluez l'implémentation et la maintenance du module réel.

La FAQ du support et des mises à jour de la Marketplace décrit Business Care et les conditions de remboursement des achats de modules et thèmes sur la Marketplace. Pour les achats concernés par cette FAQ, Business Care inclut la première année à l'achat et prévoit un renouvellement automatique. Les demandes de remboursement doivent être écrites ; l'éligibilité inclut certains problèmes dans un délai d'un mois, avec un contact préalable du vendeur pertinent en cas de dysfonctionnement. Revérifiez ces conditions pour votre achat, votre produit et votre pays avant de payer, consignez les conditions et leur date, et conservez l'échange avec le support. Ne présumez ni d'un remboursement ni d'un délai de réponse.

Les offres gratuites peuvent être des projets communautaires, des éditions allégées, des intégrations liées à un service ou des produits arrêtés. Lisez leurs limites réelles et obligations de support. L'exigence d'un compte tiers peut être légitime. Examinez la finalité des données, les destinataires, la conservation et les conditions contractuelles plutôt que de considérer l'inscription comme une preuve de collecte abusive de données.

Estimez le coût total à partir de vos coûts réels de licence, de mise en œuvre, d'hébergement, de maintenance, de support et de migration. La gratuité n'implique pas un manque de sûreté, et le paiement ne garantit pas un support durable. Incluez la formation du personnel, les services externes récurrents, l'export des données et le retrait. Comparez les candidats sur la même période avec les conditions réelles des fournisseurs et les tarifs de votre équipe.

Un outil gratuit peut répondre à une tâche définie : Security Scan signale des problèmes de sécurité locaux avec leur emplacement et leur gravité, et fournit les étapes de correction manuelle. Il ne corrige pas la boutique et ne certifie pas la sûreté d'un module candidat. Utilisez un résultat pour orienter l'analyse, puis démontrez le comportement concerné en préproduction.

Questions à poser au développeur ou à l'agence

• Quelle version avez-vous testée sur cette combinaison exacte de cœur, PHP et thème, et quels modules ou intégrations installés nécessitent un travail de compatibilité distinct ?
• Pouvez-vous démontrer le parcours d'acceptation avec nos données représentatives, y compris ses cas d'échec et de reprise, plutôt que montrer seulement un écran de paramètres ?
• La licence couvre-t-elle nos boutiques et notre domaine privé de préproduction, et qui reçoit les téléchargements, mises à jour et le support si nous changeons d'agence ?
• Quels paramètres, tables, surcharges, tâches planifiées et services externes changent, et que reste-t-il après désactivation ou désinstallation ?
• Qui corrige une interaction entre fournisseurs, quels travaux de support sont inclus et qui maintient un correctif de compatibilité spécifique ?
• Quelles preuves recevrons-nous lors de la passation, et qui est responsable du retour arrière et du rapprochement des nouvelles commandes si le lancement échoue ?

Auditer les modules déjà installés

Listez les modules actifs et inactifs, leurs responsables, versions, objectifs métier, dépendances et état de préparation aux mises à jour. Indiquez pour chacun s'il faut le conserver, le configurer, le mettre à jour, le remplacer ou le retirer, avec un responsable nommé pour la décision. Ne retirez les fonctions redondantes qu'après vérification de leurs dépendances. Désactivez d'abord pour un test réversible, puis désinstallez par l'action prise en charge et supprimez les fichiers inutilisés selon le plan de conservation.

Ne déduisez pas l'inutilisation d'un bloc vide en boutique. Un module apparemment inactif peut exporter des commandes, fournir une action d'administration ou exécuter un flux occasionnel. Interrogez le membre du personnel responsable de ce processus et observez l'exécution planifiée concernée avant de le retirer. Supprimer une dépendance sans widget visible peut casser une intégration fonctionnelle.

La désactivation normale empêche le parcours ModuleFrontController standard d'un module inactif. Elle ne retire pas les points d'accès PHP autonomes, les surcharges installées ou tout le code d'intégration. Les fichiers résiduels méritent un examen de sécurité même lorsqu'ils n'ajoutent aucun coût d'exécution mesuré.

Ces exemples en lecture seule utilisent ps_. Remplacez-le par votre préfixe réel. En multiboutique, examinez aussi les associations de boutiques ; l'indicateur actif global n'est pas un inventaire complet boutique par boutique.

SELECT name, version, active
FROM ps_module
ORDER BY active ASC, name;

SELECT hm.id_module, hm.id_hook, h.name AS hook_name
FROM ps_hook_module hm
LEFT JOIN ps_module m ON m.id_module = hm.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.id_module IS NULL;

SELECT m.name, COUNT(*) AS registrations
FROM ps_hook_module hm
JOIN ps_module m ON m.id_module = hm.id_module
GROUP BY m.name
ORDER BY registrations DESC;

Les enregistrements de hooks peuvent inclure des lignes distinctes par boutique, et un nombre élevé ne prouve pas une exécution coûteuse. Examinez les enregistrements orphelins plutôt que de supprimer des lignes manuellement. Comparez la structure de la base avant et après installation et désinstallation, y compris les données conservées documentées. Les contrôles de fichiers sous override/classes/ et override/controllers/ complètent l'inventaire de la base.

Lors de l'examen du code SQL, préférez la liaison de paramètres lorsqu'elle est disponible. Dans l'ancien code, vérifiez l'échappement des valeurs adapté au contexte, les conversions en entiers et la gestion des identifiants. Suivez le chemin des entrées non fiables jusqu'à chaque requête et vérifiez comment ce contexte est protégé.

Choisir les fonctions selon les lacunes réelles de votre boutique

Vérifiez d'abord les fonctions natives. Il n'existe pas d'ensemble universel de modules essentiels ni de seuil de nombre de produits rendant une extension obligatoire.

La documentation du tunnel de commande natif sur une page explique les changements de compatibilité de la version 9.2. Consultez les pages d'aide des modules liées pour les détails de configuration.

Prendre les décisions de lancement avant qu'elles affectent les données réelles

Fixez une politique d'URL stable avant de publier des liens. Le cœur génère les URL à partir des routes et des données d'entités actuelles ; les produits ne stockent pas une URL complète immuable à leur création. Les identifiants numériques ne créent pas à eux seuls du contenu dupliqué. Examinez les catégories par défaut, la redirection canonique et les liens générés par le thème avant de changer les routes. Établissez la correspondance des anciennes URL publiées lorsqu'un changement exige des redirections.

Définissez tôt les métadonnées et la politique de données structurées, puis examinez les résultats réels. Les entités existantes peuvent recevoir des modèles de métadonnées en masse dans SEO Revolution ; distinguez les modifications de métadonnées stockées de l'affichage dynamique. Vous n'avez pas à tout compléter manuellement.

Convenez de la politique de facturation avec votre comptable avant d'émettre des factures. Leur création dépend des paramètres de facturation et de l'indicateur de facture de l'état de commande. Le cœur prend en charge les préfixes, un numéro de départ et la remise à zéro annuelle. Appliquez les règles de correction et d'audit de votre juridiction lorsque vous modifiez des documents émis ou leur numérotation.

Décidez des données clients réellement nécessaires à l'inscription. Le mode B2B natif fournit les champs d'entreprise et d'identification ; les données personnalisées exigent une extension de champs adaptée et une finalité de collecte licite. Customer Extra Info (IP Ban) n'est pas un créateur de champs d'inscription. Prévoyez comment les clients existants pourront fournir toute nouvelle donnée obligatoire.

Configurez si possible les outils d'analyse et l'accès à Search Console avant les campagnes. Le suivi ne peut pas recréer des événements d'interaction non collectés. Respectez les exigences de consentement et vérifiez la référence initiale avant de l'utiliser pour décider. Testez le tunnel de commande avant le lancement ; un remplacement payant doit apporter un bénéfice démontré de fonctionnalité ou de compatibilité pour votre boutique.

Ajoutez chat, fidélité, widgets sociaux et autres fonctions de présentation lorsque vous pouvez en nommer l'objectif et en mesurer l'effet. Installez un changement à la fois. Après le déploiement en production, répétez les vérifications critiques et surveillez les journaux. Si vous avez besoin d'aide pour un module MPR, envoyez sa version, votre environnement, les étapes de reproduction, les résultats attendus et obtenus, et les journaux anonymisés via le support.

Décider si le changement testé peut passer en production

Utilisez les résultats comme décision de mise en production, pas comme note moyenne. Un défaut de commande non résolu, un accès incorrect aux données clients, un transfert de données inexpliqué ou une reprise non démontrée bloque le lancement même si les autres contrôles réussissent. Consignez explicitement les limites mineures, avec un responsable et une action convenue.

1. Figez le paquet testé et consignez sa version, ses dépendances, ses paramètres et la configuration exacte de boutique utilisée. Examinez les changements intervenus en production depuis la création de la copie.
2. Obtenez l'acceptation des résultats client et personnel par le responsable métier. Assurez-vous que les personnes traitant les commandes connaissent les changements et l'emplacement des échecs.
3. Choisissez le créneau de déploiement, sauvegardez les fichiers et la base correspondants, et confirmez les étapes de retour arrière répétées. Suspendez les tâches et le trafic concernés si la migration l'exige.
4. Appliquez en production l'installation ou la mise à jour prise en charge et la configuration consignée. Vérifiez le contexte de boutique, les identifiants et les points d'accès prévus ; les valeurs de test de préproduction ne doivent pas devenir silencieusement des paramètres de production.
5. Effectuez les contrôles critiques en production adaptés au module, selon la procédure autorisée par tout prestataire concerné. Vérifiez la commande, l'email ou l'enregistrement transmis obtenu, en plus de la page visible.
6. Relancez volontairement les tâches concernées, surveillez les journaux et files d'intégration, et désignez la personne qui réagit à un contrôle échoué. Si vous annulez le changement, préservez et rapprochez les transactions créées pendant ce créneau.

Remettez à l'équipe les paramètres finaux, le paquet conservé, les preuves de test, les limites connues, le contact du support et la procédure de reprise. Réutilisez les contrôles pertinents après le prochain changement de cœur, de PHP, de thème ou d'intégration ; un ancien rapport d'acceptation décrit la configuration qui avait réussi à ce moment-là.

Questions des commerçants

À partir de combien de modules en a-t-on trop ?

Utilisez l'inventaire pour identifier les modules sans objectif métier ni mainteneur, et les tests mesurés pour repérer les interactions coûteuses. Le nombre seul ne dit pas si une boutique très active est saine ou si une boutique presque vide présente un défaut grave.

Puis-je effectuer les vérifications moi-même ?

Vous pouvez comparer les comportements visibles, les paramètres enregistrés et les requêtes du navigateur en préproduction. Demandez à un développeur d'examiner les changements de schéma, les permissions, les appels côté serveur et les migrations que vous ne pouvez pas évaluer. Une liste de contrôles navigateur réussie est une preuve utile, pas un audit complet du code ou de la sécurité.

Un badge Marketplace, une licence payante ou un scan récent garantit-il la sûreté ?

Non. Chacun éclaire une partie de la décision d'achat. Exigez des preuves pour votre configuration réelle, examinez les résultats critiques et assurez-vous d'avoir un mainteneur et une procédure de reprise avant le lancement.

Faut-il mettre à jour un ancien module ou le remplacer ?

Demandez si une mise à jour prise en charge satisfait le besoin et préserve vos données et personnalisations. Sinon, comparez le remplacement ou un développement ciblé, avec les coûts de migration et de retrait. Conservez la version restaurable pendant que vous testez la piste choisie.

Une désinstallation réussie prouve-t-elle que le retour arrière fonctionnera ?

Testez la reprise que vous utiliseriez réellement après une mise à jour échouée. La désinstallation peut supprimer des données, tandis qu'un retour à une ancienne version peut exiger des fichiers et modifications de base correspondants. Réservez le test de désinstallation à une copie jetable et utilisez la procédure documentée de reprise pour les données commerciales.

Puis-je ajouter ces fonctions à une boutique déjà en activité ?

Oui. Définissez l'effet sur les données existantes, les URL publiées, les documents émis et les systèmes connectés, puis testez le changement sur une copie. Utilisez des mises à jour en masse ou migrations prises en charge si nécessaire et planifiez la bascule ; ajouter une fonction n'exige pas automatiquement de reconstruire la boutique.