Si WordPress est retenu comme plateforme cible, la préparation doit commencer par identifier ce qu’est réellement le site source. Une même installation WordPress peut être un site éditorial, un site de documentation, un site marketing, un environnement d’adhésion, un annuaire, une plateforme d’apprentissage, un système événementiel ou le CMS autour d’une boutique WooCommerce. Les Posts et CMS Pages natifs peuvent ne représenter qu’une partie du contenu réellement exploité. Les types de publication personnalisés, taxonomies, métadonnées, relations avec les médias, utilisateurs, tables de plugins, blocs, mises en page de constructeurs, redirections et identifiants externes peuvent déterminer si le site migré reste modifiable et compréhensible.
La préparation doit produire des éléments de preuve sur la source, pas des hypothèses. Chaque classe d’enregistrements importante doit avoir un propriétaire, un export ou un inventaire, un échantillon représentatif et une condition de préparation réussie. Le contenu natif WordPress doit rester séparé des données applicatives appartenant aux plugins, et la préparation du CMS WordPress doit rester distincte de celle des Products, Customers et Orders WooCommerce.
Confirmer le périmètre WordPress et les propriétaires des enregistrements
Commencez par définir quels enregistrements source appartiennent au cœur de WordPress, lesquels appartiennent à des plugins ou à du code personnalisé, lesquels restent dans des systèmes externes et lesquels sont volontairement exclus. Cette frontière évite de traiter chaque ligne de la base WordPress comme du contenu ordinaire.
WordPress stocke plusieurs types de publication dans l’infrastructure des posts, mais le type de publication continue de déterminer la finalité éditoriale, l’administration, les modèles, capacités, archives et le comportement API. Les taxonomies personnalisées ont également besoin de leurs définitions et relations avec les objets ; les métadonnées ont besoin du plugin, thème ou code qui interprète leurs clés et valeurs.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation réussie |
|---|---|---|---|
| Définir le rôle prévu du site WordPress cible | Propriétaire du site et responsable contenu | Déclaration de périmètre d’une page couvrant publication, marketing, adhésion, annuaire, apprentissage, commerce ou autres rôles applicatifs. | Chaque grande classe d’enregistrements source possède un propriétaire prévu dans WordPress, un plugin, un système externe, une archive ou une exclusion. |
| Séparer le périmètre CMS WordPress de WooCommerce ou d’autres applications | Propriétaire du site et responsable technique | Frontière d’entités listant CMS Posts, CMS Pages, médias, utilisateurs, menus et les Products, Orders, adhésions, réservations ou soumissions appartenant aux applications. | Aucun enregistrement applicatif n’est supposé être une CMS Page ou un Post standard simplement parce qu’il utilise des tables WordPress. |
| Documenter la topologie du site source | Responsable technique | Liste des domaines, sous-répertoires, sites par langue, réseau/sites Multisite, environnements de préproduction et URL publiques actives. | L’équipe peut identifier quel site ou réseau possède chaque enregistrement sélectionné. |
| Identifier les systèmes externes faisant autorité | Responsable intégrations | Carte des identifiants CRM, DAM, PIM, LMS, marketing, recherche, identité ou système documentaire. | Les clés externes et systèmes de référence qui continueront d’exister sont documentés avant la mise en correspondance des champs. |
Dans Multisite, l’identifiant du site ou du blog fait partie de la propriété de l’enregistrement. Les utilisateurs peuvent participer à plusieurs sites du réseau, tandis que Posts, CMS Pages, termes, options et de nombreux enregistrements de plugins restent propres à un site. Le dossier de préparation doit préserver ce périmètre au lieu de fusionner des enregistrements par titre ou identifiant numérique.
Sécuriser les accès à la source, les sauvegardes et les informations sur l’environnement
Une migration WordPress exige plus qu’un compte administrateur. Le contenu peut être réparti entre la base de données, le répertoire uploads, les répertoires de plugins, les fichiers de thème, les fichiers de langue, un stockage objet, des médias distants et des services externes. La préparation des accès doit rendre la source récupérable et permettre à l’équipe d’interpréter les structures personnalisées.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation réussie |
|---|---|---|---|
| Confirmer l’accès à l’administration WordPress | Administrateur du site | Compte administrateur fonctionnel et liste des zones d’administration restreintes. | Les Posts, Pages, utilisateurs, médias, plugins, thèmes, menus et réglages nécessaires peuvent être inventoriés. |
| Créer une sauvegarde complète de la source | Hébergeur ou responsable technique | Sauvegarde datée de la base plus fichiers wp-content, uploads, thèmes, plugins et références de configuration lorsqu’elles sont disponibles. |
L’emplacement de sauvegarde, la date, le responsable de restauration et la durée de conservation sont documentés. |
| Capturer les détails de l’environnement | Responsable technique | Version WordPress, version PHP, version de base de données, thème actif, thème enfant, plugins actifs, must-use plugins et services serveur pertinents. | L’environnement source peut être suffisamment reconstitué pour comprendre la propriété des contenus et plugins. |
| Documenter les processus planifiés et en arrière-plan | Responsable plugin ou intégration | Événements WP-Cron, planificateurs externes, files d’attente, endpoints webhook et traitements par lots qui créent ou mettent à jour des enregistrements. | Les mécanismes automatisés d’écriture sont connus et ne seront pas confondus avec du contenu migré statique. |
| Préserver les éléments d’export | Responsables contenu et technique | Exports WordPress utiles, inventaires de bases/tables, listes de fichiers multimédias et exports propres aux plugins. | Chaque zone de données sélectionnée dispose d’un artefact source récupérable ou d’un chemin de récupération documenté. |
L’outil d’export intégré de WordPress peut fournir des éléments de preuve utiles sur le contenu, mais il ne constitue pas une sauvegarde complète du site et ne représente pas automatiquement chaque table de plugin, option, fichier multimédia, dépendance de thème ou enregistrement externe. Le dossier de préparation doit donc distinguer les exports de contenu des éléments nécessaires à une restauration complète.
Inventorier Posts, CMS Pages, types de publication personnalisés et états de cycle de vie
Listez chaque type de publication qui contient des enregistrements, et pas uniquement ceux visibles dans le menu principal de l’administration. Incluez les Posts standard et CMS Pages, les pièces jointes, les révisions lorsqu’elles doivent être conservées et chaque type de publication personnalisé enregistré. Pour chaque type, documentez son objectif métier, le nombre d’enregistrements, son statut public ou privé, ses fonctions d’éditeur, relations parentes, auteurs, dates, comportement d’archive et le plugin ou code responsable.
| Zone d’enregistrements | Éléments à préparer | Décision à résoudre | Condition de préparation réussie |
|---|---|---|---|
| Blog Posts | Échantillons avec auteurs, dates, extraits, catégories, étiquettes, commentaires, images mises en avant et contenu intégré. | Quels historiques, brouillons, contenus programmés, privés et archives restent dans le périmètre ? | Les états de cycle de vie inclus et exclus sont explicites. |
| CMS Pages | Carte parent-enfant, modèles de page, utilisation dans les menus, formulaires, intégrations et routes à forte valeur. | Quelles hiérarchies et dépendances de modèles de page doivent continuer ? | Chaque Page importante possède un propriétaire cible et un parent prévu ou un statut de premier niveau. |
| Types de publication personnalisés | Source de l’enregistrement du type, liste de champs, taxonomies, capacités, réglages d’archive et enregistrements représentatifs. | La cible conserve-t-elle le type, le convertit-elle ou le maintient-elle dans une autre application ? | Chaque type actif possède une représentation cible et un responsable d’édition. |
| Révisions, sauvegardes automatiques et corbeille | Volumes et justification de conservation. | Les versions historiques ont-elles une valeur opérationnelle ou ne sont-elles qu’un historique de base de données ? | La conservation est intentionnelle et non héritée par défaut. |
| Contenu privé ou protégé | Responsable de l’accès, audience et mécanisme de protection actuel. | L’accès appartient-il aux rôles WordPress, à un plugin d’adhésion ou à un autre système ? | Les enregistrements protégés ont une identité et une dépendance d’autorisation documentées. |
Évitez d’utiliser uniquement les volumes d’enregistrements comme inventaire. Un type de publication personnalisé comportant vingt enregistrements peut être plus complexe à migrer que des milliers de Blog Posts ordinaires s’il dépend de plusieurs taxonomies, champs de relation, tables personnalisées et archives publiques.
Préparer taxonomies, termes, menus et relations d’archives
Les taxonomies WordPress classent des objets ; les menus organisent la navigation. Ils doivent être inventoriés séparément, même lorsqu’une Category ou un terme apparaît également dans un menu. Pour chaque taxonomie, notez si elle est hiérarchique ou plate, quels types de publication elle classe, si elle possède des archives publiques, quelles métadonnées appartiennent aux termes et si des libellés équivalents existent dans une autre taxonomie.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation réussie |
|---|---|---|---|
| Inventorier les taxonomies standard et personnalisées | Architecte de contenu ou responsable du plugin | Noms des taxonomies, types d’objets enregistrés, hiérarchie, nombre de termes, métadonnées des termes et réglages d’archive. | Chaque terme sélectionné reste relié à la bonne taxonomie et au bon type d’objet. |
| Nettoyer les termes dupliqués ou obsolètes | Responsable contenu | Liste des décisions de fusion, conservation, renommage et exclusion. | Des libellés similaires ne seront fusionnés que s’ils représentent réellement la même classification. |
| Exporter les structures de navigation | Responsable contenu | Arborescences des menus principal, pied de page, utilitaires, contextuels et propres aux langues, avec liens personnalisés. | La position dans les menus est documentée séparément de la hiérarchie du contenu et de l’appartenance à une taxonomie. |
| Documenter les destinations d’archives | Responsables SEO et contenu | Liste des URL d’archives Category, tag, taxonomie personnalisée, auteur, date et type de publication personnalisé. | Chaque archive importante a une destination prévue, un remplacement ou une décision de redirection. |
Les identifiants de termes et d’éléments de menu dépendent de l’installation. Lorsque des métadonnées ou enregistrements de constructeurs référencent ces identifiants, les éléments de préparation doivent nommer la taxonomie, le terme, le menu ou l’objet de contenu référencé, et pas seulement le numéro d’origine.
Cartographier les métadonnées, champs personnalisés, options et tables de plugins
Une métadonnée peut être une simple valeur éditoriale, une référence vers un objet, une configuration sérialisée, une donnée de mise en page, un identifiant externe ou un état applicatif. Construisez un inventaire des clés importantes pour post meta, user meta, term meta et comment meta. Regroupez les clés par propriétaire et finalité plutôt que d’essayer de conserver chaque clé technique.
Les plugins peuvent également créer des tables dédiées lorsque leur domaine ne s’adapte pas aux structures natives de WordPress. Formulaires, adhésions, systèmes d’apprentissage, événements, réservations, annuaires, redirections, outils d’analyse et intégrations utilisent souvent des tables personnalisées pour leurs définitions, transactions, historiques ou relations.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation réussie |
|---|---|---|---|
| Inventorier les clés de métadonnées critiques pour l’activité | Responsable du plugin et responsable contenu | Nom de clé, type d’objet, format de données, exemples de valeurs, fonction visible pour l’utilisateur et type d’objet référencé. | Chaque clé conservée possède un champ cible, un plugin propriétaire ou un propriétaire externe. |
| Identifier les champs qui référencent des objets | Responsable technique | Exemples d’identifiants de posts, pièces jointes, utilisateurs, termes et systèmes externes stockés dans les métadonnées. | Les références peuvent être converties vers les objets cibles plutôt que copiées comme identifiants numériques obsolètes. |
| Documenter les champs sérialisés ou structurés | Responsable du plugin ou constructeur | Exemples de schémas, champs répétés, groupes, charges utiles JSON/sérialisées et définitions de champs. | La cible peut interpréter la structure ou une décision de restructuration est documentée. |
| Inventorier les options du site et des plugins | Responsable technique | Options utiles à l’activité, plugin/thème propriétaire, périmètre de site et distinction entre contenu et configuration. | La configuration n’est pas silencieusement classée comme contenu à migrer. |
| Inventorier les tables personnalisées | Responsable du plugin et administrateur de base de données | Noms de tables, nombres de lignes, clés primaires, relations parentes, dates, statuts et clés externes. | Chaque table critique pour l’activité possède une destination explicite, un système externe conservé, une archive ou une décision d’exclusion. |
Les caches techniques, enregistrements temporaires, journaux, sessions, index générés et données de plugins abandonnés ne doivent pas être inclus simplement parce qu’ils existent. Leur exclusion doit être documentée afin qu’une comparaison ultérieure de base de données ne traite pas un nettoyage intentionnel comme du contenu manquant.
Préparer médias, blocs, constructeurs, thèmes et contenus intégrés
La préparation des médias doit préserver à la fois les fichiers et leurs références. Documentez les images mises en avant, images intégrées, galeries, documents téléchargeables, ressources hébergées à l’extérieur, légendes, textes alternatifs, métadonnées de pièces jointes et fichiers réutilisés. Identifiez les fichiers présents dans le répertoire uploads mais qui ne sont plus référencés, ainsi que les références dont les fichiers sont manquants.
La présentation du contenu peut être stockée sous forme de blocs natifs, HTML de l’éditeur classique, shortcodes, widgets, blocs réutilisables, motifs, parties de modèles, métadonnées de constructeurs de pages, options de thème ou modèles personnalisés. L’implémentation WordPress cible peut ne pas utiliser le même constructeur ou le même thème ; la préparation doit donc séparer le contenu réutilisable des données de mise en page propres à la source.
| Zone de préparation | Éléments à préparer | Responsable | Condition de préparation réussie |
|---|---|---|---|
| Médiathèque | Inventaire des fichiers, enregistrements de pièces jointes, textes alternatifs, légendes, liens d’images mises en avant, galeries et URL externes. | Responsables contenu et médias | Les fichiers prioritaires sont accessibles et chaque référence importante possède un fichier source ou un propriétaire distant connu. |
| Blocs natifs et contenu classique | Contenu représentatif avec liens, intégrations, tableaux, blocs réutilisables et formatage complexe. | Responsable éditorial | Les modèles de contenu nécessitant conversion ou reconstruction manuelle sont identifiés. |
| Shortcodes | Inventaire des shortcodes, plugin/thème propriétaire, pages exemples et rendu attendu. | Responsable du plugin | Chaque shortcode critique dispose d’un mécanisme de rendu continu ou d’une décision de remplacement. |
| Constructeurs de pages | Version du constructeur, modèles, sections globales, stockage des champs, dépendance au thème et exemples de mises en page. | Responsables design et technique | Le contenu réutilisable est séparé des données de présentation propres au constructeur. |
| Thèmes et parties de modèles | Thème actif/enfant, modèles personnalisés, zones de widgets, parties de modèles et styles globaux. | Responsable design | Le code du thème est traité comme élément d’implémentation et non comme contenu ordinaire. |
L’article WordPress n’exige pas que le design final soit déjà terminé. Il exige toutefois assez d’informations de propriété pour éviter de mélanger les données du constructeur, le code du thème, les shortcodes et le contenu réutilisable dans un même périmètre indifférencié.
Préparer utilisateurs, rôles, auteurs, commentaires et enregistrements sensibles
Les utilisateurs WordPress peuvent être auteurs, éditeurs, administrateurs, abonnés, membres, apprenants, vendeurs ou Customers d’une autre application. Les rôles et capacités natifs définissent les privilèges, tandis que les plugins peuvent ajouter rôles, capacités, profils, adhésions et historiques. Inventoriez séparément le rôle et la relation applicative.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation réussie |
|---|---|---|---|
| Classer les populations d’utilisateurs | Administrateur du site et responsable métier | Volumes et échantillons par rôle, type d’application, état actif, qualité d’auteur et finalité du compte. | Auteurs, équipes, membres, abonnés et utilisateurs applicatifs ne sont pas fusionnés uniquement sur la base de l’adresse e-mail. |
| Documenter les rôles et capacités personnalisés | Responsable technique | Définitions de rôles, capacités personnalisées, plugin/code propriétaire et utilisateurs représentatifs. | Les accès nécessaires possèdent un propriétaire côté cible ; les privilèges obsolètes sont exclus. |
| Relier auteurs et propriétaires | Responsable éditorial | Posts à forte valeur et enregistrements personnalisés avec références vers l’auteur ou le propriétaire. | Les enregistrements inclus disposent d’auteurs cibles résolvables ou d’un propriétaire de remplacement approuvé. |
| Inventorier commentaires et avis | Responsable contenu ou communauté | Statut, hiérarchie, identité de l’auteur, contenu associé, règles de spam/exclusion et propriété du plugin. | Commentaires de blog, discussions, témoignages et avis e-commerce restent correctement classés. |
| Identifier les champs sensibles en matière de confidentialité | Responsables confidentialité et métier | Inventaire des champs, base de consentement, règle de conservation et besoin d’accès. | Les données sensibles disposent d’une décision approuvée de migration, archivage, masquage ou exclusion. |
Les hachages de mots de passe source et identités d’authentification externes doivent être documentés séparément des profils utilisateurs standard. Un enregistrement utilisateur peut rester dans le périmètre même lorsque l’identifiant d’authentification d’origine n’est pas transportable.
Préparer URL, métadonnées SEO, redirections, langues et périmètre Multisite
Créez un inventaire des URL source pour les CMS Pages, Blog Posts, types de publication personnalisés, archives de taxonomies, archives d’auteurs, médias, flux et routes de plugins à forte valeur. Documentez la structure des permaliens, hiérarchie parente, règles de réécriture des taxonomies, périmètre domaine/sous-répertoire, URL canoniques et redirections existantes.
Les champs SEO peuvent être stockés dans des enregistrements natifs, des métadonnées, des tables de plugins ou des plateformes externes. Inventoriez les titres, descriptions, valeurs canoniques, champs sociaux, entrées de données structurées, contrôles d’indexation et enregistrements de redirection par propriétaire. Ne supposez pas qu’un export de plugin contient chaque relation de route.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation réussie |
|---|---|---|---|
| Capturer les URL source prioritaires | Responsable SEO | Liste d’URL basée sur les données d’analyse/recherche, avec statut actuel et intention cible. | Chaque route prioritaire dispose d’une décision : conserver, modifier, consolider, retirer ou rediriger. |
| Documenter la logique de permaliens et de réécriture | Responsable technique | Réglages de permaliens, règles de réécriture des types de publication et taxonomies personnalisés, endpoints de plugins et règles de chemin/domaine Multisite. | La conception des routes cibles distingue les enregistrements de contenu des archives et endpoints applicatifs. |
| Inventorier les propriétaires des données SEO | Responsables SEO et plugins | Carte des clés/tables de métadonnées, fichiers d’export, règles canoniques, règles d’indexation et sources de sitemap. | Chaque valeur SEO conservée a un propriétaire côté cible. |
| Préparer les relations multilingues | Responsable localisation | Langues, groupes de traduction, codes de locale, routes propres aux langues et règles de repli. | Les traductions restent reliées entre elles au lieu de devenir du contenu dupliqué sans relation. |
| Documenter les redirections existantes | Responsable SEO ou technique | Source, destination, statut, propriétaire et priorité. | Les redirections dupliquées, en chaîne, obsolètes et encore nécessaires sont classées. |
Pour Multisite, incluez la relation réseau/site dans les éléments de preuve sur les URL. Des slugs identiques sur des sites différents correspondent à des routes distinctes et ne doivent pas être fusionnés sans décision explicite sur le contenu.
Sélectionner des échantillons représentatifs pour le test de migration
La sélection des échantillons doit représenter la diversité structurelle du site plutôt que seulement les enregistrements récents ou simples. Chaque échantillon doit préciser les relations de contenu attendues, fichiers liés, éléments de route et responsable de la validation.
| Échantillon | Éléments à préparer | Pourquoi l’inclure |
|---|---|---|
| CMS Page hiérarchique | Route parent/enfant, modèle, blocs ou données de constructeur, médias, utilisation dans les menus et champs SEO. | Représente la hiérarchie des Pages, les dépendances de présentation et le routage. |
| Blog Post avec relations | Auteur, catégories, étiquettes, commentaires, image mise en avant, intégrations et routes d’archives. | Représente l’historique éditorial et la classification. |
| Un enregistrement de chaque type de publication personnalisé important | Taxonomies, métadonnées, médias, route publique, plugin propriétaire et enregistrements liés. | Met en évidence les dépendances de configuration du plugin et de schéma personnalisé. |
| Enregistrement riche en métadonnées | Définitions de champs, identifiants de référence, champs répétés, valeurs sérialisées et identifiants externes. | Montre si les valeurs de champs peuvent rester interprétables. |
| Utilisateur avec contexte applicatif | Rôle, capacités, enregistrements créés, données de profil et relation d’adhésion ou autre plugin. | Représente l’identité sans confondre les utilisateurs natifs avec les profils de plugins. |
| Enregistrement complexe média/contenu | Galerie, fichier téléchargeable, pièce jointe réutilisée, shortcode/intégration et liens internes. | Représente les dépendances entre fichiers et références de contenu. |
| Enregistrement multilingue ou Multisite lorsqu’il y en a | Propriété du site/de la langue, liens de traduction, routes et utilisateurs partagés. | Met en évidence les relations de périmètre de site et de localisation. |
Le registre d’échantillons doit inclure l’identifiant source, l’URL publique lorsqu’elle existe, le propriétaire de l’enregistrement, les objets liés, la raison de sélection et toute dépendance non résolue. Les enregistrements simples peuvent confirmer le fonctionnement de base, mais les enregistrements complexes révèlent si les éléments de périmètre sont réellement complets.
Finaliser le contrôle de préparation WordPress
Avant l’exécution, consolidez les éléments de préparation dans un registre unique. Un point non résolu ne peut rester ouvert que s’il possède un responsable, une date de décision et un effet clairement défini sur le périmètre.
| Domaine de préparation | Condition de préparation réussie |
|---|---|
| Périmètre et propriété | Chaque type d’enregistrement sélectionné appartient au cœur de WordPress, à un plugin/application personnalisée nommé, à un système externe, à une archive ou à une exclusion intentionnelle. |
| Accès et récupération | Accès administrateur, sauvegarde de base de données, sauvegarde des fichiers, inventaire de l’environnement et responsabilité de restauration sont documentés. |
| Architecture de contenu | Posts, CMS Pages, types de publication personnalisés, taxonomies, menus et états de cycle de vie disposent de décisions explicites d’inclusion et de destination. |
| Données personnalisées | Les métadonnées importantes, options, tables personnalisées, références d’objets et identifiants externes ont des schémas et propriétaires connus. |
| Médias et présentation | Les fichiers prioritaires sont disponibles ; les dépendances de constructeur, bloc, shortcode, thème et modèle sont classées. |
| Utilisateurs et confidentialité | Rôles, qualité d’auteur, profils applicatifs, commentaires, dépendances d’authentification et champs sensibles sont classés. |
| URL et SEO | Les routes prioritaires, logique de permaliens, redirections, périmètre langue/site et propriétaires des données SEO sont documentés. |
| Échantillons | Le registre d’échantillons représente chaque modèle important de contenu et d’application WordPress compris dans le périmètre. |
Le périmètre WordPress est prêt lorsque l’équipe de migration peut identifier ce qu’est chaque enregistrement sélectionné, où résident ses données liées, qui possède sa représentation cible et quels éléments source étayent cette décision.
Conclusion
La préparation d’une migration vers WordPress est un exercice de propriété couvrant contenu, classification, métadonnées, médias, identité, présentation, plugins, tables personnalisées, routes et systèmes externes. Une sauvegarde complète et un accès administrateur sont nécessaires, mais ils n’expliquent pas les types de publication personnalisés, relations de taxonomies, structures de constructeurs, profils applicatifs, périmètre Multisite ou enregistrements appartenant aux plugins.
Un dossier de préparation solide rend ces relations explicites. Il sépare les données CMS WordPress de WooCommerce ou d’autres domaines applicatifs, conserve des éléments récupérables sur la source, sélectionne des échantillons représentatifs et résout chaque enregistrement important vers une destination, un propriétaire externe conservé, une archive ou une exclusion intentionnelle avant le début de l’exécution de la migration.
Questions fréquentes
Que faut-il préparer en premier pour une migration vers WordPress ?
Définissez le rôle du site WordPress cible et classez les propriétaires des enregistrements source. Cela établit si chaque enregistrement appartient au cœur de WordPress, à un plugin ou une application personnalisée, à un système externe, à une archive ou à une exclusion intentionnelle avant de commencer le travail détaillé sur les champs.
Le fichier d’export WordPress constitue-t-il une sauvegarde complète de migration ?
Non. L’export intégré peut fournir des éléments utiles sur le contenu, mais une source récupérable exige généralement aussi la base de données, les médias et autres fichiers wp-content, les détails de l’environnement ainsi que les enregistrements propres aux plugins ou systèmes externes que l’export ne représente pas.
Pourquoi les types de publication personnalisés et taxonomies doivent-ils être inventoriés séparément ?
Ils peuvent partager le stockage WordPress tout en utilisant des configurations, capacités, éditeurs, métadonnées, archives, modèles et propriétaires de plugins différents. Préserver uniquement les titres et corps de contenu ne préserverait pas la structure qui rend ces enregistrements gérables.
Comment préparer les champs personnalisés et métadonnées ?
Documentez le propriétaire de la métadonnée, le type d’objet, le format de valeur, la définition du champ, les objets référencés, des échantillons représentatifs et la destination prévue. Les identifiants numériques et valeurs sérialisées ne doivent pas être copiés sans convertir les enregistrements ou schémas auxquels ils font référence.
Les plugins et thèmes doivent-ils être traités comme du contenu à migrer ?
Pas automatiquement. Les plugins et thèmes sont des dépendances d’implémentation. Leurs enregistrements critiques, réglages, tables personnalisées, shortcodes, modèles et liens externes nécessitent des décisions de propriété explicites, tandis que les données techniques temporaires ou obsolètes peuvent être exclues.
En quoi la préparation WordPress diffère-t-elle de la préparation WooCommerce ?
La préparation WordPress couvre CMS Posts, CMS Pages, types de publication personnalisés, taxonomies, métadonnées, médias, utilisateurs, menus, routes et frontières applicatives des plugins. La préparation WooCommerce couvre séparément Products, variations, Customers, Orders, coupons, avis e-commerce, HPOS, métadonnées du processus de commande et extensions e-commerce.