Migrer depuis WordPress

Il n'y a pas d'importeur WordPress résident dans Chinaski : pas de parseur d'export WXR/XML, pas de script de migration wp_posts. La migration est un exercice de préparation dehors, import dedans, utilisant les surfaces d'import que le produit livre réellement. Cette page dresse la carte de ce qui fonctionne, de ce qui n'est pas pris en charge, et d'un ordre de migration pratique.

Ce qui migre proprement aujourd'hui

Trois surfaces d'atterrissage vérifiées acceptent du contenu structuré :

Option A : Fichiers Markdown (l'échappatoire naturelle depuis WordPress)

L'importeur Markdown (/admin/import-markdown, lié depuis Posts et Pages) accepte :

Un unique fichier .md ou un lot allant jusqu'à 100 fichiers (40 MiB au total).
Du front matter YAML par fichier : title, slug, language, meta_title, meta_description, category, tags, date.
Des replis gracieux : un titre manquant retombe sur le premier titre H1 du fichier, puis sur un nom de fichier embelli.
Les imports créent des brouillons par conception explicite : rien ne s'auto-publie, la publication programmée n'est jamais perturbée par un import.
Isolation des erreurs par fichier : les fichiers en échec sont nommés dans le résultat sans faire échouer le lot entier.
Le Markdown est converti côté serveur via le module optionnel CommonMark ; si votre hôte en est dépourvu, la route signale une erreur admin claire (installez le module ou passez du contenu HTML par les chemins JSON/CSV/API).

Exporter le contenu WordPress vers des fichiers .md (titre + front matter + corps) est le chemin le moins éprouvé : de nombreux plugins d'export WP émettent du Markdown directement, ou un petit script peut dérouler les lignes de wp_posts.

Option B : JSON/CSV

Les routes d'export de la liste des pages/posts émettent le jeu complet de colonnes dans l'ordre attendu par l'endpoint d'import (métadonnées OG, URL canonique, dates/heures de programmation dans le fuseau du site, imbrication, récurrent). Construisez un convertisseur qui mappe les champs WordPress vers ces colonnes et le HTML wp_content, alimentez-le en JSON/CSV, et les revues/imports se déroulent avec la mécanique aller-retour faisant la vérification syntaxique pour vous.

Option C : L'API REST (et le bulk MCP)

Pour les migrations volumineuses/en lot, la surface /api/* est la plus propre :

POST/PUT pour les éléments uniques (pages, posts, blocks, snippets…).
POST /api/jobs acceptant bulk_upsert_pages, bulk_upsert_posts, bulk_create_blocks pour les lots importants (les upserts appariant sur slug+langue).
Si vous êtes déjà raccordé au serveur MCP, bulk_import et ses outils de traduction/audit empruntent la même surface.

Médias

Il n'y a pas d'importeur de médias WordPress. wp-content/uploads est re-téléversé via la bibliothèque de médias (l'upload en masse fonctionne) ou scripté actif par actif via l'API ; puis les références dans les corps sont corrigées (rechercher/remplacer les anciens chemins de domaine d'upload → les nouveaux chemins de médias). Les remplacements de médias ailleurs conservent le même nom de fichier, de sorte qu'une référence post-import peut pointer au même endroit.

Ce qui NE migre PAS

Thèmes WordPress (hiérarchies de templates PHP) : Chinaski n'a pas de thémage PHP ; refaites la conception sur Template Toolkit, éventuellement générée via le flux design-brief dans la doc intégrée.
Plugins WP : aucune architecture de hooks à mapper dessus ; les fonctionnalités des plugins deviennent des blocks, des snippets ou du processus éditorial.
Révisions, sauvegardes automatiques, historique d'approbation : considérez la migration comme « atterrir le contenu vivant », pas comme une provenance ; les pistes d'audit/revue repartent de zéro.
Plugins de formulaires : rien ne se mappe automatiquement ; reconstruisez les formulaires dans l'éditeur de formulaires de Chinaski et redirigez les shortcodes.
Systèmes de commentaires : pas d'équivalent ; couvrez-les à part si besoin.

L'ordre de migration pratique

Exporter depuis WordPress : récupérez wp_posts + catégories/tags (n'importe quel plugin d'export WP ou du SQL).
Convertir hors ligne soit en fichiers Markdown avec front matter, soit en liste JSON dans l'ordre des colonnes d'import ; placez chaque langue sous son propre répertoire/champ.
Téléverser les médias séparément : re-téléversez dans la bibliothèque de médias (en masse) ou scriptez la route REST ; puis corrigez les références internes du contenu importé.
Lancer l'import : l'importeur Markdown par lot de fichiers ou le bulk API pour les données structurées ; des brouillons arrivent pour revue du contenu.
Contrôler au hasard : vérifiez slugs, dates sensibles au fuseau horaire, catégories (chaque ligne de contenu atterrit sous la langue configurée dans le lot d'import), et références d'images.
Publier : approuvez ou publiez les brouillons (le workflow d'approbation peut être désactivé pour les admins ; activé pour les éditeurs).
Traiter les anciennes URL : exportez le mapping URL-wp→nouvelle-URL et ajoutez des redirects dans la section redirects de l'admin (motifs pris en charge là où le reverse proxy les applique). Les anciens liens des moteurs de recherche restent valides.

Ce que vous configurerez manuellement, non migré

Comptes utilisateurs/admins : nouvelles connexions par instance (les utilisateurs WordPress ne passent pas).
Theme : authoring Template Toolkit avec un choix de systèmes de design (le flux de prompt LLM Theme Prompting de la doc est l'installation la plus rapide pour une conception personnalisée).
Stacks de formulaires : chaque formulaire contact/retour est reconstruit sous les Forms de Chinaski.
Tout plugin WP sans équivalent Chinaski direct : recherche, SEO, cache, plugins de sécurité : utilisez les sous-systèmes pertinents intégrés (le SEO est intégré ; le cache est le modèle de build statique).
Planifications : les points d'activation cron/systemd de la nouvelle instance (deploy/backup/DB) comme sa propre installation opérationnelle. Si votre WordPress exécutait ces tâches via des plugins, les services propres à cette installation les remplacent.