Diagnosticar una migració WordPress: SQL, uploads i URL

El teu WordPress s’obre a localhost, però una imatge conserva una adreça que un altre equip no pot visitar. Abans de moure’l, separa tres peces: la base de dades, els fitxers i les URL que descriuen on viu el contingut. Copiar SQL no copia els mitjans; pujar fitxers no reconstrueix per si sol les files del CMS.

Aquest diagnòstic fa servir un exemple original MIT amb dues instal·lacions sintètiques de WordPress core en un entorn d’un sol ús. Comprova SQL, un PNG generat, URL serialitzades i restauració. No és una recepta del panell Sites ni una migració feta per a un client.

Inventaria fitxers i dades

Anota la base de dades, wp-content/uploads, els temes, plugins i configuració abans de tocar la destinació. La documentació oficial de migració ajuda a separar fitxers i dades. L’exemple només assaja core i mitjans sintètics, no els teus temes, blocs, plugins o botiga.

Decideix primer si realment canvia l’URL

Moure una instal·lació no obliga sempre a substituir URL. Si l’URL pública continua exactament igual, no afegeixis un reemplaçament només perquè canvies de servidor. Si canvien esquema, nom de host, port o prefix de ruta, identifica les referències afectades i assaja el canvi sobre una còpia.

El recurs passa de http://source.invalid:8080 a http://destination.invalid:8081. Són adreces fictícies en un mateix Pod, no dominis públics. WP-CLI search-replace fa servir --dry-run abans d’aplicar i --skip-columns=guid: conserva els GUID. No adoptis una substitució SQL general ni reescriguis els GUID per arreglar imatges.

La documentació oficial de search-replace descriu el tractament de dades serialitzades. Canviar text sense respectar aquesta estructura pot invalidar dades. Aquí es verifica una opció imbricada amb URL i Unicode, a més de l’enllaç del contingut, després del reemplaçament.

Què comprova l’assaig acabat

L’evidència històrica conté onze comprovacions i prové de tretze assajos conservats; això no vol dir tretze èxits. L’execució final va passar amb WordPress 7.1.3, PHP 8.3.35 i WP-CLI 2.12.0, en imatges fixades per digest. El README i REHEARSAL-EVIDENCE.json distingeixen el codi executat de les actualitzacions documentals posteriors.

La destinació té base i usuari propis. S’exporten SQL i uploads, se’n verifiquen els hashes i es restauren junts. El dry-run conserva els valors originals; després d’aplicar, es comparen IDs, tipus, slugs, GUID i una projecció lògica definida, a més de l’opció serialitzada i el hash del PNG. Això no certifica totes les dades possibles de qualsevol WordPress.

Els negatius rebutgen SQL invàlid, mitjà absent, URL sense reemplaçar i fitxer corrupte. L’importador també detecta errors SQL encara que WP-CLI anunciï èxit; el missatge no substitueix comprovar les dades. Després de reparar el mitjà, HTTP comprova article, pàgina, PNG, 404, accés d’administrador i tancament de sessió. No es va assajar un render de Chrome ni una pantalla mòbil.

La tornada enrere restaura SQL i uploads originals a la destinació sintètica i elimina un fitxer extra de prova. També comprova que la font no canviï. No és un rollback de DNS, recuperació universal ni garantia de pèrdua zero.

Llegeix el harness abans d’executar-lo

Aquest recurs és avançat: l’assaig de WordPress necessita Kubernetes. Pots revisar el codi i executar les comprovacions de preparació des de la revisió fixada:

git clone https://github.com/ocentelles/hostbrid-example-wordpress-migration.git
cd hostbrid-example-wordpress-migration
git checkout 17d66e5808498adc62a4cf8061cf8c49d4648792
python3 test-preparation.py
/bin/sh -n rehearse.sh

Els quatre tests Python comproven el contracte de preparació i rebutgen canvis de xarxa, volum o token. La comprovació de shell només valida sintaxi. Cap no executa WordPress ni garanteix que una migració funcioni. prepare.py genera manifests, però no aplica recursos automàticament. Una execució requereix un namespace adequat i recursos nous propis, imatges compatibles i revisió de l’entorn.

L’assaig va fer servir només loopback i va configurar una NetworkPolicy de denegació, però no es va mesurar que el CNI l’apliqués efectivament. No reutilitzis aquest harness sobre una base real ni interpretis l’excepció TLS local com a instruccions per a una base remota.

Abans de valorar Sites

Confirma PHP, base de dades, accés als fitxers, capacitat disponible i abast concret de la migració abans de contractar o crear un lloc. Aquest diagnòstic no prova restauració del panell, TLS remot, DNS o HTTPS públics, correu, WooCommerce, multisite ni continuïtat d’escriptures. Conserva una còpia recuperable i verifica la teva instal·lació a part; canviar d’allotjament no converteix el resultat sintètic en un lliurament provat.