El codi i el contingut necessiten límits de reversió diferents. Restaurar la base d’ahir per desfer els fitxers d’avui pot eliminar entrades, usuaris, ajustos i enviaments recents. L’opció més segura substitueix només el codi implicat, tret que la migració de dades també exigeixi recuperació.
Congela els canvis innecessaris i documenta la finestra de l’incident abans de decidir.
Identifica què ha canviat l’actualització
Anota el component, versions, hora, PHP, WordPress i qualsevol missatge de migració.
Classifica:
només fitxers
fitxers i opcions o esquema
recursos generats o memòria cau
estat d'integracions externes
dades creades pels usuaris des de l'actualitzacióLlegeix el registre de canvis, instruccions de downgrade i registres. El número de versió no descriu tot l’estat.
Conserva les dades actuals
Fes una còpia nova dels fitxers i la base de l’estat trencat i mantén l’anterior. Exporta a part el contingut crític nou quan sigui pràctic.
Inventaria entrades, usuaris, formularis o comandes creades durant la incidència. El pla ha d’explicar com es conservaran.
No iniciïs una altra actualització o neteja mentre reculls proves.
Reverteix els fitxers de manera precisa
Per a un connector o tema, substitueix només el seu directori pel paquet anterior fiable després de provar-lo. No barregis fitxers.
Per al nucli, reinstal·la una versió compatible preservant wp-content, les pujades i wp-config.php.
component -> component.failed
trusted-previous -> componentConserva el propietari, buida OPcache i utilitza només fonts oficials.
Avalua la compatibilitat de la base
Si l’actualització ha modificat l’esquema o les opcions, el codi anterior pot no entendre la base nova. Consulta al fabricant si admet downgrade.
No redueixis manualment una versió desada per forçar migracions; pots repetir operacions destructives.
Si cal restaurar dades, planifica incorporar el contingut nou amb exportacions o API de l’aplicació, no copiant files directament.
Protegeix tasques i accions externes
Pausa cron, cues i integracions que puguin executar callbacks incompatibles. Comprova si el component nou ja ha enviat correu, canviat dades remotes o creat tasques.
Restaurar WordPress no desfà els efectes externs. Concilia’ls mitjançant referències estables.
Reprèn les cues només quan el codi pugui interpretar-ne els arguments.
Prova en una còpia semblant a producció
Restaura la base actual a staging, aplica el rollback proposat i prova la fallada, els desaments i cron.
Desactiva el correu, la indexació i les API reals. Confirma que cap migració automàtica de downgrade elimina dades.
Utilitza contingut recent representatiu per demostrar que sobreviu.
Planifica la unió si s’ha de restaurar la base
Defineix l’hora de restauració i inventaria cada entrada, usuari, comentari, formulari i registre posterior. Utilitza l’exportació o API de la seva aplicació per conservar relacions i sanejament.
No copiïs files per ID sense revisar col·lisions i metadades. Assaja i congela o posa en cua les escriptures durant la finestra final.
Conserva els mitjans nous
Els registres d’adjunts i els fitxers han de romandre emparellats. Inventaria els ID, rutes _wp_attached_file i originals.
Copia amb checksums i conserva les rutes; incorpora els registres amb eines de WordPress. No regeneris metadades abans que hi hagi els originals. Protegeix les pujades privades.
Aplica i verifica
Fes una última còpia, aplica la reversió mínima, buida les memòries cau i prova el web, administració, editor, mitjans, tasques i funcions del component.
Compara els recomptes i les dates més recents amb l’inventari. Busca errors de compatibilitat.
Vigila el trànsit abans de tancar.
Prepara la solució definitiva
Documenta la causa, el risc de la versió temporal i la reparació provada. Corregeix codi propi, actualitza dependències o tria un PHP compatible a staging.
El manteniment recurrent ha de separar els paquets de codi i les còpies de base i assajar la compatibilitat de downgrade. Un rollback professional recupera el servei sense considerar prescindibles les dades noves.