Si le projet choisit Zen Cart comme plateforme cible, la préparation doit rendre la boutique source réelle compréhensible avant de finaliser la configuration de migration. Une installation utilisée depuis longtemps peut combiner Products natifs, Categories liées, attributs, téléchargements, groupes de prix Customer, totaux d’Order, EZ-Pages, define pages, modèles, plugins, surcharges, fichiers de langue et champs personnalisés de base de données. La boutique visible peut sembler cohérente alors que les enregistrements qui la soutiennent sont répartis entre plusieurs propriétaires techniques et métier.
L’objectif de la préparation est de transformer cet environnement en preuves source maîtrisées. Chaque domaine important doit préciser l’action à terminer, la personne qui possède la réponse, les preuves à fournir et la condition qui permet de déclarer le domaine prêt. Cette approche permet de distinguer les enregistrements ordinaires, la configuration de plateforme, les données appartenant aux plugins et le code personnalisé avant le début de la configuration de migration.
Établir l’accès source et documenter l’environnement Zen Cart
Commencez par identifier précisément l’installation. Documentez la version Zen Cart, l’environnement d’hébergement, la base de données, la racine des documents, le chemin d’administration, les packs de langue actifs, devises, zones fiscales, modèles, plugins, surcharges et synchronisations externes. Deux boutiques visuellement similaires peuvent se comporter différemment si l’une utilise les fonctions natives actuelles et l’autre dépend d’anciens plugins ou de modifications directes de fichiers.
Préparez l’accès source indiqué comme nécessaire pour le parcours de migration sélectionné. Les accès base de données, hébergement, administration ou fichiers ne doivent pas être présentés comme des choix interchangeables. Le responsable technique doit fournir l’accès correspondant à l’installation réelle et rester disponible lorsqu’il faut clarifier permissions, listes d’autorisation, chemins de fichiers ou préfixes de base de données.
| Action | Responsable | Preuve | Condition de préparation |
|---|---|---|---|
| Documenter précisément l’environnement Zen Cart et PHP | Responsable hébergement ou technique | Captures de version, note d’environnement, version de base de données | L’installation source et le contexte de compatibilité ne présentent aucune ambiguïté. |
| Confirmer l’accès source | Responsable des accès | État de connexion, détails de liste d’autorisation, préfixe de base de données, note sur la racine des fichiers | La connexion source requise atteint la bonne boutique. |
| Inventorier modèles, surcharges et plugins | Développeur ou agence | Modèle actif, liste de plugins, répertoires de surcharge, relevé des fichiers modifiés | Les données natives et les comportements dépendants du code peuvent être séparés. |
| Documenter langues, devises, zones fiscales et unités | Responsable commerce | Preuves de configuration et liste des langues actives | Les valeurs globales qui influencent le sens des Products et Orders sont documentées. |
| Identifier imports et synchronisations externes | Responsable intégrations | Calendrier des flux, liste des systèmes externes, détails de dernière exécution | Les valeurs susceptibles d’évoluer pendant la préparation ont une autorité nommée. |
Créez un journal des changements dès que ces preuves sont capturées. L’activité commerciale courante peut continuer, mais les nouveaux plugins, changements de base de données, restructurations majeures d’attributs ou modifications d’URL doivent être consignés afin que le modèle source préparé ne devienne pas obsolète sans visibilité.
Préparer Products, attributs, téléchargements et relations de prix
Zen Cart utilise les attributs Product pour représenter des valeurs sélectionnables, du texte saisi par le Customer, des fichiers téléversés, des informations en lecture seule, des ajustements de prix ou de poids et des fichiers téléchargeables. Option Names, Option Values et affectation de l’attribut à un Product sont des enregistrements distincts. Certaines installations utilisent également du stock par variante ou des attributs dépendants, soit de façon native dans la version actuelle, soit via un plugin.
Préparez un inventaire Product comprenant Product ID, modèle ou SKU, statut, prix, classe fiscale, quantité, comportement du stock, poids, type de Product, fabricant, Category principale, Categories liées, images, Specials, état featured, remises sur quantité, groupes de prix Customer, attributs et références de téléchargement lorsqu’elles sont utilisées. Les preuves doivent montrer quelles valeurs identifient un choix vendable et lesquelles sont seulement descriptives ou saisies par le Customer.
| Modèle source | Action de préparation | Preuve | Condition de préparation |
|---|---|---|---|
| Taille, couleur ou format sélectionnable | Documenter Option Name, Option Value, affectation d’attribut, ordre de tri et état obligatoire/par défaut | IDs Product représentatifs et export d’attributs | Le vocabulaire des choix et la relation Product sont complets. |
| Attribut qui modifie prix ou poids | Documenter ajustement, préfixe, inclusion dans le prix de base, traitement des remises et Product propriétaire | Exemple de prix et paramètres d’attribut | L’effet commercial est explicite et non déduit du seul libellé. |
| Saisie texte ou fichier | Séparer la saisie propre à l’achat des valeurs d’option réutilisables | Liste de Products et lignes d’Order représentatives | Les données saisies par l’acheteur ne seront pas confondues avec une variante stockée. |
| Product téléchargeable | Documenter fichier, attribut, jours d’expiration, nombre de téléchargements et emplacement de stockage | Manifeste Product/fichier et fichiers originaux accessibles | La relation Product-to-download et le fichier source sont disponibles. |
| Stock au niveau variante ou règle de dépendance | Identifier le propriétaire natif ou plugin, les combinaisons, SKU et quantités | Table de combinaisons ou export du plugin | Les relations de stock indépendant et de dépendance sont documentées. |
| Prix par groupe Customer ou quantité | Documenter Product, groupe, seuil, montant et dates | Inventaire des relations de prix | Les prix conditionnels ne sont pas réduits au prix de base du Product. |
Ne normalisez pas les libellés d’attributs et ne fusionnez pas des valeurs d’options sans validation métier. Des noms proches peuvent porter des significations différentes pour le prix, le stock, le téléchargement ou les lignes d’Order.
Documenter Categories, Products liés, fabricants et découverte
Les Products Zen Cart ont une Category principale et peuvent aussi être liés à d’autres Categories. La hiérarchie des Categories, le placement lié des Products, la navigation par fabricants, Specials, Products featured, listes de nouveaux Products et recherche peuvent tous influencer la découverte. Le dossier de préparation doit distinguer classification du catalogue, menus du modèle et sideboxes.
Préparez l’arborescence Category avec IDs, relations parent, statut, contenu linguistique, images, ordre de tri, restrictions par type de Product et routes importantes. Pour chaque Product présent dans plusieurs Categories, documentez la Category principale et les Categories liées. Un placement lié ne doit pas être confondu avec un Product dupliqué.
| Domaine de découverte | Responsable | Preuve | Condition de préparation |
|---|---|---|---|
| Hiérarchie de Category | Responsable catalogue | Export parent-enfant et liste des Categories conservées | Chaque Category conservée a un parent et un objectif connus. |
| Categories principales et liées | Responsable merchandising | Relations Product-to-Category | Le placement partagé est visible sans créer de Products dupliqués. |
| Enregistrements fabricant | Responsable marque | Liste des fabricants, affectations Product, notes sur les routes publiques | Le sens public de la marque est séparé des données internes fournisseur. |
| Specials, featured et nouvelles listes | Responsable merchandising | Listes de Products actifs et règles de date | Le merchandising dépendant du temps ou du statut est identifié. |
| Menus et sideboxes | Responsable boutique | Captures et notes de mise en page/modules | La présentation est séparée des relations catalogue. |
Préparer Customers, groupes de prix, adresses et historique des Orders
La préparation des Customers doit distinguer identité de compte, entrées du carnet d’adresses, état d’autorisation, préférence newsletter, groupe de prix, niveau wholesale lorsqu’il existe, solde de gift certificate, Reviews et identifiants externes. Un groupe de prix Customer peut influencer le fonctionnement commerce et doit être documenté comme une relation, pas conservé comme un simple libellé.
La préparation des Orders doit préserver la preuve historique. Sélectionnez des Orders représentant achats invités et enregistrés, attributs, téléchargements, remises, Coupons ou gift certificates, taxes, libellés de livraison et paiement, commentaires, historique de statut, adresses de facturation et livraison différentes ainsi que totaux d’Order générés par des plugins. Gardez les adresses et descriptions Product au moment de l’Order distinctes des enregistrements Customer et catalogue actuels.
| Domaine d’enregistrement | Action de préparation | Preuve | Condition de préparation |
|---|---|---|---|
| Identité Customer | Identifier doublons, états d’autorisation, groupes de prix et clés externes | Liste des exceptions Customer | Chaque exception d’identité possède un responsable et une décision. |
| Carnets d’adresses | Séparer les adresses Customer réutilisables des instantanés d’Order | Exemples d’adresses Customer et Order | Les données actuelles de compte et l’historique transactionnel ne sont pas confondus. |
| Groupes de prix ou wholesale | Documenter l’appartenance et chaque relation Product ou prix qu’elle influence | Matrice groupe-to-rule | Le sens commercial est documenté au-delà du nom du groupe. |
| Statuts d’Order et commentaires | Documenter libellés, séquence, visibilité Customer et Orders représentatifs | Inventaire des statuts | Les états historiques peuvent être interprétés sans dépendre seulement du libellé. |
| Totaux d’Order | Identifier lignes de sous-total, taxe, livraison, remise, gift certificate, frais et plugins | Ensembles représentatifs de totaux | Chaque ajustement important possède un propriétaire source connu. |
| Historique des téléchargements | Documenter attributs des fichiers achetés, accès restant et relation à l’Order | Orders liés aux téléchargements | Le contexte d’achat numérique est inclus dans les preuves source. |
Les enregistrements historiques ne doivent pas être modifiés uniquement pour les uniformiser. Documentez séparément les anomalies lorsqu’elles expliquent la transaction d’origine.
Inventorier plugins, surcharges, modèles et données personnalisées
Les plugins Zen Cart peuvent ajouter champs, tables, règles de prix, logique de stock, totaux d’Order, routes SEO, propriétés Customer, rapports, flux ou intégrations. Les surcharges et modifications directes peuvent aussi changer le comportement sans créer d’enregistrement de plugin évident. La préparation doit identifier quelles données métier chaque composant possède.
Créez un registre de dépendances avec nom du plugin, version, objectif, état actif, entités affectées, ajouts à la base de données, fichiers modifiés ou surchargés, systèmes externes et personne capable de confirmer si le comportement reste nécessaire. Utilisez « plugin Zen Cart » ou le nom précis du composant afin de ne pas confondre les extensions de plateforme avec les fonctions Add-on du service de migration.
| Effet de dépendance | Preuve à préparer | Condition de préparation |
|---|---|---|
| Extension d’attribut ou de stock par variante | Enregistrements de combinaison, clés Product, champs SKU et quantité | Chaque combinaison active possède un propriétaire source défini. |
| Module de total d’Order ou processus de commande | Résumé de configuration et Orders historiques représentatifs | Les valeurs historiques peuvent être séparées de la configuration actuelle de la boutique. |
| Plugin SEO ou URL | Paramètres de réécriture, exemples de routes et tables de redirection | Les chemins source importants peuvent être reconstruits. |
| Extension Customer ou fidélité | Champs, soldes, historique de transactions et clés Customer | Les données actives de compte ont une décision de destination explicite. |
| Intégration ERP, marketplace ou traitement logistique | IDs externes, sens de synchronisation et autorité | Les systèmes futurs peuvent identifier le même Product, Customer ou Order. |
| Contenu dépendant du modèle | Chemins de modèle, captures et source du contenu | Le contenu métier est séparé du code de présentation. |
Préparer EZ-Pages, define pages, médias et preuves d’URL
Le contenu Zen Cart peut apparaître à travers EZ-Pages, define pages, descriptions Product et Category, bannières, sideboxes, fichiers de modèle et fichiers de langue. Préparez un inventaire qui nomme le propriétaire du contenu, la langue, la route actuelle, le placement menu ou sidebox, les liens intégrés, images et disposition prévue.
Documentez les URL prioritaires de Product, Category, fabricant, EZ-Page, politique, contact et information. Les chemins natifs Product et Category peuvent utiliser des IDs et des chemins de Category, tandis que des plugins SEO peuvent les remplacer par des routes réécrites. L’inventaire des routes doit donc préciser si chaque chemin important est natif, généré par plugin, statique ou redirigé depuis l’extérieur.
Sauvegardez les images originales et fichiers de téléchargement avec leurs chemins. La base de données peut contenir les noms de fichiers sans contenir les fichiers eux-mêmes. Signalez les fichiers manquants, URL d’images externes, différences de casse dans les chemins et miniatures générées qui ne sont pas des sources originales.
Créer un package source Zen Cart restaurable
Préservez un état source Zen Cart récupérable avant tout nettoyage structurel ou exécution de migration. Le package doit inclure la base de données, l’arborescence de fichiers pertinente, le répertoire de téléchargements, les références de configuration, les preuves liées aux modèles et plugins ainsi qu’une note d’environnement rattachée au même état de boutique.
| Composant du package | Responsable | Preuve | Condition de préparation |
|---|---|---|---|
| Sauvegarde de base de données | Administrateur de base de données | Dump horodaté et note de préfixe de base de données | Le dump est complet et appartient à la boutique prévue. |
| Fichiers et téléchargements | Responsable hébergement ou technique | Archive de fichiers ou arborescence source accessible | Images originales, téléchargements, modèles, surcharges et plugins sont disponibles. |
| Enregistrement de l’environnement | Responsable technique | Note de version PHP, base de données, serveur et Zen Cart | Les comportements dépendants de la version peuvent être interprétés. |
| Registre des accès | Responsable projet | Responsable des accès et état de connexion | Les accès requis sont disponibles sans exposer les identifiants dans la documentation. |
| Journal des changements | Administrateur de la boutique | Changements après la date de référence des preuves | Les changements structurels tardifs peuvent être intégrés délibérément. |
Sélectionner des échantillons représentatifs pour les tests de migration
Préparez un manifeste d’échantillons compact avec IDs source, raison métier, fichiers liés et relations source attendues. Il doit inclure à la fois des enregistrements ordinaires et les relations les plus susceptibles d’être mal comprises. Le manifeste Zen Cart est prêt lorsque chaque attente source, dépendance de plugin ou d’attribut, fichier lié et identifiant est complet et attribué à un réviseur.
Incluez au minimum :
- un Product simple, un Product inactif et un Product lié à plusieurs Categories ;
- un Product riche en attributs avec effets sur prix ou poids ;
- une saisie texte ou fichier, du stock par variante ou des attributs dépendants lorsqu’ils existent ;
- un Product téléchargeable avec fichier source et historique d’achat ;
- des Products avec Specials, tarification par quantité ou tarification de groupe Customer ;
- des Customers provenant de groupes de prix ou d’autorisation significatifs ;
- des Orders avec attributs, commentaires, adresses différentes, gift certificates, totaux inhabituels et téléchargements ;
- des URL prioritaires natives et réécrites ;
- un enregistrement actif appartenant à un plugin et un exemple de contenu dépendant du modèle.
Appliquer le dernier critère de préparation Zen Cart
Zen Cart est prête pour l’étape de migration suivante lorsque la source peut être expliquée sans hypothèses non documentées.
| Question de préparation | Résultat requis |
|---|---|
| L’installation exacte est-elle connue ? | Version, hébergement, base de données, langues, modèle, surcharges et plugins sont documentés. |
| Les relations Product sont-elles complètes ? | Attributs, téléchargements, Categories, prix, médias et extensions de stock sont représentés. |
| Customers et Orders sont-ils interprétables ? | Groupes, adresses, statuts, totaux, commentaires et IDs externes ont des propriétaires. |
| Plugins et données personnalisées sont-ils classés ? | Chaque dépendance active possède un objectif métier et une décision de destination. |
| Contenu et routes sont-ils inventoriés ? | EZ-Pages, define pages, médias et URL natives ou réécrites importantes sont documentés. |
| Sauvegardes et accès sont-ils prêts ? | Le package source est restaurable et les accès requis sont disponibles. |
| L’ensemble d’échantillons est-il représentatif ? | Enregistrements ordinaires et complexes sont listés avec IDs source et relations attendues. |
Les éléments non résolus doivent figurer dans un journal de décision avec un responsable et une échéance. La préparation reste incomplète lorsqu’une table de plugin critique, un fichier de téléchargement, un lien de Category, une relation de prix ou un identifiant externe est encore décrit uniquement comme inconnu.
Conclusion
La préparation d’une migration vers Zen Cart est la plus robuste lorsque la boutique est traitée comme un catalogue connecté et un ensemble d’enregistrements historiques, pas comme un simple export de Products. Attributs, téléchargements, Categories liées, groupes de prix Customer, totaux d’Order, EZ-Pages, plugins, surcharges, modèles et fichiers originaux ont chacun besoin d’un responsable clair et d’un ensemble de preuves.
Un package source restaurable, un manifeste d’échantillons représentatifs et un critère de préparation explicite constituent la base de la configuration de migration.
Questions fréquentes
Pourquoi les attributs Zen Cart doivent-ils être préparés séparément des champs Product ?
Les attributs relient Option Names et Option Values aux Products et peuvent modifier prix, poids, sélection obligatoire, saisie acheteur, téléchargements ou stock. Une ligne Product plate ne peut pas préserver ces relations de façon fiable.
Quelle est la différence entre une Category principale et une Category liée ?
Un Product possède une Category principale et peut être lié à d’autres Categories. Documentez les deux relations afin que le placement supplémentaire ne soit pas interprété comme un Product dupliqué ou perdu pendant la préparation du catalogue.
Une sauvegarde de base de données Zen Cart inclut-elle les images et fichiers téléchargeables ?
Non. La base de données stocke généralement des références. Les images originales, téléchargements, modèles, surcharges et fichiers de plugins doivent aussi être préparés depuis le système de fichiers.
Comment documenter les données de plugins Zen Cart ?
Documentez le plugin, sa version, les entités affectées, champs ou tables, IDs source représentatifs, dépendances externes et objectif métier futur. Les données actives ont besoin d’un propriétaire explicite ; les enregistrements obsolètes peuvent être marqués pour archivage ou exclusion.
Quels Orders doivent figurer dans l’échantillon source ?
Incluez des Orders ordinaires et des Orders avec attributs, remises, gift certificates, adresses de facturation et livraison différentes, commentaires, totaux inhabituels, téléchargements et références externes. Ils révèlent les relations invisibles dans les Orders les plus simples.
Les URL Zen Cart réécrites doivent-elles être considérées comme des URL Product natives ?
Pas automatiquement. Documentez si chaque route importante est native, générée par un plugin SEO, statique ou redirigée depuis l’extérieur. Cette propriété détermine les preuves nécessaires pour reproduire la relation de chemin.