El migrador aprende a hablar con Payload

La pieza que faltaba: cómo hablará el migrador con Payload

El esbozo de ayer sabía leer WordPress, pero no sabía entrar en Payload. Hoy hemos puesto las tres piezas que faltan.

Primero, autenticación. La colección Users ya tenía un campo apiKey, pero Payload no lo mostraba en la UI. Con useAPIKey: true aparece la pestaña “API Keys” en el perfil de admin. Y para no tener que clicar nada, un script one-shot (generate-api-key.ts) genera la clave vía Local API y se borra después.

Segundo, la CLI. import.py con --wave=pilot|1|2|3: pilot = una sola comarca, después oleadas por post_type. Lo que más me interesa del pipeline:

• Idempotencia: antes de crear, busca por slug (find_by_wpslug). Si el contenido ya está, hace update en lugar de duplicar. Si la importación se corta a la mitad, la vuelvo a lanzar y no se duplica nada.
• Retries: 3 intentos con backoff 2s/4s/8s por petición.
• El prefijo de las tablas de WordPress se detecta solo (8WfsTsX_ en producción no es wp_).
• Contadores created/updated/skipped/failed y log a disco.

Tercero, los tests. test_import_smoke.py: 23 comprobaciones. Todas en verde.

Las credenciales no salen del servidor

Esta fase mueve credenciales: acceso a la MySQL de WordPress, claves de Payload, FTP. ANTES de generar código nuevo que las use, hemos cerrado la puerta: .gitignore ahora excluye explícitamente /test_ftp*.sh (tenía credenciales dentro), /BBDD_WP/, /WP-Media-Upload/ e /informes/, y hay un sitio reservado (scripts/migrate-wp/_local/) para los scripts de ayuda que solo viven en el servidor. Ningún secreto en el repo, ni por accidente.

El plan de importación

Las oleadas no son capricho: pilot de una comarca primero, revisión a fondo, y solo después las oleadas 1-3 por tipo de contenido. Si el pilot descubre un problema de mapeo, se corrige con 300 fichas en la base de datos, no con 6.000.

Mañana toca la ejecución del pilot.