Il y a un ticket d’assistance en particulier que je redoute par-dessus tout. Un marchand met à jour un module ; la mise à jour semble se dérouler sans problème, puis quelque chose dysfonctionne. Jamais toute la boutique. Une page du contrôleur PrestaShop qui dysfonctionne, une valeur de configuration qui refuse de s’enregistrer, ou une colonne de liste qui se vide. Lorsque je vérifie, le code du module est bien à jour, mais la base de données sous-jacente est toujours à jour.
Cet article traite précisément de cette lacune. Un module PrestaShop ne se limite pas au code PHP que vous avez déployé ; il inclut également les tables et colonnes nécessaires à son fonctionnement. Si vous omettez la mise à jour de la base de données PrestaShop, normalement incluse lors de chaque nouvelle version, vous vous retrouvez avec un module installé, apparemment fonctionnel, mais en réalité défectueux.
Je me suis fait ça à moi-même plus d’une fois. Voici ce que j’en ai appris. Mises à jour de la base de données des modules PrestaShop, de manière difficile.
1.0 Comment les mises à jour des modules PrestaShop gèrent la base de données
[Caption id = “attachment_840862” align = largeur “de AlignCenter” = “1237”]
De nombreuses suppositions circulent ici, et certaines sont fausses.
Déposez une nouvelle version dans /modules/ et votre routine d’installation ne se relance pas. Les tables restent intactes. Ce qui se passe à la place : PrestaShop lit le module améliorer/dossier, trouve les fichiers nommés mise à niveau- .php .Il se place entre la version enregistrée et celle déclarée par votre classe de module, et les exécute dans l’ordre.
Un magasin sur 1.9.0 recevant 2.1.0 exécute trois scripts, dans l’ordre.
Il en découle trois choses, et toutes trois sont importantes pour les modifications de la base de données PrestaShop.
La version figurant dans la table `module` fait foi. Il ne s’agit pas de celui de votre fichier de classe principal. PrestaShop lit les deux. C’est celui qui est enregistré qui détermine le nombre de scripts de mise à jour à exécuter.
Votre méthode `install()` est réservée aux nouvelles installations. Supposons que la version 2.0 nécessite un nouveau tableau. Placez-le dans installer(). Toute personne passant à la version 2.0 est prise en charge. Le magasin utilisant encore la version 1.9 ne reçoit rien, car son installation date d’il y a un an et ne sera plus jamais réinstallée.
Une seule défaillance peut tout arrêter. Retour non Lorsqu’une mise à jour est effectuée, trois choses se produisent : PrestaShop s’arrête, enregistre la version défaillante et désactive le module. Impossible de passer au script suivant. Ce comportement est intentionnel, mais cela signifie qu’une modification de schéma partiellement appliquée vous laisse inactif plutôt que complètement hors service.
L’activation de la mise à jour automatique des modules Cette page définit les règles de nommage des fichiers. Veuillez la lire attentivement une fois plutôt que de l’apprendre par cœur.
Le piège de dénomination de la fonction de mise à niveau
Ça m’a coûté un après-midi. Soit module_mise_à_jour_2_0_1 ,soit module de mise à niveau 201 : PrestaShop recherche les deux, que ce soit le nom de la fonction ou le nom de la fonction. Avant d’inclure votre fichier, il vérifie également si l’un de ces noms existe déjà. Si c’est le cas, le fichier est considéré comme un doublon et ignoré.
Copier un ancien script de mise à jour comme modèle est la méthode classique pour se retrouver dans cette situation. Le nom à l’intérieur du script reste inchangé. Aucune mise à jour ne se fait et le message d’erreur est peu informatif.
Migration de base de données PrestaShop 2.0 : les problèmes rencontrés sur les boutiques en ligne.
Tous ces incidents se sont produits dans des magasins où j’ai travaillé.
Modifications du schéma de base de données PrestaShop qui se déplacent d’une installation à l’autre
La version 2.0 nécessite une nouvelle colonne ; vous devez donc mettre à jour Installer() et écrire un script de mise à jour. Les deux sont corrects. Trois versions plus tard, quelqu’un renomme le dossier du module ou un commerçant réinstalle le logiciel. Sur certaines installations, la fonction `install()` a créé cette colonne. Sur d’autres, c’est le chemin de mise à jour qui l’a fait. Deux définitions qui divergent, et un seul numéro de version les englobe désormais toutes les deux.
La définition se trouve donc dans une seule méthode appelée par les deux chemins. Les modifications du schéma de la base de données PrestaShop ne peuvent pas entraîner de désynchronisation s’il n’y en a qu’une seule.
Scripts de mise à niveau qui supposent un point de départ propre
ALTER TABLE … ADD COLUMN Une erreur se produit lors de l’ajout d’une colonne existante ; votre fonction renvoie faux et le module est désactivé. Interrompre une mise à jour précédente, restaurer une sauvegarde partielle, synchroniser deux fois avec l’environnement de test : l’une de ces actions provoque cette erreur.
Chaque modification de schéma que j’écris fait désormais l’objet d’une vérification préalable. L’ajout d’une colonne implique une vérification. AFFICHER LES COLONNES. Créer un tableau au préalable signifie MONTRER LES TABLES ; un indice signifie AFFICHER L’INDEX. Quelques lignes de code supplémentaires suffisent pour que le script résiste à une seconde exécution. C’est important, car la base de données d’un inconnu peut se trouver dans n’importe quel état. S’IL N’EXISTE PAS à la fois MySQL et MariaDB, mais seulement pour certaines opérations, la vérification explicite est plus efficace.
Multistore : lignes de configuration écrites pour un seul magasin
C’est un bug discret mais sournois. La nouvelle version introduit un paramètre par boutique. La ligne par défaut créée par le script de mise à jour, testée par le développeur, semblait fonctionner correctement. Mais une seule ligne a été créée, quelle que soit la boutique concernée, alors que le commerçant en gère quatre.
Il manque désormais cette information dans trois magasins. Selon la façon dont votre code interprète cela, vous obtenez une notification PHP, une valeur vide traitée comme un paramètre réel, ou un espace vide à l’endroit où devrait figurer un prix. La documentation multistore couvre les règles de contexte. Parcourt chaque ID de magasin dans toute mise à jour modifiant la configuration ou les données par magasin.
Lors d’une installation sur un seul magasin, ce bug est invisible.
Verrous de table d’autel sur les grandes tables de catalogue
L’ajout d’une colonne à une table de 400 000 lignes n’est jamais instantané. Selon l’opération, la version de MySQL et le moteur de stockage, la table entière peut être copiée. Sur un site web en activité, pendant les heures d’ouverture, ce délai est suffisamment long pour que les clients s’en aperçoivent.
Je vérifie donc la taille de la table avant d’écrire la migration. Si elle est volumineuse : soit je prévois une fenêtre de maintenance, soit je la restructure pour éviter une reconstruction.
La clé de configuration sans valeur par défaut
Celui que je vois le plus souvent dans les modules d’autres personnes ne contient aucun tableau.
Vous ajoutez un paramètre dans la nouvelle version. Le formulaire d’administration le prend en compte, tout comme l’interface utilisateur. Les deux ont été développés sur une machine où la page des paramètres avait déjà été enregistrée au moins une fois. La clé existe donc et tout semble correct. Déployez cette version et chaque installation existante lira un nouveau paramètre. Configuration clé que personne n’a jamais écrite.
Ce qui revient, c’est non : votre valeur par défaut n’apparaît jamais, pas même une chaîne vide que vous pourriez au moins vérifier. Elle est ensuite utilisée comme un nombre ou transmise à une fonction qui attend une chaîne. En mode débogage désactivé, l’erreur passe souvent inaperçue : le commerçant voit une page légèrement incorrecte et n’y prête pas attention. En mode débogage activé, l’erreur se manifeste par un avertissement ou une erreur de type. C’est ainsi que vous recevez le message « le module plante en mode débogage », alors que seul le mode débogage est légitime.
Le même code, avec et sans la valeur par défaut.
La solution est simple. Chaque nouvelle clé de configuration voit sa valeur par défaut inscrite dans le script de mise à jour, pour chaque boutique, et ce script est fourni avec le code qui la lit. Lisez-la attentivement, car vous ne pouvez pas être certain que la mise à jour a bien été effectuée.
Migration de la base de données du module PrestaShop versus modification du schéma
Les modifications de schéma sont la partie facile. La partie difficile survient lorsque la signification des données existantes change : scinder une colonne en deux, déplacer un champ CSV dans une table associée, réencoder un statut.
C’est là que j’ai constaté le plus de dégâts. Un ratage complet ALTER TABLE : l’échec est retentissant ; une transformation de données bâclée réussit et produit des résultats incohérents. La migration d’une base de données pour un module PrestaShop nécessite un comptage des données avant et après, puis une comparaison. Mieux vaut détecter ces erreurs dans le script de mise à jour plutôt que trois semaines plus tard, par un commerçant.
Meilleures pratiques de mise à niveau du module PrestaShop 3.0 que je défendrais sans hésiter
Ceux qui m’ont sauvé :
Rendre chaque migration idempotente
Rien ne doit changer lors de la seconde exécution ce que la première a déjà géré. Obtenez cette propriété et toute une catégorie de problèmes de support disparaît, car l’état de la base de données n’est plus une chose que vous devez établir au préalable. Avant d’écrire du SQL brut sur les tables principales, les notes de PrestaShop sur la couche de base de données valent bien une heure.
La version protégée survit à une seconde tentative.
Consignez chaque échec au lieu de renvoyer silencieusement la valeur « faux ».
Un nu retourner faux Cela suffit pour que PrestaShop arrête et désactive le module. Ce n’est pas suffisant pour vous. Il est donc important d’encapsuler l’opération. Récupérez les données de sortie et transmettez-les à PrestaShopLogger en y incluant le nom et la version du module. Sinon, un marchand signalera un échec de mise à jour et vous devrez faire des suppositions.
Sur PHP 7 et versions ultérieures, attraper Erreur ainsi que Exception. Vous obtenez une erreur de type dans votre propre code de migration et elle se présente sous la forme d’une erreur, donc un gestionnaire ne surveille que l’Exception et laisse passer.
Assurez-vous de prendre en charge toutes les versions que vous avez jamais livrées.
Un commerçant peut utiliser n’importe quelle version que vous avez publiée. Lors d’une mise à jour de la version 1.4 à la version 3.0, tous les scripts intermédiaires sont exécutés séquentiellement ; chaque script doit donc fonctionner sur le schéma laissé par le précédent. C’est pourquoi les anciens fichiers de mise à niveau restent dans le module. Un utilisateur ayant deux ans de retard n’a pas d’autre solution.
Effectuer le test sur un environnement de test, et non sur une installation locale propre.
Une nouvelle installation de la version actuelle ne prouve en rien la validité de la mise à niveau. La meilleure solution : installer l’ancienne version, y insérer des données réalistes, puis effectuer la mise à niveau. Ceci est également valable pour les environnements multi-magasins, si votre système le prend en charge.
Mieux encore : prenez une copie d’une vraie boutique et effectuez la mise à jour via celle-ci. Votre installation locale contient des données propres et quatre produits, ce qui explique pourquoi elle n’affiche rien. Une vraie boutique contient des importations incomplètes, des lignes laissées par un module désinstallé il y a deux ans, des colonnes ajoutées manuellement par un développeur précédent, un catalogue suffisamment volumineux pour… ALTER TABLE ça prend du temps.
Ensuite, il y a le timing. Une mise à jour nécessitant six minutes par rapport aux données réelles s’apprend mieux lors de la planification d’une fenêtre de maintenance que le vendredi à 11 heures.
Effectuez une sauvegarde avant toute modification du schéma et ssignalez-la
Aucune sauvegarde de vos tables n’est effectuée avant la mise à jour d’un module. Ni par PrestaShop ni par aucun autre outil. Par conséquent, si le marchand ne dispose d’aucune sauvegarde et que la migration s’interrompt en cours de transformation des données, ces données sont perdues. Il est préférable de l’indiquer dans le journal des modifications plutôt que de le découvrir par vous-même.
Récupération après une mise à jour de base de données PrestaShop ayant échoué
Une mise à jour a échoué sur une boutique en ligne ; le module est désactivé. Voici approximativement l’ordre des événements :
Identifiez la version qui a échoué. Cela est enregistré, et si vous avez écrit un message de journalisation, il y sera également consigné. Grâce à ces informations, vous savez quel script ouvrir et quelles modifications ont été prises en compte avant l’arrêt.
Vérifiez le schéma lui-même, et non le numéro de version. Tous les modules.La table contient les données écrites par la dernière mise à jour réussie. La réponse se trouve dans les tables réelles, confrontées à l’action du script ayant échoué.
Réparer en avant, pas en arrière. Il est tentant de revenir à une version antérieure, mais généralement erroné, car les scripts précédents ont déjà été exécutés et les réexécuter sur un schéma partiellement modifié ne fait qu’en créer trois. Il est préférable d’écrire une migration corrective depuis l’emplacement actuel du schéma vers l’emplacement souhaité.
Déterminez ensuite pourquoi la migration n’était pas idempotente. Voilà le vrai problème.
Liste de vérification rapide avant de déployer une mise à jour de module
La liste que j’utilise :
- Version dde laclasse principale, l le fichiermise à niveau-*.php fle plus élevé: correspondent-ils ?
- Chaque fonction de mise à niveau porte le nom de la version de son propre fichier ?
- Chaque modification de schéma vérifie d’abord si elle a déjà été appliquée ?
- Chaque configuration écrit en boucle sur tous les magasins ?
- Chaque nouvelle clé de configuration se voit-elle attribuer une valeur par défaut pour les installations existantes ?
- Avez-vous déjà testé une réplique d’un vrai magasin ?
- Ancienne version installée, données ajoutées, puis mise à niveau ?
- Même chemin dans plusieurs magasins ?
- Un élément utile est consigné avant chaque retour faux
- Erreurrcontagieuseinsi que exl’exception
- Des fichiers de mise à niveau obsolètes sont-ils toujours en place pour les marchands ayant plusieurs versions de retard ?
- Journal des modifications demandant aux marchands de faire marche arrière ?
- Sur une grande table, quelle est la longueur de cela ? ALTER tenir un cadenas ?
Les questions 6 et 7 sont celles que les gens sautent, et c’est à elles deux qu’ils en saisissent la plus grande partie.
Conclusion
Mise à niveau du module PrestaShop Les problèmes sont gênants pour une raison simple : rien ne les annonce. Le module signale sa nouvelle version sans problème. La page d’administration se charge. Aucun journal d’erreurs, sauf si vous les avez créés. Pendant ce temps, votre code attend une chose, la base de données en contient une autre, et cette dernière reste inchangée jusqu’à ce que quelqu’un utilise la fonctionnalité en question.
Considérez le schéma comme faisant partie intégrante de la mise en production. Écrivez des migrations qui résistent à une seconde exécution. Consignez les événements. Testez-le en environnement de préproduction avant toute utilisation par les marchands. Côté framework, celui de PrestaShop… La documentation sur le développement de modules est le point de départ.
Si vous avez des questions ou besoin d’aide concernant les performances ou la migration de votre site web, nos experts sont là pour vous accompagner. Contactez l’équipe Knowband à l’adresse suivante : [email protected]. Découvrez dès aujourd’hui des plugins e-commerce fiables et adaptés à vos besoins.