VirtueMart stocke ses enregistrements e-commerce dans un environnement Joomla, mais n’utilise pas le même modèle où un Article sert de Product que J2Store ou J2Commerce. Les Products, Product Categories, fabricants, prix, stocks, champs personnalisés, groupes d’acheteurs, règles de calcul, Orders, méthodes d’expédition et moyens de paiement appartiennent à VirtueMart. Joomla fournit autour de ces enregistrements l’identité utilisateur, les menus, modules, templates, langues, règles d’accès, routes et environnement d’extensions.
Cette séparation de responsabilité transforme la migration en un problème de reconstruction des relations. Une variante source peut devenir un Product enfant, un champ personnalisé ou une autre relation structurée. Un segment Customer peut devenir un groupe d’acheteurs qui influence les prix ou la disponibilité de certaines méthodes. Une valeur de taxe ou de remise peut être une donnée historique dans un ancien Order ou, au contraire, une règle de calcul active pour les futurs paniers. La bonne destination dépend donc du rôle métier de la donnée source.
Frontières de responsabilité entre Joomla et VirtueMart
Une boutique VirtueMart repose sur deux modèles reliés. Le composant e-commerce possède le catalogue et les enregistrements transactionnels, tandis que Joomla possède une grande partie du contexte de site et d’identité qui les expose.
| Domaine métier | Propriétaire principal dans la cible | Relation à préserver |
|---|---|---|
| Identité Product et champs du catalogue | VirtueMart | Product vers Category, fabricant, médias, prix, stock, champs personnalisés et Products associés |
| Connexion utilisateur | Utilisateur Joomla | Utilisateur vers acheteur VirtueMart et adresses |
| Segmentation des acheteurs | Groupe d’acheteurs VirtueMart, parfois combiné à l’accès Joomla | Acheteur vers prix, visibilité, taxe, paiement ou expédition |
| Route de la boutique | Menu Joomla, routeur, alias, langue et vue VirtueMart | Product ou Category vers la destination privilégiée côté acheteur |
| Affichage Product | Layouts VirtueMart plus template et modules Joomla | Identifiants des enregistrements vers le bon rendu de page |
| Paiement et expédition | Méthodes et plugins VirtueMart | Règles actives vers les éléments historiques des Orders et le fonctionnement du checkout |
Un Product peut être présent dans VirtueMart alors que sa route côté acheteur, son placement dans un module ou son contexte linguistique est absent. Un utilisateur Joomla peut exister alors que le groupe d’acheteurs, l’adresse ou l’historique Order associé est déconnecté. Les deux côtés de chaque relation doivent donc avoir un propriétaire explicite.
Products, Categories, fabricants et médias
Les Products VirtueMart peuvent être reliés à de nombreuses structures commerciales. Un Product source peut nécessiter une ou plusieurs Categories, un fabricant, des images et fichiers, des champs de stock, dimensions, disponibilité, prix, taxes, groupes d’acheteurs, champs personnalisés, Products enfants, Products associés, avis et contenus traduits.
| Sens dans la source | Question de destination dans VirtueMart | Relation requise |
|---|---|---|
| Classification Product | Dans quelles Categories VirtueMart le Product doit-il apparaître ? | Affectations Product-Category et hiérarchie voulue |
| Identité de marque | S’agit-il d’un fabricant, d’une Category, d’un champ personnalisé ou d’une clé externe ? | Relation Product-fabricant et éventuelle page de marque |
| Galerie et fichiers | Quels médias sont des images, fichiers téléchargeables ou ressources de contenu ? | Rôle du média, relation au Product, ordre et visibilité |
| Product associé ou accessoire | La relation sert-elle au merchandising, à la compatibilité, au remplacement ou à un bundle ? | Relation Product-Product avec un objectif défini |
| Stock et dimensions | Les valeurs appartiennent-elles au Product ou à un Product enfant précis ? | Responsabilité du stock et des données sensibles à l’expédition |
| Avis et notes | S’agit-il d’enregistrements VirtueMart natifs, de contenu Joomla ou de données d’extension ? | Auteur, Product, note, texte et état de publication |
La traduction des Categories ne doit pas être confondue avec la navigation Joomla. Les Categories VirtueMart organisent le catalogue commercial ; les éléments de menu Joomla exposent certaines vues Category ou Product. Une hiérarchie Category source peut donc être migrée correctement alors que la navigation cible utilise une structure de routes différente.
Les enregistrements fabricant nécessitent eux aussi une revue sémantique. Une marque source peut n’être qu’un texte affiché, ou elle peut alimenter des filtres, pages dédiées, exports de flux, règles tarifaires ou clés d’intégration externes. La cible doit préserver les fonctions encore utiles au lieu de convertir automatiquement chaque libellé de marque en un objet unique.
Products enfants, champs personnalisés et sens des variantes
Les champs personnalisés VirtueMart peuvent décrire les Products, recueillir des informations saisies par l’acheteur, relier d’autres enregistrements, déclencher un comportement de plugin ou participer à des structures Product sélectionnables. Les Products enfants peuvent disposer de leur propre SKU, prix, stock, dimensions, images ou disponibilité. Puisque les deux mécanismes peuvent apparaître comme des choix dans la vitrine, toutes les « variantes » source ne doivent pas être traitées de la même façon.
| Fonctionnement dans la source | Représentation possible dans VirtueMart | Sens à préserver |
|---|---|---|
| Une taille ou une couleur possède son propre SKU et son propre stock | Relation Parent Product / Product enfant, souvent exposée via un champ sélectionnable | Chaque choix doit résoudre vers le bon stock et la bonne identité de ligne Order |
| Un choix modifie le prix mais partage le stock | Champ personnalisé Product ou relation de prix configurée | L’ajustement de prix reste lié au choix sélectionné |
| L’acheteur saisit du texte ou envoie des informations | Champ personnalisé de saisie acheteur ou enregistrement d’extension | La valeur saisie reste attachée au bon élément Order |
| Spécification technique | Champ personnalisé descriptif | La valeur reste lisible et, lorsque nécessaire, filtrable |
| Product ou Category associé | Relation de champ personnalisé au niveau système | Le lien continue de résoudre vers l’enregistrement attendu |
| Configurateur piloté par plugin | Champ personnalisé appartenant au plugin et tables de données associées | L’état de configuration dispose d’un propriétaire cible pris en charge |
La décision de correspondance doit être guidée par cinq questions : le choix modifie-t-il le SKU, le stock, le prix, l’image ou le traitement logistique ? Si aucune de ces dimensions ne change, la valeur peut être descriptive plutôt qu’une variante. Si plusieurs changent, un Product enfant ou une structure appartenant à un plugin est plus probable qu’un simple champ texte.
Les champs personnalisés sont des définitions réutilisables qui peuvent ensuite être affectées aux Products. Leur définition, type, ordre, visibilité, propriété du plugin et valeur propre à chaque Product constituent des relations distinctes. Copier uniquement la valeur affichée peut faire perdre la définition qui rend cette valeur sélectionnable ou exploitable.
Groupes d’acheteurs, prix et règles de calcul
Les groupes d’acheteurs VirtueMart peuvent influencer la visibilité du catalogue, les prix Product, taxes, moyens de paiement, méthodes d’expédition et d’autres règles commerciales. Un groupe Customer source n’est donc pas nécessairement l’équivalent d’une simple étiquette de groupe d’acheteurs VirtueMart.
Les prix peuvent également dépendre du contexte. Un Product peut avoir des prix associés à des plages de quantité, groupes d’acheteurs, devises ou autres conditions. Les règles de calcul peuvent appliquer taxes, remises, marges ou modifications de prix et être restreintes selon la Product Category, le fabricant, le groupe d’acheteurs, le pays, la région, la devise ou la date.
| Règle source | Relation VirtueMart | Conséquence pour la migration |
|---|---|---|
| Liste de prix de gros | Groupe d’acheteurs plus enregistrements de prix Product | L’appartenance du Customer et son éligibilité tarifaire doivent rester reliées |
| Acheteurs exonérés de taxe | Groupe d’acheteurs, localisation de l’adresse et règles de calcul | Identité, géographie et conditions de la règle doivent être cohérentes |
| Remise sur une Category | Product Category plus règle de calcul | La règle dépend de l’appartenance à la Category, pas d’un champ de remise copié |
| Taxe régionale | Contexte pays/région plus règle de calcul | L’adresse Customer ou Order fournit une partie des données nécessaires à la règle |
| Promotion limitée dans le temps | Règle de calcul ou coupon avec dates | La période active et l’opération arithmétique doivent rester explicites |
| Prix propre à une devise | Relation entre prix et devise | Montant, devise et contexte d’affichage ne doivent pas être confondus |
Les montants historiques des Orders et la logique de calcul active appartiennent à des couches différentes. Un ancien Order doit préserver la taxe, la remise, la devise et le total réellement enregistrés. Il n’a pas besoin du moteur de calcul actuel pour recalculer son historique. Le checkout futur dépend, au contraire, des règles actives dans la cible.
Acheteurs, adresses, champs et Orders
VirtueMart relie généralement un utilisateur Joomla à un enregistrement d’acheteur, à des groupes d’acheteurs et à des informations d’adresse. Des Orders invités peuvent exister sans compte Joomla réutilisable. Les champs d’acheteur peuvent recueillir des informations d’inscription, de facturation, d’expédition, fiscales, d’entreprise ou propres à une transaction.
Le modèle cible doit affecter chaque champ selon son cycle de vie :
- l’identité permanente de connexion appartient à l’utilisateur Joomla ;
- la segmentation réutilisable de l’acheteur appartient aux relations de groupes d’acheteurs ;
- les informations de facturation ou d’expédition réutilisables appartiennent aux enregistrements d’acheteur/adresse ;
- les informations invité appartiennent à l’instantané de l’Order ;
- les notes de livraison ou instructions d’achat ponctuelles appartiennent à l’Order ;
- les valeurs d’adhésion ou de consentement appartenant à une extension restent sous la responsabilité du système qui les utilise.
Les Orders constituent des éléments historiques. Ils peuvent contenir des instantanés Product, sélections de champs personnalisés, identité du Product enfant, quantités, prix, taxes, remises, coupons, contexte de groupe d’acheteurs, adresses, libellés de paiement et d’expédition, statuts, devise, notes et factures.
| Élément historique de l’Order | Pourquoi la relation est importante |
|---|---|
| Product et Product enfant | Identifie l’article vendable exact, et pas seulement le Product parent |
| Sélection de champ personnalisé | Explique la configuration, la personnalisation ou le sens d’une option Product |
| Instantané de l’acheteur et de l’adresse | Préserve l’identité de l’acheteur ainsi que l’adresse de facturation ou d’expédition utilisée |
| Prix, taxe, remise et devise | Explique le résultat financier historique |
| Moyen de paiement et méthode d’expédition | Fournit le contexte nécessaire au support et au traitement logistique |
| Statut et horodatages | Retrace l’historique opérationnel de l’Order |
| Référence externe | Relie les enregistrements comptables, ERP, transporteur ou marketplace |
Les plugins de paiement et d’expédition peuvent créer des métadonnées supplémentaires. Le libellé historique et la référence du fournisseur peuvent appartenir à l’Order migré, tandis que la configuration actuelle du plugin appartient à l’environnement cible.
Vitrine, langues, URL et présentation Joomla
Les enregistrements Product et Category de VirtueMart ne déterminent pas à eux seuls le site vu par l’acheteur. Les menus Joomla, modules, surcharges de templates, alias, affectations de langue, niveaux d’accès et mécanismes de routage façonnent la vitrine finale.
Une URL source peut dépendre de slugs Product, de Categories imbriquées, de préfixes de langue, d’alias de menu ou d’une extension SEO. Les routes VirtueMart peuvent dépendre à la fois des alias commerciaux et du contexte de menu Joomla. La migration doit donc identifier la destination canonique de chaque Product et Category à forte valeur, puis relier les redirections à cette destination.
Les données multilingues peuvent couvrir les enregistrements Product et Category traduits, les textes fabricant, les libellés de champs personnalisés, menus Joomla, modules et métadonnées. Une relation de langue n’est complète que lorsque les enregistrements e-commerce traduits se résolvent dans le bon contexte Joomla de langue et de route.
| Couche de la vitrine | Responsabilité dans le modèle de données |
|---|---|
| Alias Product et Category VirtueMart | Identité côté commerce utilisée par les routes |
| Élément de menu Joomla | Point d’entrée et contexte de route d’une vue |
| Module | Requête et emplacement qui affichent des Products ou Categories |
| Surcharge de template | Logique de présentation qui attend certains champs ou identifiants |
| Association linguistique | Relation entre contenus, menus et enregistrements e-commerce traduits |
| Métadonnées et destination canonique | Responsabilité de la page vis-à-vis des moteurs de recherche |
La logique de présentation ne doit pas être injectée dans les champs Product pour reproduire une page. Elle doit rester dans la couche de présentation Joomla/VirtueMart de la cible et consommer les enregistrements traduits par des relations stables.
Données appartenant aux plugins, données personnalisées et systèmes externes
Les boutiques VirtueMart utilisent souvent des extensions de paiement, expédition, champs personnalisés, abonnement, configurateur Product, recherche, flux, facture, marketplace, comptabilité ou traitement logistique. Elles peuvent créer des tables et références qui ne font pas partie du modèle Product, acheteur ou Order standard.
| Dépendance | Données pouvant se trouver hors des enregistrements du cœur | Question de destination |
|---|---|---|
| Plugin de champ personnalisé | Valeurs de configurateur, fichiers fournis par l’acheteur, relations avec Products enfants, logique de prix | Existe-t-il un plugin équivalent ou un enregistrement structuré dans la cible ? |
| Extension d’abonnement ou récurrence | Plans, cycles, renouvellements, références de passerelle, droits | Quel système possédera l’état récurrent après la migration ? |
| Constructeur Product ou extension de bundle | Products composants, formules, configurations enregistrées | La cible peut-elle représenter la configuration sans l’aplatir ? |
| Plugin de paiement ou d’expédition | Identifiants de transaction, libellés, suivi, métadonnées de méthode | Quelles valeurs sont des éléments historiques et lesquelles relèvent de la configuration active ? |
| Intégration ERP ou comptable | Clés Product, Customer, taxe, facture et Order | Quels identifiants sont durables et font autorité dans les systèmes externes ? |
| Surcharge de template ou module | Attentes sur les champs et règles d’affichage | Quels identifiants traduits doivent rester stables pour la présentation ? |
Les colonnes personnalisées de base de données ne sont pas auto-explicatives. Leur nom révèle parfois le stockage, mais pas leur fonction métier. Chaque valeur conservée doit avoir un consommateur identifié, un cycle de vie et une relation cible définie.
Comment les différences de VirtueMart modifient le périmètre de migration
Le périmètre VirtueMart doit être exprimé sous forme de traitements relationnels :
| Traitement | Exemples VirtueMart typiques | Conséquence sur le périmètre |
|---|---|---|
| Traduction directe d’enregistrements | Products, Categories, fabricants, acheteurs, Orders, médias | Mettre en correspondance les champs et identifiants standard |
| Reconstruction des relations | Parent/child Products, affectations de champs personnalisés, groupes d’acheteurs, prix, conditions des règles de calcul | Reconstruire les liens et les entrées nécessaires aux règles |
| Structure de présentation Joomla | Menus, modules, routes, contexte linguistique, surcharges de templates | Affecter ces éléments à l’implémentation du site cible |
| Données appartenant aux plugins | Configurateurs, abonnements, champs spéciaux de checkout, métadonnées de méthode | Définir une destination prise en charge ou une archive séparée |
| Continuité avec les systèmes externes | Identifiants ERP, comptables, logistiques, de flux ou marketplace | Préserver les clés durables et leur propriétaire |
| Retrait volontaire | Plugins obsolètes, champs personnalisés inutilisés, routes dupliquées, règles abandonnées | Exclure avec une raison documentée |
Le modèle de données est cohérent lorsqu’un Product peut être suivi à travers ses Categories, Products enfants, champs personnalisés, prix, stocks, règles de groupes d’acheteurs, lignes Order, routes Joomla et identifiants externes sans dépendre d’hypothèses techniques non documentées.
Conclusion
Les différences du modèle de données VirtueMart proviennent de l’interaction entre les enregistrements e-commerce VirtueMart et les structures du site Joomla. Les Products peuvent dépendre de Categories, fabricants, médias, Products enfants, champs personnalisés, groupes d’acheteurs, prix, règles de calcul et plugins. Les Customers peuvent traverser les utilisateurs Joomla, enregistrements d’acheteurs, adresses et groupes. Les Orders conservent des instantanés qui doivent rester compréhensibles même si les règles et plugins actuels changent.
Une migration fiable traduit explicitement ces relations. Elle sépare les éléments historiques des Orders de la logique active de calcul et de checkout, maintient le routage Joomla distinct des enregistrements Product et donne aux données appartenant à des plugins ou à des systèmes externes une destination claire. Le sens commercial est ainsi préservé au lieu de simplement reproduire les lignes de base de données.
Questions fréquentes
Pourquoi toutes les variantes VirtueMart ne peuvent-elles pas être représentées par un seul type d’option ?
Certains choix sont des Products enfants dotés de leur propre SKU, stock, prix, image ou dimensions. D’autres sont des modificateurs de prix, des champs personnalisés descriptifs, des saisies d’acheteur ou des configurations appartenant à des plugins. Leur fonction métier détermine la structure cible.
Quelle est la différence entre une définition de champ personnalisé et une valeur Product ?
La définition établit le type de champ, son fonctionnement, sa visibilité et l’éventuelle logique de plugin. L’affectation au Product fournit la valeur ou la sélection propre à ce Product. Les deux relations peuvent être nécessaires au fonctionnement de la vitrine.
Comment les groupes d’acheteurs influencent-ils le modèle de données ?
Ils peuvent influencer les prix, la visibilité, les taxes, les moyens de paiement, les méthodes d’expédition et d’autres règles. Conserver uniquement le nom du groupe sans ses membres ni les règles qui le consomment ne préserve pas le sens métier.
Faut-il recalculer les Orders historiques avec les règles de taxe et de remise de la cible ?
Non. Les Orders historiques doivent conserver les montants et libellés enregistrés lors de l’achat. Les règles actives de la cible gouvernent les nouveaux paniers et doivent rester séparées de l’instantané historique.
Pourquoi les menus Joomla sont-ils importants alors que les Products sont stockés dans VirtueMart ?
Les menus peuvent établir le contexte de route et les points d’entrée de la vitrine. Les alias Product et Category peuvent être corrects alors que l’URL privilégiée côté acheteur dépend encore des relations avec les menus et les langues Joomla.
Comment faut-il traiter les données appartenant aux plugins ?
Il faut identifier les enregistrements créés par le plugin, les relations Product, acheteur ou Order qu’il utilise et le système cible qui assumera la même fonction métier. Seules les valeurs ayant un usage futur clairement défini doivent être préservées.