Las actualizaciones sustituyen archivos del tema padre. Las ediciones directas desaparecen por diseño; el CSS del Personalizador, los temas hijos y los plugins propios suelen sobrevivir. Primero averigua dónde vivía el cambio y recupera únicamente código intencionado.
No sobrescribas el tema nuevo con una copia antigua completa sin revisar seguridad y plantillas.
Define qué ha desaparecido
Anota URLs, anchura de pantalla, diseño esperado y si el cambio era CSS, plantilla PHP, JavaScript o ajuste del tema.
Revisa fuente y Red para saber si el selector o archivo falta o si carga pero queda sobrescrito.
Recoge:
versiones anterior y nueva
hora de actualización
archivo, selector o hook ausente
capturas
pruebas de consola o CSSNo incluyas contenido privado.
Localiza el código anterior
Busca copias previas, historial Git, snapshots y copias del desarrollador. Compara solo el tema padre y los directorios hijo o personalizados relevantes.
No uses la caché del navegador como única fuente; el resultado minificado puede estar incompleto o generado.
Confirma quién creó el cambio y qué resolvía.
Audita ajustes y datos de diseño
Algunos temas guardan colores, tipografía, cabecera y maquetador en wp_options o entradas personalizadas. Compara una copia anterior de la base antes de asumir que se borró código.
No importes todo un paquete antiguo de opciones en producción: puede sobrescribir menús, widgets o URLs nuevos. Extrae el ajuste concreto, pruébalo y conserva el esquema de la versión actual.
Revisa ubicaciones más seguras
Comprueba Apariencia > Personalizar > CSS adicional, tema hijo, estilos del Editor del sitio, plugin de snippets y plugin propio. Quizá cambió la especificidad del selector y no el código.
Si el CSS existe, identifica el marcado nuevo. Evita apilar !important sin entender la cascada.
Regenera CSS y caché después de cambios controlados.
Compara las plantillas
Haz diff de la plantilla recuperada contra el padre antiguo y el nuevo. La versión nueva puede contener hooks, escaping o HTML necesario para plugins.
Fusiona:
correcciones y estructura del proveedor
solo el cambio personalizado intencionado
escaping y hooks actuales
cabecera de versión documentadaNo restaures toda la plantilla vieja: puede reintroducir vulnerabilidades.
Crea o repara un tema hijo
Mueve las plantillas, CSS y funciones apropiadas a un tema hijo. Carga estilos con el método documentado.
/*
Theme Name: Site Child
Template: parent-theme-directory
*/Template debe coincidir con el directorio padre. Haz copia y prueba la activación en staging.
Saca la funcionalidad del tema
Shortcodes, tipos de contenido, integraciones y lógica comercial deben vivir en un plugin propio mantenido para no desaparecer al cambiar el diseño.
Prefiere hooks a plantillas copiadas si basta un filtro o acción. Menos overrides reducen trabajo futuro.
No guardes secretos en el tema ni en JavaScript visible.
Restaura el cambio visual con seguridad
Aplica en staging el cambio mínimo revisado. Prueba escritorio y móvil, usuarios anónimos y conectados y navegadores clave.
Comprueba accesibilidad: foco, teclado, contraste y zoom. Un aspecto idéntico puede romper la interacción.
Despliega con control de versiones y cache-busting.
Comprueba plantillas de bloques
En temas de bloques, las plantillas del Editor del sitio pueden prevalecer sobre los archivos. Una versión de base marcada como «Personalizada» puede esconder la nueva del proveedor.
Exporta estilos y plantillas antes de restablecer. Compara el marcado de bloques, fusiona solo ajustes intencionados y valida navegación, patrones y responsive.
Demuestra resistencia a futuras actualizaciones
Ejecuta otra vez la actualización del padre en una copia staging y confirma que sobreviven el tema hijo y el plugin propio. Documenta cada override y la versión comparada.
El mantenimiento recurrente debe revisar diferencias con cada versión. La reparación duradera restaura el diseño y separa las personalizaciones de los archivos que el proveedor sustituye.