WordPress stocke une grande partie de son contenu visible au moyen d’un petit nombre de structures natives réutilisables, mais ces structures peuvent servir des applications très différentes. Un enregistrement dans la table des posts peut représenter un Blog Post, une CMS Page, une pièce jointe multimédia, un élément de navigation, une révision ou un type de publication personnalisé. Une taxonomie peut classer du contenu éditorial, des fiches d’annuaire, des cours, des événements ou des Products. Une métadonnée peut être une simple valeur d’affichage ou le champ qui relie un enregistrement à un plugin, un modèle, une règle d’autorisation ou un système externe.
La décision importante pour la migration n’est donc pas de savoir si une valeur peut entrer dans WordPress. Il faut déterminer quel objet WordPress doit en être propriétaire et quelles relations rendent l’enregistrement exploitable. Une « page » source peut devenir une CMS Page, un type de publication personnalisé, une archive de taxonomie, un enregistrement de plugin ou plusieurs objets liés. Un « client » source peut devenir un utilisateur WordPress, un Customer appartenant à un plugin e-commerce, un profil d’adhésion, un contact CRM ou ne pas avoir de compte WordPress du tout.
Le cœur de WordPress fournit des types d’enregistrements réutilisables, pas un schéma métier universel
Le cœur de WordPress sépare contenu, classification, médias, identité, réglages, commentaires, routage et présentation. Les plugins peuvent enregistrer de nouveaux types d’enregistrements ou créer des tables séparées pour des applications spécialisées. Les thèmes et modèles de blocs déterminent le rendu, mais ils ne deviennent pas automatiquement propriétaires des enregistrements métier sous-jacents.
| Couche WordPress | Signification native | Conséquence pour la représentation |
|---|---|---|
| Table des posts | Stocke plusieurs types de publication, notamment Posts, Pages, pièces jointes, révisions, éléments de menu et types de publication personnalisés enregistrés. | Le type de publication et ses relations comptent davantage que la table partagée dans laquelle il est stocké. |
| Taxonomies et termes | Classent les enregistrements au moyen de vocabulaires hiérarchiques ou plats. | Une Category source ne peut pas être mise en correspondance de façon sûre sans savoir ce qu’elle classe et comment la cible l’utilise. |
| Métadonnées | Ajoutent des données clé-valeur aux posts, utilisateurs, termes et commentaires. | Le même mode de stockage peut porter des champs d’affichage, relations, autorisations, état de plugin ou identifiants externes. |
| Utilisateurs, rôles et capacités | Représentent l’identité et les autorisations. | Un utilisateur WordPress n’est pas automatiquement un Customer, membre, apprenant, donateur, vendeur ou profil d’équipe. |
| Options et réglages | Stockent une configuration au niveau du site ou d’un plugin. | Les enregistrements de configuration ne doivent pas être confondus avec des entités de contenu transportables. |
| Commentaires | Stockent des interactions rattachées à des posts ou à d’autres objets pris en charge. | Commentaires de blog, avis Product, témoignages, questions et discussions peuvent nécessiter des propriétaires cibles différents. |
| Plugins et tables personnalisées | Ajoutent des enregistrements et une logique propres à un domaine. | Commerce, adhésions, formulaires, événements, annuaires, apprentissage et réservations exigent une interprétation selon leur propriétaire. |
WordPress peut ainsi recevoir de nombreux types de données source, mais le modèle cible doit nommer le type de publication prévu, la taxonomie, le propriétaire des métadonnées, le plugin propriétaire et la route. Sans ces décisions, le contenu migré peut exister dans la base de données tout en restant absent de l’éditeur, des archives, des modèles, de la recherche, des autorisations ou du processus applicatif.
Blog Posts, CMS Pages et types de publication personnalisés n’ont pas le même rôle
Les Posts et Pages WordPress partagent un stockage natif, mais répondent à des fonctions éditoriales différentes. Les Blog Posts s’inscrivent généralement dans un flux de publication daté et peuvent participer à des catégories, étiquettes, auteurs, archives, flux et navigation chronologique. Les CMS Pages représentent généralement du contenu plus stable et peuvent former des hiérarchies parent-enfant. Les types de publication personnalisés modélisent des domaines structurés qui dépassent le contenu éditorial ordinaire.
Une plateforme source peut appeler « page » chaque enregistrement public alors que ces enregistrements représentent des événements, lieux, études de cas, ressources, membres d’équipe, cours, biens immobiliers ou annonces. Les transformer tous en CMS Pages supprime la frontière de type qui permet de gérer des champs spécialisés, des archives, des filtres, des modèles et une administration adaptée.
| Enregistrement source | Destination WordPress possible | Relation qui détermine le choix |
|---|---|---|
| Actualité ou entrée éditoriale | Blog Post | Date de publication, auteur, catégories, étiquettes, archives, flux et contenu associé. |
| Page à propos, contact, politique ou service | CMS Page | Hiérarchie stable, position dans le menu, modèle de page et route. |
| Événement | Type de publication personnalisé pour les événements ou enregistrement appartenant à un plugin événementiel. | Date, lieu, organisateur, récurrence, billetterie et relations de calendrier. |
| Bien immobilier ou fiche d’annuaire | Type de publication personnalisé pour les fiches ou enregistrement de plugin d’annuaire. | Localisation, attributs, filtres de taxonomie, propriétaire, statut et relations de recherche. |
| Cours ou leçon | Type de publication appartenant au LMS et tables associées. | Hiérarchie de cours, inscription, progression, quiz, certificats et règles d’accès. |
| Product | Modèle Product d’un plugin e-commerce. | Type de Product, variation, prix, stock, taxe, expédition, Customer et relations avec les Orders. |
| Section de design réutilisable | Motif de blocs, élément de modèle, enregistrement de constructeur ou blocs intégrés. | Réutilisation de présentation plutôt qu’identité éditoriale indépendante. |
Les types de publication personnalisés peuvent être stockés aux côtés d’autres types de publication, mais un stockage commun ne les rend pas interchangeables. Leurs capacités enregistrées, fonctions d’éditeur prises en charge, taxonomies, métadonnées, exposition REST, comportement d’archive et modèles déterminent la manière dont les éditeurs et applications les utilisent.
Taxonomies, termes, menus et archives sont liés sans être interchangeables
Les taxonomies WordPress classent des objets. Les catégories sont hiérarchiques par défaut, les étiquettes sont plates, et les plugins ou thèmes peuvent enregistrer des taxonomies personnalisées pour des domaines comme les sujets, marques, localisations, secteurs, types de ressources, niveaux de cours ou attributs Product. Les termes correspondent aux valeurs individuelles de ces taxonomies.
Les menus et la navigation sont distincts. Une entrée de menu peut pointer vers une CMS Page, un Blog Post, une archive de taxonomie, une archive de type de publication personnalisé, une URL externe ou une autre route. L’existence d’un terme de taxonomie ne garantit pas l’existence d’une entrée de menu correspondante, et la hiérarchie du menu ne reproduit pas nécessairement celle du contenu.
| Structure source | Propriétaire dans WordPress | Point de vigilance pour la représentation |
|---|---|---|
| Section éditoriale | Category ou taxonomie personnalisée | Préserver la relation avec les bons types de publication et le fonctionnement prévu des archives. |
| Libellé de mot-clé | Tag ou taxonomie personnalisée plate | Éviter de créer une hiérarchie profonde lorsqu’il s’agit seulement d’une annotation. |
| Marque, région ou type de ressource | Taxonomie personnalisée, taxonomie e-commerce ou classification de plugin | Garder les vocabulaires séparés lorsqu’ils contrôlent des filtres ou modèles différents. |
| Arborescence de navigation principale | Enregistrements de navigation/menu | L’ordre et l’imbrication du menu sont des relations de présentation, pas des appartenances à une taxonomie. |
| Page d’atterrissage pour une classification | Archive de taxonomie, CMS Page ou vue de plugin | Décider quel objet possède la route, le corps de contenu et l’ensemble filtré de résultats. |
| Category source utilisée uniquement en interne | Métadonnée ou classification externe | Ne pas exposer par défaut un code opérationnel comme archive WordPress publique. |
Les relations entre termes doivent également respecter leur périmètre. Un terme affecté à des Blog Posts peut porter le même libellé qu’un terme affecté à des Products, tout en appartenant à une autre taxonomie et en servant une autre application. Les fusionner uniquement parce que leurs noms correspondent peut mélanger des archives et filtres sans rapport.
Les métadonnées et champs personnalisés peuvent porter une valeur d’affichage, une relation ou un état applicatif
Les API de métadonnées WordPress prennent en charge des valeurs supplémentaires pour les posts, utilisateurs, termes et commentaires. Plugins et thèmes utilisent fréquemment les métadonnées pour des sous-titres, valeurs SEO, identifiants externes, choix de modèle, références de fichiers, localisations, dates, prix, réglages de visibilité, identifiants de relation ou états applicatifs sérialisés.
Le mode de stockage seul ne révèle pas le sens. Une clé meta peut contenir du texte simple, une référence vers un autre post, une liste d’identifiants de termes, l’identifiant d’une pièce jointe, un tableau structuré ou l’état d’un plugin. Un champ qui s’affiche correctement dans la source peut devenir inutilisable si la cible ne copie que la valeur littérale et perd la définition du champ ou l’objet référencé.
| Modèle de métadonnées | Signification possible | Exigence côté cible |
|---|---|---|
| Texte simple ou nombre | Sous-titre, spécification, date, score, code ou libellé éditorial. | Rattacher la valeur au bon objet et l’exposer dans l’interface d’édition prévue. |
| Identifiant de post ou de pièce jointe | Relation vers un autre enregistrement ou média. | Convertir la référence vers l’enregistrement cible plutôt que copier l’ancien identifiant numérique. |
| Identifiant de terme | Relation de classification. | Reconnecter la valeur à la taxonomie et au terme cibles. |
| Identifiant utilisateur | Auteur, propriétaire, formateur, vendeur, réviseur ou responsable. | Préserver le rôle métier, pas seulement le numéro d’utilisateur source. |
| Tableau sérialisé ou JSON | Champs répétés, mises en page, réglages, coordonnées ou état de plugin. | Interpréter le schéma du plugin propriétaire avant de décider si la structure reste transportable. |
| Identifiant externe | Clé CRM, ERP, PIM, DAM ou système historique. | Le conserver sur l’entité cible qui représente le même objet métier. |
Les définitions de champs peuvent compter autant que leurs valeurs. Les systèmes qui enregistrent des champs personnalisés peuvent définir le type de champ, les valeurs autorisées, les libellés d’affichage, les règles de saisie, les répétitions, les groupes, la logique conditionnelle et les relations. Copier les valeurs sans les définitions peut laisser aux administrateurs des données qu’aucun éditeur ni modèle ne sait exploiter.
Les blocs, constructeurs, modèles et données de thème appartiennent à la couche de présentation
Le contenu WordPress peut prendre la forme de HTML de l’éditeur classique, de balisage de blocs, de shortcodes, de structures propres à un constructeur, de blocs réutilisables, de motifs, de parties de modèles ou de réglages de thème. Ces couches peuvent référencer la même CMS Page ou le même type de publication personnalisé tout en décrivant la présentation de façons différentes.
Un constructeur de pages source peut stocker sa mise en page dans post_content, des métadonnées, des types de publication personnalisés, des options ou des tables personnalisées. Un site basé sur les blocs peut stocker les blocs de contenu dans l’enregistrement tandis que l’éditeur de site et le thème fournissent les modèles qui les entourent. Le modèle cible doit distinguer la propriété du contenu de la propriété de la présentation.
| Structure de présentation | Ce qu’elle possède | Ce qui reste séparé |
|---|---|---|
| Blocs natifs dans le contenu du post | Contenu structuré et attributs de blocs pour un enregistrement. | Modèles du site, navigation, données de plugins et enregistrements externes. |
| Shortcodes | Instructions intermédiaires interprétées par un plugin ou un thème. | Configuration réelle du plugin ou données interrogées par le shortcode. |
| Mise en page de constructeur | Sections, widgets, styles et références propres au constructeur. | Enregistrements métier affichés dans la mise en page. |
| Modèle ou partie de modèle | Structure de rendu du site. | Données de CMS Page, Blog Post, Product, Customer ou Order. |
| Option de thème | Réglage global de design ou d’affichage. | Contenu éditorial transportable et enregistrements applicatifs. |
| Bloc réutilisable ou motif | Contenu de présentation réutilisable. | Chaque instance ou entité métier affichée au moyen du motif. |
La cible n’a pas besoin de conserver le format de stockage interne d’un constructeur source si elle utilise un autre système de rendu. Elle doit en revanche préserver le contenu, les médias, les liens, les relations réutilisables et la propriété des enregistrements nécessaires à la nouvelle implémentation.
Les pièces jointes multimédias sont des enregistrements avec fichiers, métadonnées et relations
Dans WordPress, les médias ne sont pas seulement un répertoire de fichiers copiés. Les éléments multimédias peuvent être des enregistrements de pièces jointes avec titres, légendes, descriptions, textes alternatifs, types MIME, métadonnées de fichiers, tailles d’images, auteurs, dates et relations avec un parent. Les corps de contenu, métadonnées d’image mise en avant, galeries, blocs, champs de plugins et systèmes externes peuvent tous référencer ces pièces jointes.
| Situation du média source | Représentation WordPress | Conséquence sur les relations |
|---|---|---|
| Image mise en avant | Pièce jointe plus relation d’image mise en avant vers un enregistrement de contenu. | Le fichier et la référence doivent tous deux être convertis. |
| Image intégrée au contenu | Pièce jointe ou fichier externe plus URL dans le contenu. | Le contenu cible doit pointer vers le bon emplacement de fichier. |
| Galerie | Plusieurs pièces jointes plus structure de bloc, shortcode, constructeur ou plugin. | Le transfert des fichiers seul ne préserve pas l’ordre, les légendes ni le fonctionnement de la galerie. |
| Document téléchargeable | Pièce jointe média, URL de fichier ou téléchargement appartenant à un plugin. | Les règles d’accès, destinations de liens et chemins de remplacement restent partie intégrante du modèle. |
| Image de Product ou de fiche | Pièce jointe reliée via un plugin e-commerce ou d’annuaire. | La relation au plugin est distincte des médias d’une CMS Page ordinaire. |
| Ressource hébergée à l’extérieur | URL distante ou référence DAM. | La cible doit conserver le propriétaire externe plutôt que d’inventer une relation de pièce jointe locale. |
Les identifiants de parent des pièces jointes ne constituent pas toujours une carte complète de propriété. La même image peut apparaître dans plusieurs enregistrements, et les flux d’édition récents peuvent ne pas définir de parent significatif. La cible doit déduire les relations à partir des références réelles, champs d’image mise en avant, galeries, enregistrements de plugins et balisage de contenu plutôt que de s’appuyer uniquement sur la colonne parent.
Utilisateurs, rôles, capacités et profils représentent des significations de compte différentes
Les utilisateurs WordPress fournissent une identité de connexion, tandis que les rôles et capacités déterminent les actions autorisées. Les métadonnées utilisateur ajoutent des valeurs de profil et des états propres aux plugins. Des plugins peuvent ajouter des adhésions, cours, communautés, comptes e-commerce, profils vendeurs, annuaires du personnel, abonnements ou relations de contenu protégé.
| Identité source | Représentation WordPress possible | Distinction de propriété |
|---|---|---|
| Auteur ou éditeur | Utilisateur WordPress avec attribution d’auteur et capacités éditoriales. | La propriété des posts et l’historique de révision peuvent compter indépendamment de l’état de connexion. |
| Administrateur du site | Utilisateur disposant de capacités administratives. | L’autorité administrative n’équivaut pas au statut de Customer ou de membre. |
| Abonné à une newsletter | Contact marketing externe, enregistrement de plugin ou utilisateur WordPress limité. | Le consentement marketing et l’appartenance à une liste ne doivent pas être déduits d’un compte de connexion. |
| Membre | Utilisateur WordPress plus profil, plan, accès et statut appartenant au plugin d’adhésion. | L’enregistrement utilisateur seul ne reproduit pas le fonctionnement de l’adhésion. |
| Apprenant | Utilisateur WordPress plus inscription LMS, progression, quiz et certificats. | L’historique d’apprentissage appartient au domaine du LMS. |
| Customer | Customer d’un plugin e-commerce, utilisateur WordPress, identité invitée ou contact CRM externe. | La propriété e-commerce doit être explicitement nommée. |
| Vendeur ou vendeur de marketplace | Utilisateur plus enregistrements de vendeur et versements appartenant au plugin. | L’appartenance à un rôle ne représente pas le compte commercial complet. |
Les hachages de mots de passe source, fournisseurs d’authentification, réglages multifacteur et identités SSO peuvent ne pas être transportables comme de simples champs utilisateur. Le compte peut préserver son identité métier même si la relation d’authentification doit être représentée autrement.
Les commentaires, révisions et enregistrements historiques nécessitent leur propre contexte
Les commentaires peuvent représenter une discussion de blog, des avis Product, des témoignages, des questions, des messages de support ou des interactions liées à un plugin. Les révisions correspondent à des versions antérieures d’un contenu, pas à des enregistrements publics distincts. Les sauvegardes automatiques, états de corbeille, publications programmées et posts privés portent eux aussi un sens de cycle de vie.
| Enregistrement historique | Signification WordPress | Limite de représentation |
|---|---|---|
| Commentaire de blog | Interaction rattachée à un Blog Post ou une CMS Page. | Préserver l’auteur, la date, le statut, le commentaire parent et la relation avec le contenu propriétaire. |
| Avis Product | Enregistrement de type commentaire appartenant à un plugin e-commerce. | La note, le statut d’acheteur vérifié, la référence Product et le sens de modération diffèrent d’un commentaire ordinaire. |
| Discussion en fil | Hiérarchie de commentaires ou enregistrement de plugin communautaire. | Les réponses parent-enfant et le contexte d’adhésion peuvent être essentiels. |
| Révision de contenu | Version historique d’un post. | Ne pas présenter les révisions comme des CMS Pages ou Blog Posts publics dupliqués. |
| Enregistrement en brouillon, programmé, privé ou dans la corbeille | État de cycle de vie d’une entité de contenu. | Le statut de publication doit rester distinct de la visibilité dans les menus et des autorisations d’accès. |
Les enregistrements historiques peuvent être volontairement exclus lorsqu’ils n’ont plus de valeur métier, mais ils ne doivent pas être silencieusement confondus avec le contenu actuel. Le modèle cible doit préciser s’il représente l’enregistrement courant, son historique éditorial ou les deux.
Les plugins et tables personnalisées définissent une propriété applicative spécifique
Les plugins WordPress peuvent enregistrer des types de publication personnalisés, taxonomies, métadonnées, rôles, endpoints REST, réglages et événements planifiés. Ils peuvent aussi créer des tables de base de données dédiées lorsque le domaine exige des structures qui s’intègrent mal aux modèles natifs de posts et métadonnées. Formulaires, réservations, adhésions, systèmes d’apprentissage, événements, annuaires, dons, redirections, outils d’analyse, automatisations et commerce ajoutent fréquemment leurs propres enregistrements.
| Domaine appartenant à un plugin | Enregistrements possibles | Exigence de représentation |
|---|---|---|
| Formulaires | Définitions de formulaires, champs, soumissions, notifications et intégrations externes. | Séparer la structure de formulaire réutilisable des soumissions historiques et des processus d’envoi. |
| Adhésions | Plans, abonnements, règles d’accès, relations utilisateurs et contenu protégé. | Distinguer propriété de l’identité, droits, paiement et accès au contenu. |
| Systèmes d’apprentissage | Cours, leçons, inscriptions, progression, quiz, tentatives et certificats. | Préserver les relations requises par le modèle d’apprentissage cible. |
| Événements et réservations | Événements, sessions, ressources, participants, réservations, paiements et rappels. | Ne pas aplatir calendriers et relations de réservation en posts génériques. |
| Annuaires ou marketplaces | Fiches, propriétaires, localisations, attributs, réclamations, vendeurs et versements. | Identifier quels enregistrements sont du contenu et lesquels appartiennent au processus applicatif. |
| SEO et redirections | Métadonnées, valeurs canoniques, champs schema, redirections et aperçus sociaux. | Rattacher les valeurs à l’enregistrement qui possède la route et séparer les réglages globaux du site. |
| Tables personnalisées | Entités sur mesure, historiques, relations, journaux et clés d’intégration. | Représenter le schéma métier plutôt que copier des lignes de table sans l’application propriétaire. |
Les noms de fichiers de plugins et les listes de plugins actifs ne constituent pas le modèle de données. La véritable carte de propriété vient des types de publication enregistrés, taxonomies, clés de métadonnées, tables personnalisées, rôles utilisateurs, options, événements planifiés et références externes utilisés par le site.
Les URL, permaliens, archives et le périmètre Multisite font partie de l’identité des enregistrements
Les routes WordPress peuvent dépendre du type de publication, du slug, de la CMS Page parente, de la date de publication, de la Category, d’une taxonomie personnalisée, des réglages d’archive, règles de réécriture, domaine du site et endpoints de plugins. Une URL source ne peut donc pas toujours être reconstruite à partir du seul titre cible.
| Élément de route | Relation avec l’enregistrement | Conséquence côté cible |
|---|---|---|
| Chemin de CMS Page | Slug de la page plus hiérarchie parente. | Déplacer la page sous un autre parent peut modifier le chemin complet. |
| Permalien de Blog Post | Slug du post plus modèle de permalien configuré. | Les segments de date ou Category peuvent faire partie de l’URL historique. |
| Archive de taxonomie | Règle de réécriture de la taxonomie et slug du terme. | Un terme peut posséder une archive publique même sans entrée de menu. |
| Archive de type de publication personnalisé | Réécriture et réglages d’archive du type enregistré. | Les routes d’enregistrement et d’archive peuvent nécessiter des identités séparées. |
| Endpoint de plugin | Route applicative rattachée à un compte, Product, cours ou autre zone. | L’endpoint n’est pas une CMS Page ordinaire. |
| URL Multisite | Réseau, site, domaine et périmètre de chemin. | Les enregistrements peuvent appartenir à un site alors que les utilisateurs ou plugins entretiennent des relations à l’échelle du réseau. |
| Redirection | Relation entre ancienne route et nouvelle destination. | L’ancien chemin reste un enregistrement de continuité même lorsque le slug cible change. |
WordPress Multisite ajoute une autre couche de propriété. Posts, Pages, termes, options et de nombreux enregistrements de plugins sont propres à chaque site, tandis que les utilisateurs peuvent participer à plusieurs sites du réseau. Les plugins activés au niveau réseau et les services externes partagés peuvent ajouter du périmètre. Un export source qui omet l’identité du site peut fusionner des enregistrements volontairement séparés.
Le cœur de WordPress et les plugins e-commerce doivent rester des modèles distincts
Le cœur de WordPress ne fournit pas nativement les Products, paniers, processus de commande, Customers, Orders, coupons, paiements, expédition, taxes, inventaire ou traitement logistique. Ces entités appartiennent à WooCommerce ou à un autre plugin e-commerce. Elles peuvent s’appuyer sur des types de publication, taxonomies, utilisateurs, métadonnées, commentaires ou tables WordPress, mais leur sens métier vient de l’application e-commerce.
| Concept e-commerce | Relation avec le cœur de WordPress | Propriétaire réel |
|---|---|---|
| Product et variation | Peuvent utiliser des types de publication personnalisés, taxonomies, métadonnées ou tables dédiées. | Plugin e-commerce et ses extensions. |
| Customer | Peut être relié à un utilisateur WordPress ou rester une identité de transaction invitée. | Plugin e-commerce, CRM, système d’adhésion ou plateforme de compte externe. |
| Order et ligne d’Order | Peuvent utiliser des types de publication personnalisés ou des tables e-commerce dédiées. | Plugin e-commerce et extensions de paiement ou de traitement logistique. |
| Avis Product | Peut utiliser les commentaires plus des métadonnées de notation. | Modèle d’avis Product du plugin e-commerce. |
| Abonnement, réservation, bundle ou enregistrement vendeur | Peut référencer des Products, utilisateurs et Orders. | Extension spécialisée ou application marketplace. |
| Contexte de paiement, taxe, expédition et traitement logistique | Peut apparaître dans les enregistrements de transactions historiques. | Intégrations e-commerce et opérationnelles, pas contenu du cœur de WordPress. |
Une migration WordPress et une migration WooCommerce correspondent donc à des périmètres différents même si elles utilisent la même installation. La cible doit identifier le plugin e-commerce, sa version et son modèle de stockage, les extensions installées et les systèmes externes avant d’interpréter Products, Customers, Orders ou enregistrements applicatifs spécifiques.
Une carte de représentation WordPress doit préserver propriété et éditabilité
Le modèle cible est cohérent lorsque chaque enregistrement possède un type, un propriétaire, un système de classification, un contrat de métadonnées, une route et une surface d’édition nommés. L’objectif n’est pas de copier la conception de la base de données source. Il est de préserver les relations qui permettent aux éditeurs, administrateurs, applications et systèmes externes de comprendre les données.
| Question sur la source | Décision de représentation |
|---|---|
| L’enregistrement est-il du contenu éditorial ou une entité applicative ? | Choisir un type de publication natif, un type personnalisé, un enregistrement de plugin ou un propriétaire externe. |
| Un regroupement classe-t-il des enregistrements ou organise-t-il seulement la navigation ? | Séparer relations de taxonomie, menus et pages d’atterrissage. |
| Une valeur personnalisée contient-elle une donnée ou une référence vers un autre objet ? | Convertir à la fois la valeur et sa relation cible. |
| La mise en page est-elle stockée avec le contenu ou dans un système de constructeur/modèles ? | Préserver le sens du contenu séparément de l’implémentation de la présentation. |
| Un compte est-il seulement une identité de connexion ou appartient-il à un système d’adhésion, d’apprentissage, e-commerce ou vendeur ? | Garder l’utilisateur WordPress et le profil applicatif comme des enregistrements distincts mais reliés. |
| Une URL provient-elle d’un slug, d’une hiérarchie, d’une archive, d’un endpoint de plugin ou du périmètre Multisite ? | Préserver la relation qui possède la route plutôt que se fier aux titres. |
| L’entité appartient-elle au cœur de WordPress, à un plugin, à une table personnalisée ou à une plateforme externe ? | Garder le propriétaire réel explicite et conserver les identifiants intersystèmes stables. |
Ces décisions maintiennent le site migré exploitable. Les éditeurs retrouvent les bons enregistrements, les modèles rendent les objets prévus, les archives et filtres interrogent les bonnes classifications, les comptes conservent leur signification applicative et les intégrations continuent d’identifier les mêmes entités métier.
Conclusion
WordPress modifie le sens des données en utilisant des tables natives réutilisables pour de nombreux types d’enregistrements, tout en permettant aux plugins et au code personnalisé de définir des applications spécialisées. Posts, CMS Pages, types de publication personnalisés, taxonomies, métadonnées, pièces jointes, utilisateurs, commentaires, options, tables de plugins, routes et entités e-commerce peuvent partager l’infrastructure sans partager le même sens métier.
Une migration cohérente préserve cette propriété. Le contenu reste connecté au bon type de publication et à la bonne taxonomie, les métadonnées restent reliées à leur contrat de champ et aux enregistrements référencés, les médias restent connectés au contenu qui les utilise, les utilisateurs restent associés à leurs rôles et profils applicatifs, les routes restent rattachées aux objets qui les possèdent et les enregistrements de plugins ou e-commerce restent distincts du contenu WordPress natif ordinaire.
Questions fréquentes
Les types de publication personnalisés WordPress sont-ils identiques aux CMS Pages ?
Non. Les deux peuvent être stockés dans le système de posts WordPress, mais un type de publication personnalisé peut disposer de ses propres fonctions d’édition, taxonomies, capacités, métadonnées, archives, comportement REST et modèles. La cible doit préserver le type qui représente la fonction métier de l’enregistrement.
Chaque Category source peut-elle devenir une Category WordPress ?
Non. Le regroupement source peut correspondre à une Category standard, une étiquette, une taxonomie personnalisée, une taxonomie e-commerce, un menu de navigation, un champ de métadonnées, un filtre de plugin ou une classification externe. Le choix dépend de ce que le regroupement classe et de la manière dont la cible doit l’interroger ou l’afficher.
Pourquoi les champs personnalisés WordPress dépendent-ils autant des relations ?
Un champ personnalisé peut contenir une valeur littérale, l’identifiant d’un autre enregistrement, une référence de pièce jointe, un terme, un utilisateur, une structure sérialisée ou l’état d’un plugin. Copier la valeur visible sans convertir la relation ou la définition du champ peut rendre les données cibles inutilisables.
Les thèmes et constructeurs de pages sont-ils propriétaires des enregistrements métier sous-jacents ?
En général, non. Ils possèdent des structures de présentation, modèles, styles et références de mise en page. La CMS Page, le Blog Post, le Product, l’événement, la fiche ou autre entité reste la propriété du cœur de WordPress ou du plugin concerné, même lorsqu’un constructeur contrôle son affichage.
Les Products WooCommerce doivent-ils être traités comme des posts WordPress ordinaires ?
Non. WooCommerce peut utiliser l’infrastructure WordPress, mais les Products, variations, Customers, Orders, coupons, inventaire, paiements, expédition, taxes et extensions appartiennent au modèle e-commerce WooCommerce. Leurs relations exigent une interprétation propre au commerce.
Quand les données WordPress doivent-elles rester dans une table personnalisée ou un système externe plutôt que devenir un type de publication ?
Le propriétaire est déterminé par l’application qui gère l’enregistrement. Les transactions à fort volume, historiques spécialisés, relations plusieurs-à-plusieurs complexes, journaux d’intégration ou processus métier propres à un domaine peuvent résider dans des tables de plugins ou des plateformes externes. Le modèle de migration doit préserver l’entité et ses références sans la forcer dans un post générique simplement parce que WordPress constitue le cadre du site.