Joomla ne représente pas un site web comme une simple collection de pages et ne fournit pas non plus un schéma e-commerce universel. Son modèle sépare enregistrements de contenu, arbres de Categories, routes de menus, Modules, affectations de templates, Users, contrôles d’accès, langues, médias, champs personnalisés et données appartenant aux extensions. Une page apparemment simple dans le navigateur peut donc dépendre de plusieurs enregistrements ayant des propriétaires différents.
Lorsque Joomla est la plateforme cible, la planification doit traduire des relations plutôt que copier uniquement des champs texte. Un Article peut contenir le contenu principal, tandis qu’un Menu Item détermine la route publique, une Category fournit le contexte d’organisation, un Access Level contrôle la visibilité, un Module apporte du contenu complémentaire et une extension possède le processus métier derrière la page. Préserver seulement le contenu visible peut laisser dans la cible des enregistrements présents mais privés de leur sens de navigation, permission, langue ou application.
Joomla sépare contenu, routage, présentation et données applicatives
Joomla core fournit des structures réutilisables, mais chacune possède une responsabilité distincte. Articles et autres enregistrements de Components contiennent le contenu. Categories regroupent les enregistrements du composant propriétaire. Menus créent navigation et relations de route. Modules placent du contenu réutilisable autour d’une page. Templates et overrides déterminent la présentation. Users, groupes et niveaux d’accès contrôlent identité et visibilité. Components, plugins et code personnalisé ajoutent des enregistrements propres à une application.
| Couche Joomla | Signification principale | Conséquence pour la migration |
|---|---|---|
| Articles et enregistrements de Components | Contenu éditable ou enregistrements appartenant à une application | La cible doit identifier le véritable propriétaire au lieu de traiter chaque page visible comme un Article. |
| Categories | Regroupement hiérarchique dans un composant précis | Une Category de contenu et une Category e-commerce peuvent avoir le même libellé tout en appartenant à des partitions différentes. |
| Menus et Menu Items | Navigation, route, alias, langue, accès et contexte de page | Les URL publiques et points d’entrée peuvent dépendre des relations de Menu Item plutôt que du seul titre d’Article. |
| Modules | Blocs réutilisables affectés à des positions et pages | Le contenu complémentaire peut nécessiter son propre enregistrement cible et une relation d’affectation. |
| Templates et overrides | Mise en page et rendu | Ce sont des actifs de présentation, pas des substituts aux données métier ou au contenu migré. |
| Users, groupes et niveaux d’accès | Identité, permissions et visibilité | Un compte Joomla ne peut pas être interprété automatiquement comme un Customer ou un segment commercial. |
| Components, plugins et tables personnalisées | Fonctionnement et enregistrements propres à un domaine | Commerce, memberships, formulaires, annuaires, téléchargements et intégrations exigent une interprétation par propriétaire. |
Ce modèle en couches constitue la différence centrale de Joomla. Un même champ source peut devenir contenu core, paramètre de Menu Item, champ personnalisé, enregistrement de composant, relation User ou exigence d’implémentation en cible selon sa fonction réelle.
Articles, Categories et Menu Items portent des relations différentes
Un Article est un enregistrement de contenu. Une Category regroupe des enregistrements appartenant au même composant Joomla. Un Menu Item est un enregistrement de navigation et routage qui peut pointer vers un Article, une vue de Category, un composant tiers, un lien système ou une autre destination. Ces objets peuvent décrire une même page publique sans être interchangeables.
Les Categories Joomla sont liées au composant. L’arbre du contenu core est distinct des partitions de Categories utilisées par d’autres composants compatibles. Cela compte lorsqu’une plateforme source possède une taxonomie universelle : une « Category » source peut devoir devenir une Category de contenu Joomla, une Category d’extension e-commerce, un tag, une branche de menu ou plusieurs enregistrements coordonnés.
Les Menu Items portent des données structurelles absentes des contenus : leurs alias peuvent former les chemins d’URL, leurs relations parent-enfant créent les arbres de menus, la langue et les paramètres d’accès déterminent la disponibilité, les références de composant indiquent la vue ouverte et l’affectation de style peut changer la présentation d’une route donnée.
| Concept source | Représentation Joomla possible | Signification à garder explicite |
|---|---|---|
| Page éditoriale | Article + un ou plusieurs Menu Items | L’Article possède le contenu ; le Menu Item possède le point d’entrée navigable et le contexte de route. |
| Landing page de Product Category | Category e-commerce + Menu Item Joomla | Regroupement commercial et navigation publique restent deux relations distinctes. |
| Section de bibliothèque de ressources | Category, Articles tagués, Menu Item et Modules | Classification, contenu, route et affichages complémentaires peuvent avoir des propriétaires distincts. |
| Alias d’URL direct | Alias de Menu Item, sortie du routeur du composant ou redirection | Le chemin public ne doit pas être déduit uniquement du titre. |
| Landing page masquée | Enregistrement publié sans entrée visible, ou Menu Item masqué | L’absence de navigation visible ne signifie pas non-publication ou absence d’URL. |
Le modèle cible doit donc préserver à la fois l’identité de l’enregistrement et l’identité de la route. Les fusionner trop tôt peut casser alias, chemins parents, entrées par langue, breadcrumbs, accès ou liens depuis d’autres contenus.
Modules, templates et overrides ne sont pas des corps de page
Joomla assemble les pages avec davantage que la sortie du composant principal. Les Modules peuvent fournir navigation, bannières, formulaires, recherche, accès compte, changement de langue, contenu associé, HTML personnalisé ou blocs propres à une extension. Leur sens dépend du type, de la position, de l’état de publication, de la langue, de l’accès et des Menu Items auxquels ils sont affectés.
Une plateforme source peut stocker tout le contenu d’une page dans un seul layout alors que Joomla répartit le résultat entre Article ou vue de composant et plusieurs Modules. L’inverse peut également se produire. Le modèle de migration doit déterminer si un Module reste un bloc réutilisable, devient du contenu intégré, correspond à un widget cible ou relève d’une implémentation de design distincte.
Templates et overrides constituent une autre frontière. Un style de template peut être affecté par les Menu Items, et un override peut changer le rendu d’un composant ou Module sans modifier l’enregistrement sous-jacent. Les données Product, Article, Customer ou Order peuvent donc rester migrables même si l’ancien rendu n’est pas reproductible comme donnée.
| Objet de présentation Joomla | Ce qu’il possède | Ce qu’il ne possède pas |
|---|---|---|
| Module | Enregistrement réutilisable et contexte d’affectation | Enregistrement métier principal rendu par un composant. |
| Position de Module | Identifiant de placement attendu par un template | Contenu stocké dans le Module. |
| Style de template | Configuration visuelle pour certaines routes | Sens d’un Article, Product, Customer ou Order. |
| Layout override | Logique de rendu modifiée | Enregistrement portable vers une autre cible par défaut. |
| Custom HTML Module | Contenu réutilisable hors Article | Route complète de page ou fonctionnement applicatif. |
Maintenir ces frontières évite de prendre des artefacts de présentation pour du contenu manquant ou d’enfouir les données métier dans une discussion de reconstruction visuelle.
Joomla Users, groupes, niveaux d’accès et Customers sont des concepts distincts
Un Joomla User est avant tout une identité de connexion au site ou à l’administration. Le compte peut contenir username, e-mail, statut, préférences, appartenance aux groupes et contexte de permissions. L’ACL Joomla distingue ensuite ce qu’un User peut voir de ce qu’il peut faire.
Ce modèle n’est pas un modèle Customer e-commerce. Une extension peut relier Customer, adresse, shopper group, abonnement, membership ou Orders à un Joomla User ID, mais ces données restent la propriété de l’extension. Un Joomla User enregistré peut n’avoir jamais acheté, alors qu’un Order invité peut comporter des informations d’acheteur sans compte Joomla durable.
| Enregistrement d’identité | Signification dans Joomla | Écart fréquent avec la source |
|---|---|---|
| User | Identité de connexion et attributs de compte core | Interprété comme profil Customer complet alors que les données e-commerce résident ailleurs. |
| User Group | Regroupement pour les permissions ACL | Pris à tort pour un segment marketing, groupe de prix ou entreprise B2B. |
| Viewing Access Level | Définit quels groupes peuvent voir un élément | Réduit à public/privé et perd les règles de visibilité imbriquées. |
| Permissions administrateur | Actions qu’un User peut exécuter dans un composant | Confondue avec le statut de compte en vitrine. |
| Customer d’extension | Acheteur ou membre éventuellement relié à un Joomla User | Perdu lorsque seule la table User core est interprétée. |
| Acheteur invité | Données historiques stockées avec un Order | Transformé à tort en compte Joomla permanent. |
La cible doit préserver la distinction entre identité, autorisation, profil acheteur, adresse, organisation et propriété historique de la transaction. Les fusionner peut exposer du contenu restreint, supprimer des accès légitimes, dupliquer des Customers ou détacher des Orders de leur identité historique.
Champs personnalisés, tags, médias et métadonnées ajoutent du sens structuré
Les Custom Fields Joomla peuvent attacher des valeurs structurées à des Articles, Users ou Contacts. Leur rôle métier varie : labels éditoriaux, spécifications techniques, données d’annuaire, identifiants externes, attributs membre, clés d’intégration ou contenu structuré. Le libellé du champ ne suffit pas à choisir sa représentation cible.
Les tags fournissent une classification transversale. Les médias et chemins de fichiers peuvent alimenter images intégrées, galeries, téléchargements, documents ou actifs d’extensions. Les métadonnées peuvent appartenir aux Articles, Categories, Menu Items ou enregistrements d’extensions et influencer snippets de recherche, partage, indexation et routage.
| Zone | Question de relation | Interprétation en cible |
|---|---|---|
| Custom Field | Quel composant et type d’enregistrement possède la valeur ? | Champ natif cible, élément de contenu structuré, champ d’extension ou relation avec une donnée externe. |
| Tag | Sert-il navigation, filtrage, contenu associé ou annotation éditoriale ? | Préserver la relation métier réellement assurée par le tag. |
| Média | Quels enregistrements réutilisent l’actif et le chemin est-il intégré au contenu ? | Maintenir les relations d’attachement et de réutilisation plutôt que copier des fichiers sans références. |
| Métadonnée | Appartient-elle au contenu, à la route, à la Category ou au composant ? | L’attacher à l’objet cible qui contrôle le rendu public équivalent. |
| Identifiant externe | Quel système utilise cette valeur comme clé ? | Conserver la clé stable sur la bonne entité cible. |
Une mise en correspondance champ à champ ignorant la propriété du composant peut placer une valeur correcte sur le mauvais objet. La cible peut alors afficher la valeur tout en perdant filtrage, intégration, accès ou comportement d’édition.
Les données multilingues utilisent langues, associations, routes et support des extensions
Joomla distingue traduction d’interface et langue du contenu. Les enregistrements peuvent porter une langue et les associations multilingues relient leurs équivalents. Menus, pages par défaut, alias, Modules, Categories et enregistrements d’extensions peuvent aussi varier par langue.
Une plateforme source stockant les traductions comme colonnes d’un seul enregistrement peut nécessiter plusieurs enregistrements Joomla associés. Une autre source peut déjà utiliser des enregistrements distincts mais sans association Joomla. Les extensions peuvent gérer les traductions via le système core, leurs propres tables ou un outil tiers.
| Élément multilingue | Signification dans le modèle |
|---|---|
| Content language | Identifie la langue affectée à un contenu ou un enregistrement de composant. |
| Language association | Relie des enregistrements équivalents sans les fusionner. |
| Menu Item par langue | Fournit route et contexte de navigation dans une langue. |
| Module par langue | Fournit du contenu complémentaire sur certaines routes linguistiques. |
| Enregistrement de traduction d’extension | Contient les données e-commerce/applicatives traduites selon le design de l’extension. |
| Language override | Modifie le texte de l’interface plutôt que du contenu métier migré. |
La cible doit distinguer contenu métier traduit, chaînes d’interface et relations de route. Préserver du texte sans associations peut produire des pages qui semblent dupliquées mais ne sont pas reliées comme équivalents. Préserver les associations sans les menus et Modules correspondants peut laisser une branche linguistique incomplète.
Les extensions définissent les frontières du commerce et des autres applications
Joomla core ne définit pas nativement Products, panier, Customers, Orders, abonnements, événements, annuaires ou marketplace. Ces données appartiennent aux Components installés ou applications personnalisées. Deux sites Joomla peuvent donc présenter des vitrines proches tout en stockant le commerce dans des tables et relations totalement différentes.
L’extension propriétaire détermine types de Product, structures de Category, options ou variants, prix, stock, lien Customer, lignes Order, historique de statuts, références de paiement/livraison, champs personnalisés et identifiants d’intégration. Plugins et Modules peuvent ajouter encore d’autres enregistrements ou modifier l’interprétation.
| Concept e-commerce | Position de Joomla core | Propriétaire réel |
|---|---|---|
| Product et choix vendable | Aucun schéma Product universel | Composant e-commerce et ses extensions. |
| Customer et adresse | Le User core peut fournir l’identité uniquement | Composant e-commerce, membership ou application personnalisée. |
| Order et ligne Order | Aucun schéma Order universel | Composant e-commerce ou système externe de commande. |
| Groupe de prix ou règle B2B | Pas équivalent par défaut aux Joomla User Groups | Extension e-commerce, plugin tarifaire ou système externe. |
| Champ de commande | Pas un champ User core par défaut | Composant e-commerce, plugin de formulaire ou table personnalisée. |
| Référence de paiement/livraison | Contexte historique stocké par le propriétaire e-commerce | Composant e-commerce + plugin de gateway ou transporteur. |
« Données Joomla » n’est donc pas une définition de périmètre suffisante. L’inventaire doit nommer Components, plugins, Modules, tables personnalisées et systèmes externes propriétaires des données importantes.
Les implémentations personnalisées et identifiants externes exigent une carte de propriété
Les sites Joomla anciens contiennent souvent Components personnalisés, tables modifiées, overrides, plugins d’événements, tâches planifiées, intégrations API et relations directes en base. Certaines valeurs n’affectent que la présentation ; d’autres sont des clés métier de référence.
Une carte de propriété utile indique l’enregistrement, son propriétaire table/API, son entité parente, le système externe consommateur et l’objet cible qui doit porter la valeur. Cela est crucial pour IDs ERP/CRM, références documentaires, états de membership, identifiants vendeurs marketplace, clés de traitement et horodatages de synchronisation.
| Signal de propriété | Pourquoi il change la migration |
|---|---|
| Table personnalisée avec clés étrangères vers Users ou Articles core | L’enregistrement métier peut disparaître si seules les tables Joomla core sont interprétées. |
| Champ ou événement créé par un plugin | La valeur peut dépendre du fonctionnement du plugin et non d’un champ cible natif. |
| Identifiant réutilisé par un système externe | Régénérer les IDs peut casser rapprochement ou synchronisation. |
| Override lisant des colonnes non standards | La page visible peut dépendre de données absentes des écrans ordinaires. |
| Plusieurs extensions utilisant le même User | L’identité doit rester partagée tandis que chaque profil d’extension reste distinct. |
La cible n’a pas besoin de reproduire chaque détail d’implémentation Joomla. Elle doit toutefois représenter délibérément chaque relation portant du sens métier, d’accès, de contenu ou d’intégration.
Conclusion
Une migration Joomla est fondamentalement une traduction entre couches. Articles, Categories, Menu Items, Modules, templates, Users, niveaux d’accès, langues, Custom Fields, médias, extensions et systèmes externes possèdent chacun une partie différente du sens du site.
Un modèle cible cohérent préserve ces frontières avant de décider comment les enregistrements seront représentés. Il maintient le contenu relié aux routes, les identités aux permissions, les traductions à la structure linguistique, les données e-commerce à leur extension propriétaire et les identifiants externes aux systèmes qui en dépendent.
Questions fréquentes
Joomla fournit-il un modèle Product et Order natif ?
Non. Joomla core fournit contenu, identité, accès, routage et infrastructure d’extensions, mais Products et Orders appartiennent à un composant e-commerce ou une application personnalisée. Leur sens de migration doit être dérivé du schéma de ce propriétaire.
Les Joomla Categories sont-elles identiques aux Menu Items ?
Non. Les Categories regroupent les enregistrements dans un composant, tandis que les Menu Items créent navigation et relations de route. Une page publique de Category peut dépendre des deux objets, mais ils doivent rester séparés dans le modèle cible.
Tous les Joomla Users peuvent-ils être migrés comme Customers ?
Non. Un Joomla User est une identité de connexion et un sujet de permissions. Customers, adresses, memberships et Orders peuvent être des données appartenant à une extension et liées à cette identité, tandis qu’un acheteur invité peut ne disposer d’aucun compte Joomla.
Comment représenter Modules et overrides de templates ?
Classer les Modules selon leur contenu réutilisable et leurs relations d’affectation. Templates et overrides relèvent généralement de l’implémentation de présentation plutôt que de la migration de données métier, même si le contenu stocké dans des Modules personnalisés doit être pris en compte.
Pourquoi les données multilingues Joomla sont-elles sensibles aux relations ?
Affectations de langue, enregistrements associés, Menu Items par langue, Modules, alias et traductions d’extensions peuvent tous contribuer à une même expérience linguistique. Le texte traduit seul ne conserve pas ces relations.
Quand des données personnalisées Joomla nécessitent-elles une conception cible séparée ?
Lorsqu’une valeur importante réside dans des tables personnalisées, champs d’extension, enregistrements de plugins, overrides ou intégrations externes sans équivalent standard dans la cible. La conception doit préserver le sens métier et la propriété plutôt que copier aveuglément le stockage source.