El migrador aprèn a parlar amb Payload

La peça que faltava: com parlarà el migrador amb Payload

L’esbós d’ahir sabia llegir WordPress, però no sabia entrar a Payload. Avui hem posat les tres peces que falten.

Primer, autenticació. La col·lecció Users ja tenia un camp apiKey, però Payload no el mostrava a la UI. Amb useAPIKey: true apareix la pestanya “API Keys” al perfil d’admin. I per no haver de clicar res, un script one-shot (generate-api-key.ts) genera la clau via Local API i es borra després.

Segon, la CLI. import.py amb --wave=pilot|1|2|3: pilot = una sola comarca, desprès onades per post_type. El que m’interessa del pipeline:

• Idempotència: abans de crear, cerca per slug (find_by_wpslug). Si el contingut ja hi és, fa update en lloc de duplicar. Si l’import es talla a la meitat, el torno a llançar i no es duplica res.
• Retries: 3 intents amb backoff 2s/4s/8s per petició.
• El prefix de les taules de WordPress es detecta sol (8WfsTsX_ en producció no és wp_).
• Comptadors created/updated/skipped/failed i log a disc.

Tercer, els tests. test_import_smoke.py: 23 comprovacions. Totes verdes.

Les credencials no surten del servidor

Aquesta fase mou credencials: accés a la MySQL de WordPress, claus de Payload, FTP. ABANS de generar codi nou que les faci servir, hem tancat la porta: .gitignore ara exclou explícitament /test_ftp*.sh (tenia credencials a dins), /BBDD_WP/, /WP-Media-Upload/ i /informes/, i hi ha un lloc reservat (scripts/migrate-wp/_local/) per als scripts d’ajuda que només viuen al servidor. Cap secret al repo, ni per accident.

El pla d’importació

L’onatge no és capçalera: pilot d’una comarca primer, revisió a fons, i només després les onades 1-3 per tipus de contingut. Si el pilot discovers un problema de mapatge, es corregeix amb 300 fitxes a la base de dades, no amb 6.000.

Demà toca l’execució del pilot.