La validation d’une migration vers Joomla doit démontrer que les enregistrements migrés forment encore des pages, routes, permissions, relations linguistiques et processus appartenant aux extensions qui restent utilisables. Un Article peut exister alors que sa Category, son élément de menu, son niveau d’accès, son association de langue, son contexte de Module, son style de Template ou son alias produisent un résultat public incorrect. Un utilisateur peut être présent alors que les groupes qui lui sont attribués et les niveaux d’accès de consultation exposent trop ou trop peu de contenu.
Joomla sépare également les enregistrements du cœur du CMS de ceux des composants et extensions. Products, Customers, Orders, formulaires, annuaires, réservations, memberships et structures de page builder peuvent utiliser l’infrastructure Joomla tout en restant sous la responsabilité de leur composant. La validation doit suivre ces propriétaires au lieu de traiter chaque ligne comme un Article ou un utilisateur Joomla.
Définir les éléments de validation et les décisions de lancement Joomla
Utilisez un état de décision unique pour chaque domaine important :
- Pass : les échantillons représentatifs et les cas d’exception démontrent le résultat attendu pour le contenu, les routes, les accès, les langues, l’assemblage des pages ou les extensions Joomla.
- Watch : le résultat est utilisable, mais une correction non bloquante documentée, une tâche de configuration côté cible, un ajustement manuel de présentation ou une différence acceptée reste à traiter.
- Block : le problème affecte de façon importante l’accès public, le contenu restreint, la continuité multilingue, des routes importantes, des enregistrements d’extensions, l’historique e-commerce, la conformité ou le périmètre de migration convenu.
| Domaine de validation | Ce qu’il faut démontrer dans Joomla | Situation typique de Block |
|---|---|---|
| Contenu du cœur | Articles et Categories conservent leur contenu, état, hiérarchie, langue, accès, métadonnées et possibilité d’édition. | Un Article prioritaire manque, est mal affecté ou inaccessible au public prévu. |
| Menus et routes | Éléments de menu, alias, relations parent-enfant, pages d’accueil, vues de composants et redirections mènent vers les destinations approuvées. | Une route à forte valeur mène vers le mauvais élément, la mauvaise langue ou le mauvais contexte d’accès. |
| Identité et ACL | Utilisateurs, groupes, permissions, niveaux d’accès de consultation et enregistrements restreints respectent les règles prévues. | Des utilisateurs non autorisés peuvent voir ou modifier un contenu restreint, ou des utilisateurs requis perdent leur accès. |
| Multilingue | Langues, associations, structures de menus et contenus propres à chaque langue restent reliés. | Un parcours prioritaire dans une langue ne peut pas être mené à son terme. |
| Assemblage des pages | Modules, positions, styles de Templates, overrides et sortie des composants permettent d’utiliser les pages prioritaires. | Une page essentielle au lancement ne peut pas être comprise ou utilisée. |
| Périmètre des extensions | Les enregistrements appartenant aux composants et les résultats de migration non standard restent reliés à leur propriétaire. | Des données d’extension ou e-commerce essentielles sont absentes ou détachées de leur composant. |
Une décision Joomla doit identifier l’Article, la Category, l’élément de menu, la vue de composant, la langue, le niveau d’accès, le style de Template, la position de Module ou l’enregistrement d’extension contrôlé. Un Pass global du site ne doit pas masquer un échec limité à une langue ou à un public restreint.
Utiliser des tests représentatifs pour démontrer les relations Joomla
Les tests représentatifs doivent inclure des enregistrements qui révèlent le modèle de page Joomla :
- un Article avec Category, auteur, métadonnées, état, accès, langue et médias ;
- des Categories imbriquées utilisées par des mises en page de type liste ou blog ;
- un élément de menu pointant directement vers un Article et un élément de type Category Blog ou Category List ;
- une hiérarchie de menus avec alias, éléments parents, accès, langue et élément d’accueil par défaut ;
- un Article ou une vue de composant restreint associé à un niveau d’accès non public ;
- des utilisateurs représentatifs de plusieurs groupes ;
- des Articles, Categories, menus et associations multilingues lorsque ces fonctions sont utilisées ;
- une page assemblée à partir de la sortie d’un composant, de Modules, d’un style de Template et d’overrides ;
- un enregistrement de chaque extension ou composant e-commerce important inclus dans le périmètre ;
- les routes, redirections, médias et champs personnalisés prioritaires.
Un résultat de test représentatif devient Block lorsqu’il révèle une hypothèse structurelle qui serait répétée par une migration plus large. C’est notamment le cas lorsque des Articles sont affectés à la mauvaise Category, que des alias de menus produisent des routes dupliquées ou incorrectes, que des utilisateurs reçoivent le mauvais niveau d’accès, que des associations multilingues disparaissent ou que des enregistrements d’extensions se retrouvent détachés de leur composant propriétaire.
Les tests représentatifs démontrent le modèle de relations et la méthode de validation. Ils n’ont pas à représenter le volume complet, mais doivent couvrir suffisamment de cas pour que les responsables du contenu, des accès, des langues, de la présentation et des extensions puissent reproduire le contrôle.
Valider les Articles, Categories, tags, champs et contenus du cœur
Les Articles Joomla doivent conserver leur titre, alias, contenu, structure d’introduction et de texte complet lorsque celle-ci est pertinente, état, statut Featured, auteur, dates, Category, langue, niveau d’accès, tags, champs personnalisés, métadonnées, images et liens. Les Categories disposent de leur propre hiérarchie, accès, langue, métadonnées et mises en page publiques.
| Élément du cœur | Pass | Watch | Block |
|---|---|---|---|
| Article | Contenu, état, auteur, Category, langue, accès, métadonnées et médias sont cohérents. | Une correction mineure de mise en forme ou de métadonnées facultatives reste à faire. | Un Article prioritaire manque, est inaccessible ou se trouve dans le mauvais contexte. |
| Category | Hiérarchie, langue, accès, description, métadonnées et appartenance des Articles sont corrects. | Un nettoyage d’ordre à faible priorité reste à faire. | Une famille de contenu prioritaire ne peut pas être trouvée ou est exposée au mauvais public. |
| Tag | Les termes et affectations soutiennent la découverte transversale prévue. | Une normalisation non critique reste à faire. | Une classification ou un filtre requis ne peut pas être utilisé. |
| Champ personnalisé | Groupe de champs, type, valeur, contexte d’affichage et Template ou extension consommateur sont corrects. | Un ajustement d’affichage facultatif reste à faire. | Un champ opérationnel ou public requis est perdu. |
| Média | Images et fichiers se résolvent correctement depuis les Articles, Categories, champs et Modules. | Des légendes ou dimensions secondaires doivent être ajustées. | Un média prioritaire manque ou pointe vers le mauvais enregistrement. |
Les Categories et les menus Joomla ne représentent pas la même hiérarchie. Une Category peut être correcte alors que son élément de menu public manque ou est mal configuré. Inversement, un élément de menu peut charger une page tandis que la Category sous-jacente contient les mauvais Articles. Validez séparément la structure des données et celle des routes.
Incluez des exemples archivés, non publiés, Featured, planifiés et soumis à un accès restreint lorsque ces états existent. Les administrateurs doivent pouvoir filtrer et modifier les enregistrements dans les interfaces de gestion attendues, tandis que les visiteurs ne doivent voir que les contenus prévus pour leur langue et leur niveau d’accès. Cela évite qu’un simple échantillon de pages publiques masque des défauts administratifs ou de cycle de vie.
Valider les menus, alias, routes, redirections et contexte d’accueil
Les routes Joomla dépendent fortement des éléments de menu. Un élément de menu peut viser un Article, une Category Blog, une Category List, une vue de composant, une URL externe ou une autre route. Il peut également contrôler l’alias, la hiérarchie parent-enfant, la langue, l’accès, l’état de page d’accueil par défaut, le style de Template et des paramètres de mise en page.
| Élément de route | Ce qu’il faut démontrer |
|---|---|
| Élément direct vers un Article | L’Article prévu s’ouvre avec l’alias, la langue, l’accès et le contexte de Template approuvés. |
| Category Blog ou List | La bonne Category et le bon périmètre de sous-categories produisent les Articles et l’ordre attendus. |
| Vue de composant | L’élément de menu pointe vers le bon composant, la bonne vue et le bon contexte d’enregistrement. |
| Menu parent-enfant | Hiérarchie, ordre, libellés, accès et états actifs permettent une navigation correcte. |
| Élément d’accueil | Le bon élément par défaut existe pour chaque langue et contexte de site concernés. |
| Redirection | Les anciennes routes à forte valeur arrivent sur les routes Joomla approuvées, sans boucle ni mauvaise langue. |
| Lien interne | Les liens provenant des Articles, Modules, champs et extensions ne dépendent plus d’anciens alias ou identifiants source. |
Une route ne doit pas être marquée Pass simplement parce qu’elle retourne une page. Cette page doit afficher la sortie de composant attendue, le bon Article ou contexte de Category, la bonne langue, la règle d’accès, les métadonnées, les Modules et le style de Template prévus.
Testez les routes depuis plusieurs points d’entrée : URL directe, navigation par menu, lien interne dans un Article, lien de Module, sélecteur de langue et résultat de recherche lorsque cela s’applique. Joomla peut produire différents contextes Itemid et Modules pour le même enregistrement de composant ; les éléments de validation doivent donc confirmer que la route approuvée charge également l’assemblage de page et les métadonnées attendus.
Valider les utilisateurs, groupes, permissions et niveaux d’accès de consultation
Le système d’autorisation Joomla combine utilisateurs, groupes d’utilisateurs hiérarchiques, permissions d’action et niveaux d’accès de consultation. La validation doit distinguer ce qu’un utilisateur peut faire de ce qu’il peut voir.
| Élément ACL | Pass | Watch | Block |
|---|---|---|---|
| Identité utilisateur | État du compte, nom d’utilisateur ou e-mail, champs de profil et identifiant externe requis sont corrects. | Un nettoyage mineur du profil reste à faire. | Des utilisateurs requis ne peuvent pas accéder au site ou sont dupliqués incorrectement. |
| Appartenance aux groupes | Les utilisateurs représentatifs appartiennent aux groupes prévus et l’héritage de la hiérarchie est compris. | Un nettoyage de groupes non critique reste à faire. | Un utilisateur reçoit une autorité héritée incorrecte. |
| Permission du composant | Les utilisateurs peuvent créer, modifier, publier, supprimer, configurer ou administrer uniquement comme prévu. | Un ajustement documenté et non bloquant reste à faire. | Une administration non autorisée est possible ou un membre du personnel requis ne peut pas travailler. |
| Accès de consultation | Articles, éléments de menu, Categories, Modules et enregistrements de composants sont visibles uniquement par les groupes approuvés. | Un ajustement de visibilité à faible priorité reste à faire. | Un contenu restreint est exposé ou un contenu requis est masqué. |
| Profil d’extension | Les données e-commerce, membership, annuaire ou autres enregistrements de composant restent associés au bon utilisateur Joomla. | Des métadonnées historiques facultatives doivent être nettoyées. | L’identité applicative ou un droit d’accès est détaché. |
Utilisez des utilisateurs appartenant à plusieurs groupes ainsi que des utilisateurs dont les droits reposent sur l’héritage des groupes. Copier un libellé de rôle ne démontre pas que les permissions héritées sont équivalentes. Testez les actions ainsi que l’affichage depuis les contextes front-end et d’administration appropriés.
Pour chaque niveau d’accès important, vérifiez au moins un contenu qui doit être visible et un qui doit être masqué. Incluez les Articles, éléments de menu, Modules et vues de composants. Une page restreinte ne doit pas devenir accessible uniquement parce que l’Article ou l’utilisateur existe sur Joomla cible.
Valider le contenu multilingue et ses associations
La validation multilingue doit démontrer les relations, pas uniquement le nombre d’Articles par langue. Vérifiez les affectations de langue, les Articles et Categories associés, les menus propres à chaque langue, les éléments d’accueil par défaut, les Modules, les alias, les métadonnées et le sélecteur de langue.
| Élément multilingue | Ce qu’il faut démontrer |
|---|---|
| Affectation de langue | Chaque enregistrement prioritaire utilise la langue prévue ou le périmètre toutes langues approuvé. |
| Associations d’Articles et de Categories | Les enregistrements équivalents dans les différentes langues sont correctement reliés. |
| Structure des menus | Chaque langue présente l’arborescence de menus prévue et son élément d’accueil par défaut. |
| Affectation des Modules | Les Modules propres à une langue apparaissent uniquement dans le contexte prévu. |
| Alias et routes | Les chemins des différentes langues n’entrent pas en collision et les liens atteignent la bonne traduction. |
| Accès et métadonnées | Les règles d’accès, titres, descriptions et intentions canonical propres à chaque langue restent cohérents. |
Testez un parcours visiteur complet : page d’accueil, navigation par menu, page de contenu ou de composant, changement de langue puis retour. Une association manquante peut être Watch pour un contenu de faible valeur, mais devient Block lorsqu’elle interrompt un parcours client, légal ou e-commerce requis.
Les éléments de validation doivent inclure des enregistrements sans traduction ainsi que des enregistrements volontairement affectés à toutes les langues. Ces cas ne doivent pas être traités comme équivalents. Un Article de faible valeur non traduit peut être Watch ; l’absence d’une traduction légale, de compte ou e-commerce peut bloquer le lancement dans la langue concernée. Documentez le fallback ou l’exclusion prévus au lieu de supposer que la langue par défaut convient.
Valider les Modules, Templates, overrides et l’assemblage des pages
Une page Joomla peut combiner une vue de composant avec plusieurs Modules affectés selon la position, l’élément de menu, la langue, le niveau d’accès et l’état de publication. Les styles de Templates et les overrides de mise en page peuvent modifier le rendu d’un même contenu. La validation doit distinguer les éléments provenant des enregistrements migrés de ceux qui relèvent de l’implémentation de la boutique cible.
| Élément d’assemblage | Pass | Watch | Block |
|---|---|---|---|
| Sortie du composant | La vue principale d’Article, de Category ou d’extension affiche les enregistrements prévus. | Un ajustement mineur de mise en page reste à faire. | La page affiche le mauvais composant ou le mauvais contexte d’enregistrement. |
| Affectation de Module | Les Modules requis apparaissent à la bonne position, dans le bon menu, la bonne langue et le bon contexte d’accès. | Un ajustement non critique de position reste à faire. | Un Module requis pour la navigation, la connexion, les obligations légales ou l’e-commerce manque. |
| Style de Template | Le style prévu s’applique à l’élément de menu ou à la zone du site concernés. | Des finitions visuelles restent à faire. | La page devient inutilisable ou masque un contenu critique. |
| Override | Le rendu cible prend en charge les données et actions requises. | Un remplacement documenté est encore en attente. | Une vue critique perd des champs ou une interaction parce que l’ancien override ne s’applique plus. |
| Page builder | Le contenu inclus reste modifiable et produit un résultat public approuvé. | Des retouches manuelles restent nécessaires. | Une page prioritaire est vide, cassée ou enfermée dans des données d’extension inutilisables. |
La validation ne doit pas promettre une reconstruction complète des Templates si elle n’est pas incluse dans le périmètre. Elle doit démontrer que les pages prioritaires obtiennent un résultat approuvé et utilisable, et distinguer les défauts de migration des tâches d’implémentation sur la cible.
Utilisez des pages prioritaires avec différents éléments de menu, niveaux d’accès, langues et styles de Templates. Un Module peut être publié tout en échouant parce que son affectation de menu, sa position, sa langue ou sa règle d’accès est incorrecte. Lorsqu’un override n’est pas conservé, les éléments de validation doivent présenter le rendu cible approuvé et confirmer que les champs et actions requis restent disponibles.
Valider séparément les données appartenant aux extensions et les données e-commerce
Les extensions Joomla peuvent posséder des Products, Customers, Orders, subscriptions, réservations, formulaires, événements, annuaires, memberships, téléchargements, données de page builder et références vers des systèmes externes. Ces enregistrements peuvent utiliser des utilisateurs, Categories, tags, champs ou éléments de menu du cœur tout en conservant leurs propres tables et règles.
| Domaine d’extension | Éléments de validation requis | Signal pour la décision de lancement |
|---|---|---|
| Composant e-commerce | Structure des Products, Categories, options, prix, stock, Customers, Orders, routes et champs de l’extension | Block lorsqu’un Product prioritaire ou un Order historique ne peut pas être interprété. |
| Extension de membership ou d’accès | Relation utilisateur, plan, état, dates, contenu protégé et historique de paiement lorsqu’il est inclus | Block lorsqu’un droit d’accès actif est incorrect. |
| Composant de formulaire | Définition du formulaire, champs, soumissions lorsqu’elles sont incluses, routage et notifications | Block lorsqu’un formulaire requis ou son historique convenu est inutilisable. |
| Composant d’événement, réservation ou annuaire | Enregistrement principal, propriétaire, dates, lieux, participants et vue publique | Block lorsqu’une obligation active ou un parcours de découverte est incorrect. |
| Page builder | Enregistrements de pages, blocs, médias et contexte d’édition | Watch ou Block selon l’importance de la page et le résultat approuvé. |
| Table personnalisée ou intégration | Clé parente, identifiant externe, transformation et système consommateur sur la cible | Block lorsqu’un processus convenu ne peut pas lire le résultat. |
| Résultat de migration approuvé | Résultat acheté de mise en correspondance, filtrage ou configuration pris en charge | Comparer avec le besoin sélectionné et la destination Joomla attendue. |
| Résultat de migration non standard | Type de données, relation, transformation ou identifiant externe approuvé comme traitement personnalisé | Comparer avec les éléments d’acceptation convenus. |
Les enregistrements e-commerce ne doivent pas être validés comme de simples utilisateurs ou Articles Joomla. Le composant propriétaire de Products, Customers et Orders détermine les éléments à contrôler. Un utilisateur Joomla peut être lié à un Customer, mais l’utilisateur seul ne démontre ni l’historique e-commerce ni le fonctionnement du compte.
Le responsable de l’extension doit participer à la décision lorsque les enregistrements créent des obligations actives ou des accès restreints. Validez à la fois l’enregistrement administratif et le résultat visible publiquement ou par l’utilisateur. Un Product, une réservation, un membership ou une soumission de formulaire qui apparaît dans une table mais ne peut pas être trouvé, modifié ou rapproché depuis le composant cible ne doit pas obtenir Pass.
Valider l’exécution globale et les actions de migration ultérieures
L’exécution globale doit démontrer la couverture complète du contenu, des états, des langues, des accès, des menus, des extensions et des exceptions. Rapprochez les totaux par type de contenu, Category, langue, état, niveau d’accès, groupe utilisateur, menu et type d’enregistrement d’extension inclus. Examinez les exclusions volontaires, défauts source, alias dupliqués, médias orphelins, associations cassées et enregistrements nécessitant une implémentation séparée.
Les activités ultérieures nécessitent une revalidation adaptée à l’action :
| Action ultérieure | Éléments Joomla à revalider |
|---|---|
| Poursuite avec la configuration acceptée | Confirmer que les nouveaux Articles, utilisateurs, médias et enregistrements d’extensions conservent les mêmes Categories, langues, accès, routes et relations de champs. Recontrôler les collisions avec les modifications apportées à la boutique cible et les nouveaux alias. |
| Poursuite avec une configuration modifiée | Revalider chaque sélection de type de données, mise en correspondance de Category ou de champ, règle utilisateur, règle de langue, décision d’extension, règle de route et filtre modifiés. |
| Production d’un nouveau résultat de migration distinct | Traiter ce résultat indépendamment. Reprendre les éléments concernant le contenu, les ACL, le multilingue, l’assemblage des pages, les extensions et la décision de lancement. |
La validation à volume complet doit également comparer la répartition des enregistrements et pas seulement les totaux. Les nombres par langue, niveau d’accès, Category, état, groupe utilisateur et type d’extension peuvent révéler des erreurs de classification masquées par un total global. Le journal des exceptions doit préciser si une différence est volontaire, provient d’un défaut de la source, correspond à une décision de restructuration sur la cible ou reste un problème de migration non résolu.
Constituer le dossier de décision de lancement Joomla
Le journal final doit identifier :
- l’Article, la Category, l’élément de menu, le groupe utilisateur, le niveau d’accès, la langue, le Module, le style de Template, le composant ou la route testés ;
- les identifiants source et cible utilisés pour le rapprochement ;
- le résultat attendu et les éléments observés ;
- la décision Pass, Watch ou Block ;
- le responsable de la correction ou de la tâche d’implémentation cible ;
- si le problème affecte le lancement, une activité de migration ultérieure ou un nettoyage non bloquant ;
- les éléments requis pour clôturer le constat.
Un Pass exige des contenus prioritaires utilisables, des routes correctes, des accès maîtrisés, des parcours linguistiques cohérents, un assemblage de pages approuvé et une propriété explicite des enregistrements d’extensions. Un élément Watch possède un responsable identifié et ne compromet pas ces résultats. Un Block subsiste lorsque du contenu important est inaccessible, que des données restreintes sont exposées, qu’un parcours linguistique échoue, qu’une page critique ne peut pas être assemblée ou qu’un résultat d’extension convenu est inutilisable.
Conclusion
La validation Joomla doit démontrer les relations entre Articles, Categories, menus, alias, routes, utilisateurs, groupes, permissions, niveaux d’accès, langues, Modules, Templates et enregistrements d’extensions. La seule présence des enregistrements ne prouve pas que le site fonctionne à travers la page, le public, la langue ou le composant prévus.
Les tests représentatifs démontrent le modèle de relations. L’exécution globale démontre l’exhaustivité du périmètre et le traitement des exceptions. Les actions ultérieures nécessitent une revalidation ciblée ou complète selon l’action sélectionnée. L’approbation du lancement repose sur des éléments reproductibles et sur des décisions explicites Pass, Watch ou Block.
Questions fréquentes
Pourquoi faut-il valider séparément les Categories et les menus Joomla ?
Les Categories organisent le contenu, tandis que les éléments de menu définissent les routes publiques, les mises en page, la hiérarchie, l’accès, la langue et le contexte de Template. L’un peut être correct alors que l’autre conduit le visiteur vers un résultat incorrect.
Comment valider les contrôles d’accès Joomla ?
Utilisez des utilisateurs représentatifs de chaque groupe important et testez à la fois les actions autorisées et les droits de consultation. Les seuls noms de groupes ne démontrent pas les permissions héritées ni les niveaux d’accès associés aux Articles, menus, Modules et enregistrements de composants.
Qu’est-ce qui rend une validation multilingue Joomla complète ?
Validez les affectations de langue, les Articles et Categories associés, les menus et pages d’accueil propres à chaque langue, les Modules, les alias, les métadonnées et un parcours visiteur complet à travers le sélecteur de langue.
Les enregistrements d’extensions doivent-ils être contrôlés comme des Articles ou utilisateurs Joomla ?
Non. Validez-les au moyen du composant qui possède leurs champs, relations, routes et processus. Les Articles et utilisateurs du cœur peuvent intervenir dans ces relations, mais ils ne remplacent pas le type d’enregistrement de l’extension.
Comment les différences de Template ou de page builder doivent-elles influencer la décision de lancement ?
Déterminez si le problème relève du contenu migré, de l’implémentation cible ou d’un résultat personnalisé convenu. Utilisez Watch pour un travail nommé qui ne bloque pas le lancement et Block lorsqu’une page prioritaire est inutilisable ou ne peut pas être maintenue.
Que faut-il revalider après une activité de migration Joomla ultérieure ?
Recontrôlez les Articles, Categories, menus, alias, utilisateurs, accès, langues, médias, enregistrements d’extensions et redirections modifiés, ainsi que les collisions avec les changements effectués sur la boutique cible. Une nouvelle configuration ou une nouvelle migration exige des éléments plus larges qu’une poursuite sans modification.