El migrador ya habla con el WordPress de producción

Llevo tres semanas con el migrador (el script que pasa el contenido del WordPress viejo al nuevo gestor) trabajando sobre datos de prueba. Hoy lo he puesto delante del WordPress real: la base de datos de producción, con sus prefijos rarísimos y las taxonomías de Toolset (unas herramientas de WordPress para clasificar contenido). La fase 3 ya no es un borrador: el piloto importa.

Dos puertas para entrar en Payload

El primer problema ni siquiera era de migración: era de autenticación (demostrarle al sistema quién eres). El plugin de API keys de Payload —claves que identifican un programa frente a otro— pide configuración manual desde la interfaz, y yo quería un camino que funcionara siempre. Solución: modo doble. Si hay PAYLOAD_API_KEY, se usa API key; si no, login con email y contraseña (JWT, un token de acceso), que funciona out-of-the-box. Y si no hay nada de nada, el script se para con un RuntimeError que lo explica.

Encontrar las tablas buenas

Para detectar el prefijo de las tablas WordPress hacía un LIKE '%\\_posts'. PyMySQL (la librería que hace las consultas SQL desde Python) se lo come como un especificador de formato, y el primer candidato que salía era una tabla de Mailpoet, no del core. Dos correcciones: escapar el porcentaje (%%) y cruzar con las tablas *_options, que son las que delatan el core de WordPress. Si hay varias candidatas, gana el prefijo más corto.

Comarcas, municipios y detalles que no perdonan

En el primer pilot nada enlazaba: las comarcas no se resolvían a IDs, el seed decía berguedà con acento y el WordPress lo tiene sin él, y Payload quería enteros donde le pasaba strings. Ahora los catálogos de comarcas y municipios se crean solos (idempotentes: repetirlos no duplica nada) y las relaciones van con el tipo correcto. Para Bagà han salido 13 posts: 1 de cultura y 12 eventos del calendario.

De HTML de Gutenberg a Lexical

El contenido del WP llegaba con comentarios <!-- wp:paragraph --> que Payload escapaba y mostraba literalmente en la página. He reescrito el conversor con html.parser: limpia los comentarios de Gutenberg, mapea párrafos, encabezados y listas, y conserva negritas y cursivas dentro del texto. Los enlaces, además, pedían campos extra en el nodo (id, direction, format): sin ellos, el admin petaba con un React error #418 y escondía todos los campos richText. Con el parser nuevo, las dos piezas del último piloto se ven limpias en el frontend.

De paso: dependencias al día

He aprovechado para poner Payload 3.89, Next 15.4.11 y React 19.0.1: el peer dep de Payload (las versiones que exige de sus vecinas) lo exigía. El error #418 ha sobrevivido a la actualización, que era otra pista de que era estructural y no de versión.

Balance del día: 29 smoke tests en verde (pruebas rápidas de lo básico), dos pilotos importados con portada y meta descripción, y la sensación de que la fase 3 por fin camina sola. La continuación, en El sábado más denso: editor, ingesta y un DNS que se apagó; la publicidad también acabaría cruzando el puente en La publicidad se importa: Advanced Ads hacia Payload.