J2Commerce associe la propriété du contenu Joomla à une couche commerce dédiée. Un élément vendable peut dépendre d’un Article Joomla, de sa Category, de son alias, de sa langue, de son niveau d’accès, de ses médias, de sa route de menu et de son état de publication, tout en portant des relations commerciales propres aux Products, prix, stocks, taxes, options, processus de commande et Orders. La migration ne réussit donc que si ces deux couches restent reliées.
La filiation des versions compte également. J2Commerce actuel est le successeur actif de J2Store, tandis que d’anciennes générations de J2Store et J2Commerce peuvent conserver des structures de tables, extensions et conventions d’implémentation différentes. Un modèle de données fiable ne traite pas toutes les installations de commerce Joomla comme interchangeables. Il identifie la famille de versions qui possède chaque enregistrement puis traduit le sens métier dans la structure cible actuelle.
Le modèle de propriété de J2Commerce
La distinction centrale se situe entre l’identité de contenu et l’identité commerciale. Joomla fournit le cadre de contenu qui rend une page Product publiable, routable, recherchable et visible par le bon public. J2Commerce fournit les enregistrements commerciaux qui rendent l’élément achetable.
| Signification métier | Propriété Joomla habituelle | Propriété J2Commerce habituelle |
|---|---|---|
| Titre Product, contenu long, alias, état de publication, langue, niveau d’accès | Article Joomla et enregistrements CMS associés | L’enregistrement commerce référence l’élément vendable |
| Hiérarchie de Categories et regroupement de contenu | Categories Joomla et relations de menus | Les listes ou filtres commerce peuvent consommer ce regroupement |
| SKU, prix, stock, taxe, poids, caractère achetable | Le CMS n’en est généralement pas le propriétaire principal | Product J2Commerce et enregistrements commerciaux associés |
| Choix acheteur et comportement de type de Product | Peut être affiché via les mises en page Joomla | Options J2Commerce, variantes, logique de type de Product ou extensions |
| Identité acheteur | User Joomla lorsqu’un compte existe | Customer, adresse, contexte de commande et d’Order |
| Route de vitrine | Alias Joomla, Menu Item, routeur, langue et contexte d’accès | L’état du Product détermine si la sortie commerce peut être utilisée |
Cette séparation explique pourquoi les nombres d’enregistrements constituent une preuve faible. Un Product peut exister dans la couche commerce tout en pointant vers le mauvais Article, la mauvaise Category, la mauvaise langue ou le mauvais état de publication. À l’inverse, un Article peut s’afficher correctement tout en ayant perdu la relation commerce qui fournit prix, stock ou contrôles d’achat.
Identité Product, types de Products et relations de vente
J2Commerce utilise des Articles Joomla comme base de contenu pour les Products, mais l’Article n’est pas l’objet commercial complet. Les Products source doivent être décomposés entre les éléments qui décrivent l’offre et ceux qui contrôlent son comportement de vente.
Un Product physique simple peut se traduire proprement lorsqu’un Article, un enregistrement commerce, un SKU, un prix et une position de stock décrivent le même article. La complexité augmente lorsque la source utilise variantes, bundles, téléchargements, abonnements, adhésions, réservations, acomptes ou autres modèles de Products spécialisés. Ces modèles ne sont pas équivalents simplement parce qu’ils apparaissent comme des choix sélectionnables sur une page Product.
| Modèle source | Question de traduction dans J2Commerce | Relation qui doit rester explicite |
|---|---|---|
| Un Product sans choix | Quel Article et quel enregistrement commerce représentent l’élément vendable ? | Relation Article-Product, SKU, prix, stock, Category et état de publication |
| Variantes de taille ou couleur | Chaque choix porte-t-il son propre SKU, prix, stock, image, poids ou disponibilité ? | Structure de choix parent vers le bon résultat vendable |
| Product téléchargeable | Quels fichiers, états d’Order et droits Customer contrôlent l’accès ? | Relation Product-fichier et Order-accès |
| Abonnement ou adhésion | Quel plan, renouvellement, User Group ou droit d’accès définit l’offre ? | Achat Product vers enregistrements récurrents ou états d’accès |
| Réservation | Quelles dates, ressources, capacités, acomptes ou données de participants portent le sens ? | Product vers planning et enregistrements de réservation |
| Bundle ou offre configurable | Le bundle est-il un enregistrement vendable, un ensemble de Products composants ou une logique d’extension ? | Offre parente vers composants, prix, stocks et preuve de ligne d’Order |
Un choix source ne doit devenir une option J2Commerce que si le sens pour l’acheteur est préservé. Les spécifications descriptives appartiennent au contenu ou à des champs structurés ; les sélections portant un stock ont besoin d’une relation d’inventaire vendable ; les valeurs de personnalisation doivent rester attachées à la bonne ligne d’Order. Réduire tout cela à un champ générique supprime le sens opérationnel même lorsque le texte visible subsiste.
Categories, menus, accès et découverte dans la vitrine
La découverte des Products J2Commerce est influencée par les structures Joomla. Les Categories Joomla regroupent les Articles dans le composant de contenu, tandis que les Menu Items créent des destinations navigables et influencent les routes. Modules, niveaux d’accès, affectations linguistiques, Tags et mises en page de templates peuvent également contrôler où un Product apparaît.
Une taxonomie source peut donc nécessiter davantage qu’un import direct de Categories. Le modèle cible doit séparer ces fonctions :
- Classification : manière dont l’équipe organise les Products ;
- Navigation : manière dont les acheteurs atteignent les listes Product et pages d’atterrissage ;
- Accès : Users autorisés à voir le contenu ou les contrôles d’achat ;
- Routage : alias et contexte de menu qui définissent l’URL préférée ;
- Présentation : Module ou mise en page qui assemble la vitrine visible.
| Structure source | Relation cible possible | Sens à préserver |
|---|---|---|
| Product Category | Category d’Article Joomla, règle de liste commerce ou les deux | Regroupement administratif et découverte par l’acheteur |
| Collection dynamique | Filtre, requête de Module, Tag, Custom Field ou règle détenue par une extension | La règle d’appartenance, pas seulement les membres actuels |
| Marque ou fabricant | Champ Product structuré, Category, Tag, page de contenu ou enregistrement d’extension | Affichage, filtrage, navigation ou identité dans un système externe |
| Catalogue restreint | Access Level Joomla, User Group, règle commerce ou extension | Qui peut voir ou acheter le Product |
| Page de campagne | Article Joomla, Menu Item, Modules et Products liés | Contenu, route et composition de merchandising |
Un même Product peut être accessible par plusieurs chemins Joomla. La migration doit attribuer une destination préférée et conserver les alias utiles ou les relations de redirection nécessaires, plutôt que de supposer que chaque chemin source fait partie de l’enregistrement Product.
Customers, Users Joomla, champs de commande et Orders
La signification Customer est répartie entre Joomla et J2Commerce. Un acheteur enregistré peut avoir une identité User Joomla, une ou plusieurs appartenances à des groupes, des informations Customer, des adresses, des champs de commande et des Orders. Un acheteur invité peut ne pas avoir de compte Joomla réutilisable tout en apparaissant dans des Orders historiques.
Le modèle cible doit distinguer l’identité permanente de la preuve transactionnelle :
| Valeur source | Propriété cible probable | Principe de traduction |
|---|---|---|
| Identité de connexion et état du compte | User Joomla | Préserver l’identité unique et la relation de compte lorsqu’elles sont prises en charge |
| Rôle d’accès ou adhésion | User Group Joomla, Access Level ou extension commerce | Préserver la règle qui consomme cette appartenance |
| Adresse de facturation ou de livraison réutilisable | Enregistrements Customer/adresse | Séparer la propriété d’adresse réutilisable d’un instantané d’Order |
| Coordonnées d’un invité | Contexte Customer propre à l’Order | Ne pas créer un compte persistant uniquement parce qu’une adresse e-mail existe |
| Numéro fiscal, société, instruction de livraison | Champ Customer, de commande, d’adresse ou d’Order | Attribuer selon que la valeur est réutilisable ou propre à la transaction |
| Données marketing ou consentement | Profil Joomla, enregistrement d’extension ou système externe | Préserver uniquement avec un propriétaire et un objectif clairs |
Les Orders conservent ce qui s’est passé au moment de l’achat. Noms Product, SKUs, quantités, sélections d’options, prix, remises, taxes, livraison, libellés de paiement, adresses, statuts, notes et références externes doivent rester interprétables même si le catalogue ou la configuration de commande actuels ont changé.
Les statuts d’Order doivent être traduits selon leur sens opérationnel plutôt que copiés par libellé. Un statut source « complete » peut signifier payé, traité logistiquement, clôturé ou simplement traité. Le statut cible doit préserver l’interprétation historique sans laisser entendre qu’un plugin ni processus automatisé actuel est actif.
Contenu, langues, URL et médias
Comme la page Product s’appuie sur le contenu Joomla, la migration doit identifier les valeurs source qui appartiennent à l’Article et celles qui appartiennent aux enregistrements commerce. Descriptions longues, tableaux techniques, médias intégrés, documents téléchargeables, métadonnées, associations linguistiques et paramètres d’accès peuvent tous influencer la page sans être des champs de prix ou de stock.
Les boutiques multilingues nécessitent une traduction au niveau des relations. Un Product traduit peut impliquer des Articles Joomla séparés, des affectations de Categories, alias, menus, Modules et associations linguistiques, en plus du texte commerce traduit. Copier un code langue sur une seule ligne Product ne recrée pas ces relations.
La propriété des médias doit aussi être claire. Une image source peut être :
- l’image principale du Product ;
- une image de galerie Product ;
- une image propre à une option ;
- une image intégrée au contenu d’un Article ;
- un fichier téléchargeable ;
- une ressource de Module ou de page d’atterrissage.
Chaque rôle peut nécessiter une destination différente. Traiter tous les médias comme une seule galerie Product peut supprimer un comportement d’option, casser le contenu d’Article ou exposer des fichiers qui devraient rester contrôlés.
La continuité des URL dépend des alias Joomla, du contexte de menu, du routage, de la langue et parfois d’extensions. Le modèle de données doit identifier les destinations canoniques des Products et Categories, les URL source qui conservent de la valeur et la relation entre les redirections et les nouvelles routes Joomla. Il s’agit d’une décision de propriété des routes, pas d’une simple copie de slug.
Extensions, tables historiques et identifiants externes
J2Commerce peut être étendu par des packages de paiement, livraison, apps, rapports, Modules et plugins. Ces extensions peuvent créer leurs propres enregistrements, ajouter des champs aux Products ou Orders, consommer des User Groups Joomla ou dépendre d’identifiants externes. J2Commerce actuel possède également une filiation technique distincte des installations J2Store historiques, de sorte que tables et extensions propres à une version ne doivent pas être mélangées sans interprétation.
| Type de dépendance | Question sur le modèle de données | Résultat cible approprié |
|---|---|---|
| Extension de paiement ou livraison | Quels libellés ou références historiques appartiennent aux Orders, et quelle configuration appartient à l’extension active ? | Préserver la preuve d’Order ; affecter la configuration actuelle à l’extension cible |
| Extension d’abonnement, réservation ou acompte | Quels plans, instances, plannings, soldes ou droits existent hors Products et Orders ordinaires ? | Mettre en correspondance avec un équivalent pris en charge, un système externe ou une structure définie séparément |
| Champs personnalisés de commande | La valeur est-elle une donnée Customer réutilisable, une donnée d’adresse, une métadonnée d’Order ou une entrée de ligne ? | La stocker avec l’enregistrement qui possède son cycle de vie |
| Extension de reporting | Quels identifiants et relations source sont nécessaires pour reproduire le rapport ? | Préserver les données sous-jacentes faisant autorité plutôt que la seule sortie du rapport |
| Connexion ERP, CRM, comptabilité ou entrepôt | Quels IDs sont des clés stables et lesquels sont un état de synchronisation temporaire ? | Conserver les identifiants durables avec le système externe consommateur nommé |
| Tables J2Store/J2Commerce historiques | Quels enregistrements portent encore un sens métier dans la boutique active ? | Traduire le sens actuel ; ne pas reproduire automatiquement une structure technique obsolète |
Le nom d’une extension ne constitue pas un modèle de données. Le périmètre doit identifier les enregistrements qu’elle crée, les relations qu’elle consomme et le système qui possédera ces relations après la migration.
Identifiants, frontières de versions et filiation des enregistrements
Les identifiants sont particulièrement importants lorsqu’une boutique a traversé J2Store, J2Commerce 4 puis la génération actuelle de J2Commerce. Un même objet métier peut posséder un Article ID Joomla, un ID commerce historique, un ID commerce actuel, un SKU, une clé ERP externe et un ou plusieurs alias d’URL. Ces identifiants sont liés, mais ne sont pas interchangeables.
Un enregistrement cible doit normalement posséder une identité interne faisant autorité et ne conserver que les clés historiques ou externes encore utiles. Préserver chaque ID technique dans un Custom Field visible crée du bruit sans reconstruire les relations originales. Supprimer toutes les clés source peut rendre impossibles la réconciliation, les intégrations ou l’interprétation de l’historique d’Orders.
| Identifiant | Usage qui continue | Traitement cible |
|---|---|---|
| Article ID Joomla | Relie le contenu à l’élément vendable dans la source | Utiliser pour la réconciliation source ; reconstruire la relation Article-Product cible |
| ID J2Store ou J2Commerce historique | Relie d’anciens enregistrements commerce et tables d’extensions | Conserver dans un registre de correspondance contrôlé lorsque des enregistrements en aval le référencent encore |
| SKU ou code Product | Identité opérationnelle utilisée par l’équipe et les systèmes externes | Préserver comme clé métier lorsqu’elle est unique et fait autorité |
| Clé ERP, CRM ou entrepôt externe | Relie le Product, Customer ou Order à un autre système | Préserver avec le système consommateur nommé |
| Alias ou URL source | Soutient la continuité des routes et redirections | Mettre en correspondance avec la destination canonique plutôt que le traiter comme Product ID |
La filiation détermine également si deux lignes source sont des doublons, des versions historiques ou des Products distincts. Cette question doit être résolue avant la création des relations cibles. Un modèle cible propre peut préserver la traçabilité sans hériter des structures de tables obsolètes.
Incidence des différences J2Commerce sur le périmètre de migration
Le périmètre J2Commerce doit être organisé autour des traitements de relations plutôt qu’autour d’une liste plate d’entités.
| Traitement | Exemples habituels | Conséquence pour le périmètre |
|---|---|---|
| Traduction directe d’enregistrements | Products, Customers, Orders, Categories, médias et contenu standard avec propriété claire | Mettre en correspondance les champs et préserver identifiants et relations nécessaires |
| Reconstruction de relations | Liens Article-Product, User-Customer, options Product, associations linguistiques, dépendances Category/menu | Reconstruire les connexions dans la structure cible, pas seulement les enregistrements |
| Configuration cible | Menus, Modules, templates, règles d’accès, configuration paiement/livraison, comportement fiscal actif | Affecter au responsable de l’implémentation cible |
| Données détenues par des extensions | Plans d’abonnement, réservations, enregistrements de commande personnalisés, métadonnées plugins, rapports personnalisés | Définir une destination ou une exclusion explicite |
| Continuité avec des systèmes externes | IDs ERP, clés comptables, références de traitement logistique, adhésion CRM | Préserver les clés durables et documenter le système consommateur |
| Retrait volontaire | Contournements J2Store obsolètes, routes dupliquées, champs inutilisés, extensions abandonnées | Exclure avec une raison documentée plutôt que transférer la dette technique |
Le périmètre est cohérent lorsque chaque valeur source importante possède un propriétaire cible, chaque relation dispose d’une méthode de reconstruction définie et chaque structure non prise en charge ou obsolète reçoit un traitement explicite. Cela évite de migrer le contenu Joomla, les enregistrements commerce J2Commerce et les données d’extensions comme des inventaires déconnectés.
Conclusion
Les différences de modèle de données de J2Commerce viennent de la combinaison du contenu Joomla avec une couche commerce dédiée. Les Products ne sont pas de simples lignes contenant prix et stock : ils sont reliés à des Articles, Categories, alias, accès, langues, médias, options, Customers, Orders et extensions. J2Commerce actuel doit également être distingué des structures historiques de J2Store et des générations précédentes de J2Commerce.
Une migration fiable traduit la propriété métier plutôt que les libellés de champs. Elle aligne les identités Article et Product, préserve le sens des choix acheteur et des lignes d’Order, sépare le routage Joomla des enregistrements commerce et attribue les données d’extensions ou systèmes externes à une destination claire. Cette approche produit une boutique cible dont les enregistrements restent compréhensibles et exploitables dans l’environnement Joomla actuel.
Questions fréquentes
Pourquoi un Product J2Commerce ne peut-il pas être traité comme une ligne Product ordinaire ?
Parce que l’élément vendable peut dépendre à la fois d’un Article Joomla et d’enregistrements commerce J2Commerce. Le contenu, l’alias, la Category, la langue, l’accès et l’état de publication peuvent appartenir à Joomla, tandis que SKU, prix, stock, options et caractère achetable appartiennent à J2Commerce.
J2Commerce utilise-t-il le même modèle de données que J2Store historique ?
Non. J2Commerce est le successeur actif, mais les générations actuelles et historiques peuvent utiliser des tables commerce, extensions et conventions d’implémentation différentes. Les relations J2Store existantes doivent être interprétées et traduites plutôt que supposées identiques.
Comment traduire les variantes et options Product ?
Classez ce que chaque choix modifie. Un SKU portant du stock, un simple modificateur de prix, une spécification descriptive et un champ de personnalisation ont des propriétaires différents et ne doivent pas devenir le même type d’option.
Où stocker les données Customer lorsque des Users Joomla sont impliqués ?
L’identité de connexion permanente appartient à la relation User Joomla, tandis que les adresses réutilisables et informations commerce appartiennent aux enregistrements Customer. Les données invitées et champs propres à une transaction doivent rester attachés à l’Order concerné plutôt que créer des comptes artificiels.
Les menus et Modules Joomla appartiennent-ils aux données Product ?
Non. Ce sont des structures Joomla distinctes de présentation et de routage qui consomment les données Product et Article. Les relations nécessaires doivent être définies indépendamment du transfert de l’enregistrement Product.
Comment traiter les données détenues par des extensions et des systèmes externes ?
Identifiez l’enregistrement, sa finalité métier et le système qui le possédera après migration. Les identifiants durables et relations prises en charge peuvent être conservés ; un état technique obsolète ne doit pas être copié sans consommateur futur.