J2Store intègre l’e-commerce dans Joomla au lieu de placer chaque valeur commerciale dans un objet produit indépendant. Les articles Joomla peuvent jouer le rôle de produits, tandis que catégories Joomla, alias, menus, utilisateurs, niveaux d’accès, médias, modules et templates fournissent une grande partie du contexte de contenu et de vitrine. J2Store ajoute ensuite prix, SKU, stock, type de produit, options, relations client, processus de commande et commandes qui rendent l’article vendable.
J2Store est aujourd’hui un projet arrivé en fin de développement dont le dépôt est archivé, tandis que J2Commerce constitue le successeur actif. Ce fait de cycle de vie n’efface pas le modèle de données des boutiques J2Store existantes. Il rend l’interprétation de la source encore plus importante : anciens enregistrements, applications, plugins, surcharges et tables personnalisées doivent être compris comme des éléments métier legacy plutôt que supposés correspondre à une structure cible actuelle.
La relation entre article et produit
La relation déterminante dans J2Store est celle qui relie un article Joomla à ses données e-commerce. L’article fournit l’identité de contenu ; J2Store fournit l’identité commerciale. Une migration qui les sépare peut créer des produits dupliqués, des enregistrements e-commerce orphelins ou des pages d’article qui ne se comportent plus comme des produits.
| Fonction métier | Couche Joomla | Couche J2Store |
|---|---|---|
| Titre du produit et contenu long | Titre d’article, corps, métadonnées, langue, état de publication | L’enregistrement e-commerce référence l’article vendable |
| Regroupement de contenu | Catégorie Joomla, tags, contexte de menu | Listes de produits, filtres ou logique d’application peuvent utiliser ce regroupement |
| Identité commerciale | Responsabilité CMS limitée | Type de produit, SKU, prix, fiscalité, stock, poids, dimensions |
| Choix de l’acheteur | Affichés via l’article ou le rendu du template | Options, variantes, champs personnalisés ou enregistrements détenus par des applications |
| Compte acheteur | Utilisateur et groupes Joomla | Client, adresses, champs du processus de commande et commandes |
| URL de la boutique | Alias, catégorie, élément de menu, routeur, langue | L’état du produit détermine si les contrôles d’achat sont disponibles |
L’ID de l’article et la relation avec le produit J2Store doivent être traités comme une seule identité logique pendant la migration. Conserver les deux tables tout en perdant le lien ne constitue pas une préservation.
Types de produits, options et enregistrements e-commerce spécialisés
Les installations J2Store peuvent représenter des modèles de vente simples, variables, configurables, téléchargeables, virtuels, par abonnement, réservation, paiement partiel et autres. Certains modèles proviennent des types produit principaux ; d’autres d’applications ou plugins. Leurs libellés visibles dans la vitrine ne révèlent pas toute la structure sous-jacente.
Un produit source doit être séparé en significations distinctes avant migration :
| Élément source | Responsable J2Store possible | Question de migration |
|---|---|---|
| Nom, description, médias intégrés | Article Joomla | Quel contenu appartient à la page produit canonique ? |
| SKU, prix, stock, poids | Produit J2Store ou enregistrement de variante | La valeur est-elle partagée ou propre à un choix de l’acheteur ? |
| Taille, couleur, matière, gravure | Option, variante, contenu d’article ou enregistrement d’application | La valeur modifie-t-elle SKU, stock, prix, traitement ou uniquement la présentation ? |
| Fichier numérique | Produit téléchargeable ou relation d’application | Quel achat et quel état de commande donnent accès au fichier ? |
| Plan d’abonnement | Produit, plan, renouvellement et droits détenus par une application | Quelles relations récurrentes et de compte doivent continuer ? |
| Créneau de réservation | Planning, ressource, capacité et réservation détenus par l’application | Quel enregistrement représente le service vendable et lequel représente la réservation ? |
| Acompte ou échéance | Plan de paiement et enregistrements de solde | Comment total initial, montant payé, reste et statut sont-ils reliés ? |
Une option produit ne doit pas être traduite uniquement d’après son nom. Une valeur « taille » peut être une variante portant du stock, un modificateur de prix, une dimension descriptive ou un facteur d’expédition. Le propriétaire cible doit suivre la fonction métier.
Les enregistrements spécialisés demandent une attention particulière car les extensions J2Store peuvent stocker leurs données hors des tables produit et commande ordinaires. Un produit d’abonnement sans ses enregistrements de plan et de droits devient un produit à achat unique. Un produit de réservation sans ses données de réservation devient seulement une page décrivant un service.
Catégories, menus, modules et routes
La structure de catalogue J2Store dépend fortement de Joomla. Une catégorie source peut avoir plusieurs significations cibles : classification d’article, navigation acheteur, regroupement dynamique, entrée de filtre, frontière d’accès ou contexte de page d’atterrissage.
| Structure source | Relation J2Store/Joomla | Sens à préserver |
|---|---|---|
| Catégorie produit | Catégorie Joomla affectée aux articles produit | Classification et navigation fondée sur les catégories |
| Collection ou rayon | Catégorie, tag, requête de module, élément de menu ou règle d’application | Logique de regroupement et parcours de découverte |
| Marque ou fabricant | Champ produit, tag, catégorie, page de contenu ou extension | Affichage, filtrage, route et identité externe |
| Produits mis en avant | Configuration de module ou requête d’application | La règle de sélection plutôt qu’une liste copiée statiquement |
| Catalogue restreint | Niveau d’accès Joomla, groupe utilisateur ou extension | Quels utilisateurs peuvent voir ou acheter les produits |
| Page de campagne | Article Joomla, élément de menu, modules et liens produit | Composition du contenu et route canonique |
Le contexte du menu Joomla influence le routage. Le même article peut apparaître sous différents chemins de menu, chemins de catégorie ou alias. La migration doit identifier la destination produit préférée et la distinguer des routes alternatives qui nécessitent une redirection ou un retrait.
Les modules et surcharges de template ne sont pas des enregistrements produit. Ils peuvent déterminer quels produits apparaissent, quels champs sont visibles et comment options ou prix sont rendus. Leur dépendance aux identifiants migrés doit être documentée, mais leur logique de présentation reste une structure cible séparée.
Clients, utilisateurs Joomla et contexte de compte
Les données client J2Store peuvent couvrir utilisateurs Joomla, groupes, enregistrements client, adresses, champs du processus de commande et commandes historiques. Une adresse e-mail client ne suffit pas à reconstruire la relation de compte.
Un client enregistré peut disposer de :
- un ID utilisateur Joomla et un état de connexion ;
- une appartenance à des groupes Joomla ;
- une ou plusieurs adresses de facturation et de livraison ;
- des valeurs réutilisables de profil ou de fiscalité ;
- des champs personnalisés d’inscription ou de commande ;
- des commandes liées à l’utilisateur ou à l’adresse e-mail ;
- des enregistrements d’adhésion, abonnement, récompense ou accès détenus par une application.
Une commande invitée peut contenir les mêmes coordonnées et adresses sans aucun utilisateur Joomla persistant. Créer un compte enregistré pour chaque invité historique peut modifier le sens de l’identité et produire des comptes dupliqués ou inutilisables.
| Valeur client | Responsabilité appropriée | Raison |
|---|---|---|
| Nom de connexion, e-mail, état activé | Utilisateur Joomla | Contrôle l’identité persistante d’authentification |
| Rôle de groupe utilisateur | Relation au groupe Joomla | Peut contrôler accès, tarification ou fonctionnement d’extensions |
| Adresse réutilisable | Enregistrement client/adresse J2Store | Appartient au cycle de vie du client |
| Instantané de facturation/livraison invité | Commande historique | Appartient à une transaction précise |
| Numéro fiscal ou données société | Champ client, adresse ou commande selon l’usage | La responsabilité dépend du caractère réutilisable de la valeur |
| Consentement marketing ou statut d’adhésion | Profil Joomla, extension ou système externe | Nécessite un système consommateur identifié |
Le traitement des mots de passe doit être considéré comme une question d’identité, pas comme un champ client générique. La réutilisation des identifiants dépend des modèles d’authentification source et cible ainsi que de la relation utilisateur Joomla conservée.
Les commandes comme éléments historiques
Les commandes J2Store préservent davantage qu’un total d’en-tête. Elles peuvent inclure instantanés produit et option, SKU, quantités, prix unitaires, remises, coupons, taxes, expédition, libellés de paiement, adresses, champs personnalisés du processus de commande, notes, statuts et références détenues par des extensions.
La commande historique doit rester interprétable même si le produit d’origine évolue ou qu’une extension n’est plus active. Cela exige de conserver les valeurs d’instantané avec la commande plutôt que de les reconstruire uniquement depuis le catalogue actuel.
| Relation de commande | Sens à préserver |
|---|---|
| Commande vers client ou invité | Qui a passé la commande et si un compte persistant existait |
| Commande vers ligne | Ce qui a été acheté, y compris options choisies et nom/SKU enregistrés |
| Ligne vers prix et remise | Comment le sous-total historique a été formé |
| Commande vers fiscalité et expédition | Quels montants et libellés expliquent le total |
| Commande vers enregistrement de paiement | Méthode historique et référence du prestataire lorsque conservée |
| Commande vers historique de statuts | Interprétation opérationnelle de la transaction dans le temps |
| Commande vers enregistrement d’application | Contexte d’abonnement, réservation, accès fichier, échéance ou traitement |
Les libellés historiques de paiement et d’expédition ne recréent pas le fonctionnement actuel des passerelles ou transporteurs. Ils appartiennent à la commande comme éléments historiques. La configuration active du processus de commande appartient à l’environnement cible.
Relations de contenu, langues, médias et SEO
Les pages produit J2Store héritent des capacités de contenu Joomla. Les articles produit peuvent contenir descriptions formatées, médias intégrés, champs personnalisés, métadonnées, alias, affectations linguistiques, paramètres d’accès et plugins de contenu. Un export produit source peut ne pas distinguer les valeurs qui sont du contenu produit de celles générées par un template ou une extension.
Le modèle cible doit classer les médias selon leur rôle :
- image intégrée dans l’article ;
- image produit principale ;
- image de galerie produit ;
- image propre à une option ;
- fichier téléchargeable ;
- ressource de page d’atterrissage ou de module.
Les relations linguistiques dépassent elles aussi le simple texte traduit. Les sites Joomla multilingues peuvent utiliser des articles, catégories, menus, modules, alias et associations linguistiques séparés. L’ensemble des traductions doit rester relié dans les couches contenu et e-commerce.
La continuité SEO dépend des relations entre alias d’article, chemins de catégorie, éléments de menu, comportement du routeur, métadonnées et éventuelle extension canonique ou de redirection. Une URL source ne doit pas automatiquement devenir un champ alias si son chemin était généré par une relation de menu ou de catégorie. La cible a besoin d’un responsable canonique et d’un chemin de redirection défini pour les alternatives importantes.
Applications, plugins, tables personnalisées et systèmes externes
Les anciennes boutiques J2Store sont souvent façonnées par des applications et plugins. Abonnements, réservations, paiements partiels, récompenses, bundles produit, uploads, champs du processus de commande, paiements, expédition, fiscalité, reporting et intégrations peuvent tous créer des enregistrements hors du modèle simple produit-client-commande.
| Dépendance | Enregistrements cachés ou distribués | Exigence de migration |
|---|---|---|
| Application d’abonnement ou d’adhésion | Plans, références de facturation, renouvellements, états d’accès, groupes utilisateurs | Préserver la relation entre produit, client, plan et droit |
| Application de réservation | Ressources, dates, capacité, réservations, participants | Distinguer le produit vendable de l’instance réservée |
| Application de paiement partiel | Plans de paiement, échéances, soldes, liens transactionnels | Maintenir la relation financière cohérente |
| Champs personnalisés du processus de commande | Valeurs client, adresse, métadonnées de commande, saisies de ligne | Affecter chaque champ à son véritable responsable de cycle de vie |
| Plugin de paiement ou expédition | Configuration, références fournisseur, libellés de méthode, statuts personnalisés | Séparer configuration active et éléments historiques de commande |
| Intégration ERP, CRM, comptabilité ou entrepôt | ID externes, état de synchronisation, tables de mise en correspondance | Préserver les clés durables et nommer le responsable externe |
| Surcharge de template ou module | Règles d’affichage et hypothèses sur les identifiants | Reconstruire la présentation à partir des enregistrements migrés |
L’état archivé de J2Store signifie que certaines extensions legacy peuvent ne plus avoir d’équivalent actif. La question du modèle de données reste objective : quels enregistrements portent encore un sens métier et où ce sens vivra-t-il après migration ? Les enregistrements sans consommateur cible doivent être archivés ou retirés volontairement plutôt que copiés comme débris techniques opaques.
Traçabilité des enregistrements legacy et responsabilité d’archive
Les migrations J2Store nécessitent souvent deux destinations : un modèle cible opérationnel et une archive historique. Toutes les anciennes tables ne doivent pas devenir des objets actifs, mais les enregistrements qui expliquent commandes, droits, éléments fiscaux ou historique des systèmes externes peuvent encore nécessiter une conservation à long terme.
La décision doit être fondée sur la traçabilité métier plutôt que sur l’ancienneté de la table. Un ancien ID produit peut être obsolète pour la vitrine mais encore relier d’anciennes lignes de commande à des exports comptables. Un enregistrement d’application peut ne plus piloter de comportement actif mais expliquer une période d’adhésion ou un solde d’échéance. Un alias dupliqué peut être inutile comme contenu actif mais nécessiter encore une redirection.
| Enregistrement legacy | Usage opérationnel cible | Usage d’archive |
|---|---|---|
| Identifiants produit et article | Reconnecter l’article vendable actuel et son contenu | Retracer les anciennes lignes de commande ou références externes |
| Configuration d’extension archivée | Généralement remplacée par la configuration actuelle | Expliquer comment les transactions historiques ont été produites |
| Instances d’abonnement, réservation ou paiement | Continuer seulement si un propriétaire cible pris en charge existe | Préserver l’historique contractuel ou transactionnel lorsque nécessaire |
| Champs personnalisés obsolètes | Conserver uniquement si un processus actuel les consomme | Stocker dans un export documenté si l’interprétation historique reste importante |
| Anciennes routes et alias | Rediriger les destinations de valeur | Conserver un registre des routes pour audit et dépannage |
Cette séparation empêche la cible active de devenir une copie d’une implémentation abandonnée tout en conservant les éléments dont les équipes, clients ou systèmes externes peuvent avoir besoin. L’archive doit rester consultable et reliée à des identifiants métier stables plutôt que laissée sous forme de dump de base de données non documenté.
Comment les différences de J2Store modifient le périmètre de migration
Le périmètre J2Store doit séparer traduction des enregistrements, reconstruction des relations et traitement des dépendances legacy.
| Traitement | Exemples | Implication pour le périmètre |
|---|---|---|
| Traduction directe d’enregistrements | Produits, clients, commandes, catégories, contenu et médias standards | Mettre les champs en correspondance avec le propriétaire cible pris en charge |
| Reconstruction de relations | Article-produit, utilisateur-client, produit-option, commande-enregistrement d’application | Reconstruire la relation avec des identifiants stables |
| Configuration cible | Menus, modules, templates, fiscalité, paiements, expédition, accès et langues | Affecter à la couche d’implémentation cible |
| Traduction d’extensions legacy | Abonnement, réservation, paiement partiel, processus de commande personnalisé, reporting | Définir une destination actuelle ou préserver dans une archive historique |
| Continuité avec des systèmes externes | ID ERP, CRM, comptabilité, traitement, marketplace | Conserver les identifiants durables et la responsabilité de mise en correspondance |
| Retrait intentionnel | Extensions abandonnées, routes dupliquées, champs obsolètes, contenu inutilisé | Exclure avec une décision métier documentée |
Un modèle de migration cohérent attribue à chaque valeur conservée une destination autoritative unique. Il ne prend pas l’ancien schéma J2Store pour modèle cible simplement parce que la base source le contient.
Conclusion
Les différences du modèle de données J2Store proviennent de la façon dont l’e-commerce est superposé aux articles, utilisateurs, catégories, menus, alias, modules et templates Joomla. Le sens produit est réparti entre contenu et enregistrements commerciaux. Le sens client peut couvrir identité Joomla et adresses ou commandes J2Store. Les modèles de vente spécialisés dépendent souvent de tables détenues par des applications, et les commandes historiques doivent rester compréhensibles même lorsque ces applications ne sont plus actives.
Parce que J2Store est désormais une plateforme legacy, la migration doit préserver le sens métier sans reproduire une structure technique obsolète. Le meilleur modèle cible reconnecte identité article-produit, affecte les valeurs client et commande au bon responsable de cycle de vie, traduit explicitement les données d’extensions et retire les enregistrements qui n’ont plus de consommateur valide.
Questions fréquentes
Pourquoi les articles Joomla sont-ils centraux dans le modèle de données J2Store ?
J2Store utilise les articles Joomla comme fondation de contenu des produits. Contenu, catégorie, alias, langue, accès et état de publication de l’article peuvent donc être indissociables des prix, SKU, stocks, options et enregistrements d’achat J2Store.
J2Store est-il toujours la continuation active de la plateforme ?
Non. Le développement de J2Store a été arrêté et son dépôt archivé. J2Commerce est le successeur actif. Les données J2Store existantes restent des éléments source valides, mais elles doivent être traduites vers la structure cible choisie plutôt que supposées rester opérationnelles telles quelles.
Les options J2Store sont-elles équivalentes aux variantes sur toutes les plateformes ?
Non. Un choix source peut être un SKU portant du stock, un modificateur de prix, un champ de personnalisation, une spécification ou un enregistrement d’extension. La structure cible doit suivre ce que ce choix modifie dans le comportement produit et commande.
Comment représenter les clients invités ?
Conservez les coordonnées et adresses invitées avec la commande historique, sauf si un véritable compte persistant existait. Créer des utilisateurs Joomla artificiels peut déformer l’identité et dupliquer l’historique client.
Les commandes historiques rétablissent-elles les paiements, l’expédition ou la fiscalité actifs ?
Non. Les commandes historiques préservent libellés, montants, statuts et références enregistrés. Le fonctionnement du processus de commande en production relève de la configuration cible des paiements, expéditions, taxes et devises.
Que faire des données d’une extension J2Store abandonnée ?
Déterminez si les enregistrements conservent un usage métier, légal ou opérationnel. Affectez-les à un propriétaire actuel lorsqu’il existe ; sinon, conservez-les dans une archive ou retirez-les volontairement plutôt que d’insérer des champs opaques dans des enregistrements cibles sans rapport.