Qué importa primero: WordPress compara la versión de la base de datos almacenada en opciones con la versión esperada por los archivos de núcleo cargados. Un bucle significa que la actualización no persistió, la solicitud utiliza otra base de datos, o versiones de código difieren entre los nodos.
Qué indica realmente este síntoma
Al hacer clic repetido en Actualizar se puede ocultar un problema de equilibrio de carga o caché. La versión del núcleo activo, la opción db_version y la conexión a la base de datos deben comprobarse desde la misma ruta de solicitud.
Recopila pruebas antes de cambiar nada
- Grabar la versión central servida por el nodo web y WP-CLI.
- Lee la opción db_version de la base de datos WordPress está usando realmente.
- Comprueba si varios contenedores o servidores ejecutan diferentes versiones de núcleo.
- Inspecciona los errores de escritura de la base de datos, caché de objetos y el rutas de reproducción de lectura.
Causas más habituales
- Versiones de código mixto: Un nodo espera un esquema más nuevo mientras que otro sirve archivos antiguos.
- Base de datos incorrecta: Web y CLI apuntan a diferentes bases de datos o prefijos de tabla.
- Fallo de escritura: La actualización del esquema se ejecuta pero no puede persistir la nueva opción de versión.
- Stale caché de objetos: Un db_version en caché sigue devolviéndose después de que la base de datos haya cambiado.
Secuencia segura de diagnóstico y reparación
- Tome una copia de seguridad de la base de datos y coloque el sitio en una ventana de mantenimiento controlada.
- Alinee cada nodo web en la misma versión completa del núcleo.
- Ejecute la actualización de la base de datos una vez a través de WP-CLI o la ruta de administración canónica.
- Rocíe el caché de objetos pertinente y Confirma la versión almacenada desde la base de datos activa.
Cómo distinguir entre las causas probables
No trates Versiones de código mixto y Base de datos incorrecta como causas equivalentes. Un nodo espera un esquema más nuevo mientras que otro sirve archivos antiguos. En cambio, web y CLI apuntan a diferentes bases de datos o prefijos de tabla. Para distinguirlas, usa estas dos comprobaciones: Grabar la versión central servida por el nodo web y WP-CLI; y lee la opción db_version de la base de datos WordPress está usando realmente. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Tome una copia de seguridad de la base de datos y coloque el sitio en una ventana de mantenimiento controlada— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No edite manualmente db_version para descarritoar la pantalla. El valor es evidencia de migraciones que pueden no haberse ejecutado.
Cómo verificar la reparación
- El administrador se abre sin volver a la pantalla de actualización.
- Las versiones de código y base de datos coinciden en cada nodo.
- Las tablas centrales y las operaciones críticas de plugin funcionan después de caché y reiniciar el servicio.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.