Migrar desde WordPress

No hay un importador residente de WordPress en Chinaski: ningún parser de exportaciones WXR/XML, ningún script de migración de wp_posts. La migración es un ejercicio de preparar afuera, importar adentro, usando las superficies de importación que el producto realmente incluye. Esta página mapea qué funciona, qué no está soportado, y un orden de migración práctico.

Qué migra limpiamente hoy

Tres superficies verificadas aceptan contenido estructurado:

Opción A: Archivos Markdown (la vía de escape natural de WordPress)

El importador de Markdown (/admin/import-markdown, enlazado tanto desde Posts como desde Pages) acepta:

Un solo archivo .md o un lote de hasta 100 archivos (40 MiB en agregado).
YAML front matter por archivo: title, slug, language, meta_title, meta_description, category, tags, date.
Fallbacks tolerantes: un título faltante hace fallback al primer encabezado H1 del archivo, y luego a un nombre de archivo embellecido.
Las importaciones crean borradores por diseño explícito: nada se autopublica, la publicación programada nunca es alterada por una importación.
Aislamiento de errores por archivo: los archivos que fallan se nombran en el resultado sin que falle todo el lote.
Markdown se convierte del lado del servidor mediante el módulo opcional CommonMark; si tu host no lo tiene, la ruta reporta un error claro en el admin (instala el módulo o usa contenido HTML por las rutas JSON/CSV/API).

Exportar contenido de WordPress a archivos .md (título + front matter + cuerpo) es la ruta menos probada: muchos plugins de exportación de WP emiten Markdown directamente, o un script pequeño puede volcar las filas de wp_posts.

Opción B: JSON/CSV

Las rutas de exportación de las listas de pages/posts emiten el conjunto completo de columnas en el orden que espera el endpoint de importación (metadatos OG, URL canónica, fechas/horas de programación en la zona horaria del site, anidamiento, recurrente). Construye un conversor que mapee los campos de WordPress a esas columnas y al HTML de wp_content, aliméntalo como JSON/CSV, y las revisiones/importaciones llegan con la maquinaria de ida y vuelta haciendo la verificación de sintaxis por ti.

Opción C: La REST API (y bulk vía MCP)

Para migraciones grandes/en lote, la superficie /api/* es la más limpia:

POST/PUT para elementos individuales (pages, posts, blocks, snippets…).
POST /api/jobs aceptando bulk_upsert_pages, bulk_upsert_posts, bulk_create_blocks para lotes grandes (los upserts coinciden por slug+idioma).
Si ya estás conectado al servidor MCP, bulk_import y sus herramientas de traducción/auditoría viajan por la misma superficie.

Medios

No hay importador de medios de WordPress. wp-content/uploads se vuelve a subir a través de la biblioteca de medios (la carga en lote funciona) o por script por asset vía la API; luego se parchan las referencias dentro del cuerpo (buscar/reemplazar rutas del dominio de uploads antiguo → nuevas rutas de medios). Los reemplazos de medios en otros lugares mantienen el mismo nombre de archivo, así que cualquier referencia posterior a la importación puede apuntar al mismo lugar.

Qué NO migra

Themes de WordPress (jerarquías de templates PHP); Chinaski no tiene theming en PHP; rediseña en Template Toolkit, opcionalmente generado mediante el flujo de design briefs en los docs de la aplicación.
Plugins de WP: no hay arquitectura de hooks a la cual mapear; las funciones de los plugins se convierten en blocks, snippets o proceso editorial.
Revisiones, autoguardados, historial de aprobaciones: trata la migración como "aterrizar el contenido publicado", no como procedencia; las pistas de auditoría/revisión empiezan de cero.
Plugins de formularios: nada se mapea automáticamente; reconstruye los formularios en el editor de formularios de Chinaski y re-apunta los shortcodes.
Sistemas de comentarios: no hay equivalente; cúbrelo por separado si lo necesitas.

El orden de migración práctico

Exporta desde WordPress: saca wp_posts + categorías/tags (cualquier plugin de exportación de WP o SQL).
Convierte fuera de línea a archivos Markdown con front matter o a una lista JSON en el orden de columnas de importación; pon cada idioma en su propio directorio/campo.
Sube los medios por separado: re-súbelos a la biblioteca de medios (en lote) o scripta la ruta REST; luego parcha las referencias internas del contenido importado.
Ejecuta la importación: el importador de Markdown por lote de archivos o el bulk de la API para datos estructurados; los borradores llegan para revisión de contenido.
Verificación por muestreo: verifica slugs, fechas sensibles a la zona horaria, categorías (cada fila de contenido aterriza bajo el idioma configurado en el lote de importación) y referencias de imágenes.
Publica: aprueba o publica los borradores (el flujo de aprobación puede estar desactivado para admins; activado para editores).
Maneja las URLs antiguas: exporta el mapeo URL-wp→URL-nueva y añade redirecciones en la sección de redirecciones del admin (patrones soportados donde el reverse proxy los aplica). Los enlaces antiguos de motores de búsqueda siguen siendo válidos.

Qué configurarás manualmente, no migrado

Usuarios/cuentas de admin: nuevos logins por instancia (los usuarios de WordPress no se trasladan).
Theme: autoría en Template Toolkit con una selección de sistemas de diseño (el flujo de prompt de LLM Theme Prompting de los docs es la configuración más rápida para un diseño personalizado).
Stacks de formularios: cada formulario de contacto/feedback se reconstruye bajo los Forms de Chinaski.
Cualquier plugin de WP sin equivalente directo en Chinaski: búsqueda, SEO, caché, seguridad: usa los subsistemas correspondientes de la aplicación (el SEO es integrado; el caché es el modelo de build estático).
Programaciones: los puntos de activación cron/systemd de la nueva instancia (deploy/backup/DB) como su propia instalación operativa. Si tu WordPress ejecutaba estas tareas desde plugins, los servicios propios de esta instalación los reemplazan.