EasyStore combine un composant e-commerce dédié avec les couches Joomla d’identité, d’accès, de routage, de modules et de construction de pages. Ses produits, variantes, catégories, tags, marques, collections, clients, commandes, coupons, avis et autres enregistrements commerciaux appartiennent à EasyStore, tandis que Joomla et SP Page Builder peuvent déterminer comment ces enregistrements sont atteints et présentés.
Lorsque EasyStore est la plateforme cible, la question centrale du modèle de données n’est pas de savoir si un enregistrement source peut être copié dans un champ portant un nom similaire. Il faut déterminer quel objet EasyStore doit porter le sens de la donnée et quelles relations Joomla ou de présentation doivent rester distinctes. Un catalogue source peut réunir dans un même modèle produits, options, spécifications, collections, navigation, pages d’atterrissage, identités d’acheteurs et historique transactionnel ; EasyStore répartit ces responsabilités entre enregistrements e-commerce et enregistrements servant à construire le site.
EasyStore sépare les responsabilités e-commerce et Joomla
EasyStore stocke le modèle de vente principal, tandis que Joomla fournit le cadre du site qui l’entoure. SP Page Builder peut ensuite consommer les données EasyStore et organiser le rendu de la vitrine sans devenir le système propriétaire du stock produit, de l’identité client ou de l’historique des commandes.
| Couche | Enregistrements habituels | Conséquence pour la migration |
|---|---|---|
| E-commerce EasyStore | Produits, variantes, prix, stocks, catégories, tags, marques, collections, clients, commandes, coupons, avis | Ces enregistrements forment le graphe commercial et doivent conserver leurs relations internes. |
| Noyau Joomla | Utilisateurs, niveaux d’accès, menus, modules, langues, médias, alias | Ces enregistrements peuvent contrôler l’identité, l’accessibilité, la visibilité et le contexte du site sans remplacer les entités EasyStore. |
| SP Page Builder | Mises en page et blocs de contenu EasyStore | La présentation référence les données EasyStore mais ne devient pas le système d’enregistrement des produits ou commandes. |
| Intégrations de paiement et d’expédition | Références de passerelle, transporteur et transaction | Les références historiques appartiennent aux commandes ; le fonctionnement futur relève de l’intégration cible. |
| Extensions et intégrations personnalisées | Champs supplémentaires, webhooks, identifiants externes, processus spécialisés | La responsabilité doit être identifiée avant d’affecter les valeurs aux objets cibles. |
Cette séparation évite deux erreurs fréquentes : traiter le contenu Joomla comme s’il s’agissait de données commerciales, et traiter le rendu visuel du Page Builder comme s’il contenait le modèle produit de référence.
Produits, variations et variantes doivent être traduits au niveau des relations
Un produit EasyStore peut contenir titre, alias, description, médias, tarification, traitement fiscal, dimensions d’expédition, identifiants, règles de stock, catégorie, tags, accès et valeurs SEO. Lorsque des variations sont ajoutées, EasyStore crée un sens commercial au niveau de la variante. La tarification et le stock quittent alors en partie le contexte du produit parent pour la section des variantes produit, où chaque combinaison peut porter son propre prix, sa remise, son poids, son SKU, son identifiant standardisé, sa quantité, sa disponibilité et sa visibilité.
Une plateforme source peut représenter le même assortiment sous forme de produits séparés, d’un produit unique avec options, d’une matrice de combinaisons, d’enregistrements enfants configurables ou de champs personnalisés. La cible doit décider quels enregistrements deviennent le parent EasyStore et lesquels deviennent des variantes.
| Modèle de catalogue source | Question de représentation EasyStore | Sens exposé au risque |
|---|---|---|
| Un produit par taille ou couleur | Les enregistrements doivent-ils être regroupés sous un parent unique avec variantes ? | URL, avis, médias, stocks et identifiants externes peuvent être dupliqués ou fusionnés à tort. |
| Produit parent avec SKU enfants | Quels attributs enfants définissent les valeurs de variation EasyStore ? | Les combinaisons vendables peuvent perdre leur SKU, prix, stock ou identité de visibilité. |
| Option en texte libre sur une commande | La valeur correspond-elle à une variation vendable ou à une métadonnée historique de ligne de commande ? | Les choix de l’acheteur peuvent être forcés dans une structure de variante qui ne correspond pas à la source. |
| Champs de spécification produit | Les valeurs doivent-elles devenir des Additional Data EasyStore plutôt que des variations ? | Des attributs informatifs peuvent être pris à tort pour des choix sélectionnables par l’acheteur. |
| Stock au niveau produit plus stock au niveau option | Quel niveau de stock fait autorité ? | La cible peut compter deux fois le stock ou exposer des combinaisons indisponibles. |
Les variations EasyStore ne sont pas de simples libellés d’affichage. Dès qu’un produit possède des variations, chaque variante résultante peut porter ses propres attributs commerciaux. Les identifiants source doivent donc rester attachés au niveau vendable reconnu par les systèmes externes, les processus d’entrepôt et les commandes historiques.
Additional Data, tags, marques, collections et produits associés ont des rôles différents
EasyStore propose plusieurs structures pour décrire et regrouper les produits. Additional Data peut contenir des spécifications structurées. Les tags facilitent la découverte et les classifications souples. Les marques identifient une marque ou un fabricant. Les catégories organisent la hiérarchie principale du catalogue. Les collections permettent de regrouper des produits à des fins de merchandising. Les relations de vente incitative et de vente croisée relient un produit à d’autres produits.
Ces structures ne doivent pas être ramenées à une taxonomie générique unique.
| Structure EasyStore | Rôle principal | Données source pouvant y correspondre |
|---|---|---|
| Catégorie | Organisation principale du catalogue et affectation des produits | Catégories ou départements source ayant un sens durable pour la navigation |
| Tag | Libellé souple de découverte | Mots-clés, thèmes, cas d’usage ou classifications non hiérarchiques |
| Marque | Identité de marque ou de fabricant | Enregistrements de marque, vendeur ou fabricant lorsque le sens correspond |
| Collection | Regroupement éditorial ou commercial de produits | Groupes de campagne, assortiments saisonniers, gammes mises en avant ou collections éditoriales |
| Additional Data | Spécifications informatives sur le produit | Attributs techniques, matières, dimensions, compatibilités ou faits descriptifs |
| Relation de vente incitative / croisée | Lien commercial de produit à produit | Références de produits associés, complémentaires, de remplacement ou de valeur supérieure |
Une « collection » source peut correspondre à une catégorie, un groupe généré par règle, une page d’atterrissage ou une campagne. Sa représentation cible doit suivre sa finalité métier plutôt que son libellé. Le même principe s’applique aux attributs : une taille choisie par l’acheteur appartient à la structure de variation, tandis qu’une spécification technique non sélectionnable relève plutôt d’Additional Data ou d’un autre champ descriptif.
Les catégories EasyStore ne sont ni les menus Joomla ni les mises en page Page Builder
Les catégories EasyStore organisent les produits dans le modèle e-commerce. Les éléments de menu Joomla rendent les pages accessibles et peuvent définir alias, chemins de routage, accès, langue et contexte de template. Les mises en page SP Page Builder organisent les composants et les blocs EasyStore sur les pages. Une seule page d’atterrissage de la vitrine peut dépendre de ces trois couches.
| Concept de vitrine | Responsable EasyStore | Relation Joomla ou de présentation |
|---|---|---|
| Hiérarchie de liste des produits | Arborescence des catégories EasyStore | Un élément de menu peut exposer une route de catégorie ou une page organisée manuellement. |
| URL produit | Alias du produit EasyStore et routage du composant | Le contexte du menu Joomla peut influencer la route publique. |
| Page de campagne | Références vers des produits ou collections EasyStore | Une mise en page SP Page Builder peut organiser le contenu de la campagne. |
| Libellé de navigation | Élément de menu Joomla | Il peut pointer vers une catégorie, collection, produit EasyStore ou une page personnalisée. |
| Bloc produit | Source de données EasyStore | Le bloc SP Page Builder contrôle le placement et la présentation. |
Cette séparation est importante lorsque la plateforme source stocke navigation et regroupement du catalogue sous la forme d’un même objet. Recréer seulement l’arborescence de catégories peut ne pas recréer la navigation publique, tandis que copier uniquement des mises en page peut laisser les produits déconnectés de leurs catégories et collections de référence.
Les clients EasyStore et les utilisateurs Joomla peuvent être liés sans être le même enregistrement
EasyStore peut maintenir des enregistrements client et convertir un utilisateur Joomla existant en client. Cette relation ne rend pas les deux concepts identiques. Joomla détient l’identité de connexion, l’état du compte, les groupes d’utilisateurs et les accès. EasyStore détient le profil acheteur et les relations commerciales nécessaires à l’activité de la vitrine.
Une plateforme source peut contenir des clients enregistrés, des acheteurs invités, des administrateurs n’ayant jamais acheté et des clients dont l’historique transactionnel utilise une adresse e-mail différente de celle du compte actuel. Ces situations ne doivent pas être normalisées dans une forme de compte unique au détriment du sens historique.
| Modèle d’identité source | Décision de relation dans EasyStore |
|---|---|
| Acheteur enregistré avec connexion équivalente sous Joomla | Relier le client EasyStore au bon utilisateur Joomla lorsque la cible prend en charge cette identité. |
| Acheteur invité | Préserver les informations de l’acheteur et ses adresses avec les commandes historiques sans inventer de compte permanent. |
| Plusieurs comptes source partageant la même adresse e-mail | Décider si les identités restent séparées, sont consolidées ou nécessitent une clé externe. |
| Compte d’employé ou d’administrateur | Garder l’identité d’autorisation distincte du statut client, sauf si la personne est également acheteuse. |
| Contact B2B lié à une organisation | Ne pas réduire organisation, contact, tarification et autorisations à un simple enregistrement client. |
Les groupes d’utilisateurs Joomla doivent également rester distincts des segments commerciaux. Un groupe utilisé pour des autorisations administratives ou du contenu restreint n’est pas automatiquement équivalent à un groupe de clients, une audience de remise ou un niveau de vente en gros.
Les commandes préservent des instantanés commerciaux, pas une configuration active
Une commande EasyStore représente une transaction historique. Son sens utile peut inclure l’identité du client ou de l’acheteur invité, les adresses, les produits et variantes choisis, les quantités, prix, remises, taxes, expédition, références de paiement, statuts, remboursements ou annulations, notes et horodatages. Ces valeurs constituent des instantanés de ce qui s’est produit au moment de l’achat.
Les données historiques de commande ne doivent pas servir de substitut à la configuration actuelle des produits, taxes, expéditions, paiements ou du processus de commande. Le libellé d’une méthode d’expédition dans une ancienne commande enregistre la méthode utilisée à l’époque ; il ne définit pas la configuration du transporteur cible. Une référence de paiement conserve le contexte transactionnel ; elle ne configure pas une passerelle.
| Relation de commande | Sens historique à préserver |
|---|---|
| Référence produit ou variante | Quel article vendable a été acheté, avec l’identifiant source lorsque nécessaire |
| Description de ligne et valeurs sélectionnées | L’article et les choix visibles par l’acheteur tels qu’enregistrés au moment de l’achat |
| Relation client ou invité | Qui a passé la commande et quelles adresses ont été utilisées |
| Prix, remise, taxe et total | L’instantané commercial, sans recalcul selon les règles actuelles |
| Référence d’expédition et de paiement | La méthode et le contexte transactionnel enregistrés pour cette commande |
| Statut et chronologie | Les éléments du cycle de vie nécessaires au support et au reporting |
| Informations de remboursement ou d’annulation | La modification historique de la transaction initiale |
Lorsque la plateforme source stocke les lignes de commande indépendamment des enregistrements produit actuels, ces instantanés doivent rester lisibles même si le catalogue courant a changé, qu’un SKU a été retiré ou qu’une variante a été réorganisée.
Coupons, avis et autres relations ont leurs propres responsables
Les coupons et les avis sont liés au catalogue et aux clients, mais ne sont pas des champs produit. Un coupon peut contenir des critères d’éligibilité, un type de remise, des dates, des règles d’usage et des relations avec des produits, catégories ou clients. Un avis peut relier une identité client ou invitée à un produit, une note, un texte, un statut et un horodatage.
Traiter ces enregistrements comme du contenu décoratif fait perdre leur sens relationnel. Un avis sans lien correct vers le produit devient orphelin. Un coupon copié comme simple code sans ses contraintes peut représenter une règle commerciale différente. Une liste de souhaits, un événement d’analyse ou un panier abandonné peut relever d’une autre zone EasyStore ou d’un service externe et ne doit pas être déduit des seules données client ou commande.
L’intégration SP Page Builder représente des références de présentation
EasyStore peut fournir des produits et éléments e-commerce aux mises en page SP Page Builder. Les blocs du Page Builder peuvent afficher listes de produits, recherche, catégories, filtres, prix, notes, titres, contrôles de panier, listes de souhaits, avis et autres éléments de vitrine. Ces blocs référencent les données commerciales ; ils ne détiennent ni le stock produit ni l’historique des commandes.
Un constructeur visuel source peut intégrer des références au catalogue directement dans du JSON de page ou des enregistrements de mise en page. Le modèle cible doit séparer le contenu éditorial réutilisable, la configuration de mise en page statique et les références dynamiques vers EasyStore.
| Élément Page Builder | Interprétation des données |
|---|---|
| Bloc de liste de produits | Requête de présentation ou référence vers des produits EasyStore |
| Bloc de catégorie | Relation d’affichage avec une catégorie EasyStore |
| Bloc de prix, note, titre ou vignette | Champs rendus depuis le contexte produit |
| Contrôle de panier ou de liste de souhaits | Élément interactif de la vitrine, pas données historiques de panier |
| Bloc de texte ou d’image statique | Contenu de page pouvant nécessiter une migration de contenu indépendante |
| Surcharge de mise en page personnalisée | Implémentation de présentation plutôt qu’entité e-commerce standard |
Cette distinction permet aux produits et catégories de rester les sources de référence tandis que les mises en page sont recréées ou adaptées selon le modèle de présentation de la cible.
Paramètres, intégrations et données personnalisées doivent être classés selon leur responsabilité
Les paramètres EasyStore peuvent définir fiscalité, fonctionnement du processus de commande, paiements, expédition, notifications par e-mail, comportement du stock et règles d’affichage. Ils influencent le fonctionnement en production mais ne sont pas équivalents aux produits, clients ou commandes. Les enregistrements historiques peuvent faire référence à leurs résultats sans transporter la configuration future elle-même.
Transporteurs personnalisés, intégrations de paiement, extensions développées, champs de base de données personnalisés, webhooks et identifiants de systèmes externes peuvent ajouter d’autres couches de responsabilité. Le modèle cible doit déterminer si chaque valeur est un enregistrement EasyStore principal, une identité ou route Joomla, une référence SP Page Builder, un enregistrement d’intégration ou une clé de système externe.
| Signal de donnée personnalisée | Exigence de migration |
|---|---|
| Identifiant ERP ou entrepôt au niveau variante | Le préserver sur la bonne variante vendable et pas uniquement sur le produit parent. |
| Champ client personnalisé | Déterminer si la valeur relève d’EasyStore, des données utilisateur Joomla ou d’un profil externe. |
| Référence de transaction de passerelle | La conserver avec la commande historique et le contexte de paiement. |
| Identifiant d’expédition propre à un transporteur | Le conserver avec la commande ou la relation de traitement qui l’utilise. |
| Source de données Page Builder personnalisée | Identifier l’entité EasyStore référencée et la configuration de présentation distincte. |
| Table détenue par une extension | Définir l’entité parente, la finalité métier et le responsable cible avant migration. |
Un modèle de migration EasyStore propre est donc avant tout une carte de responsabilités : les entités commerciales restent dans EasyStore, la connexion et les accès restent dans Joomla, la composition visuelle reste dans SP Page Builder ou dans la couche de présentation cible, et les identifiants externes restent attachés aux enregistrements reconnus par les systèmes connectés.
Conclusion
La migration des données EasyStore exige davantage que la création de produits et de clients. Les produits peuvent contenir des enregistrements commerciaux au niveau des variantes ; catégories, tags, marques, collections et spécifications jouent des rôles différents dans la découverte ; les utilisateurs Joomla et clients EasyStore peuvent être reliés sans devenir la même entité ; les commandes conservent des instantanés historiques ; et les mises en page SP Page Builder référencent les données e-commerce sans en devenir propriétaires.
Maintenir ces frontières explicites produit un modèle cible qui soutient la gestion du catalogue, l’identité client, le service historique, la présentation de la vitrine et la continuité des systèmes connectés sans aplatir les couches Joomla et EasyStore dans un ensemble d’enregistrements ambigu.
Questions fréquentes
Les variations EasyStore sont-elles uniquement des options d’affichage ?
Non. Une fois les variations créées, les variantes EasyStore peuvent porter leur propre prix, remise, traitement fiscal, données d’expédition, SKU, identifiants standardisés, stock, disponibilité et visibilité. Elles doivent être traitées comme des enregistrements vendables lorsque la source utilise des combinaisons équivalentes.
Les spécifications produit doivent-elles devenir des variations ?
Uniquement lorsque la valeur définit une combinaison vendable et sélectionnable par l’acheteur. Les spécifications informatives sont mieux représentées via Additional Data ou une autre structure descriptive afin de ne pas créer de variantes artificielles.
Les catégories EasyStore sont-elles identiques aux éléments de menu Joomla ?
Non. Les catégories EasyStore organisent les produits. Les éléments de menu Joomla créent la navigation et le contexte de routage et peuvent pointer vers une catégorie, un produit, une collection ou une page Page Builder.
Un utilisateur Joomla et un client EasyStore peuvent-ils être liés ?
Oui. EasyStore permet de convertir un utilisateur Joomla en client, mais l’utilisateur Joomla reste l’identité de connexion tandis qu’EasyStore détient le profil commercial et ses relations client.
Les commandes migrées configurent-elles le paiement, l’expédition ou la fiscalité ?
Non. Les commandes préservent le contexte historique des transactions. Le fonctionnement futur des paiements, de l’expédition, de la fiscalité et du processus de commande relève des paramètres EasyStore et des intégrations activées sur la cible.
Comment traiter les mises en page de vitrine SP Page Builder ?
Il faut les séparer en contenu de page statique, configuration de présentation et références vers les entités EasyStore. Les données produit et commande doivent rester autoritatives dans EasyStore même lorsque Page Builder détermine l’apparence des éléments de vitrine.