Wordpress — Actualización base de datos al actualizar Wordpress

Uno de los problemas que podemos encontrarnos después de actualizar WordPress es que los archivos del núcleo se hayan actualizado correctamente, pero la base de datos todavía no haya ejecutado las rutinas de actualización correspondientes.

El resultado puede ser bastante desconcertante: intentamos acceder al panel de administración y WordPress nos muestra una pantalla indicando que es necesario actualizar la base de datos, o directamente encontramos errores relacionados con la versión de la base de datos.

Este problema suele aparecer después de una actualización manual, una actualización interrumpida, una restauración de una copia de seguridad o cuando los archivos de WordPress se han sustituido correctamente pero el proceso de actualización de la base de datos no ha llegado a completarse.

En este artículo vamos a ver qué significa realmente este problema, cómo funciona internamente la comprobación de versiones de WordPress y cuáles son las formas más seguras de solucionarlo.

Nota: antes de modificar archivos o ejecutar consultas SQL sobre una instalación de WordPress, realiza siempre una copia de seguridad completa de la base de datos y de los archivos.

Tabla de Contenidos

¿Qué está ocurriendo realmente?

Cuando actualizamos WordPress no estamos actualizando únicamente archivos PHP, JavaScript, CSS e imágenes del núcleo.

Algunas versiones de WordPress también introducen cambios en la estructura o en los datos almacenados en la base de datos. Por este motivo, una actualización puede implicar dos procesos diferentes:

Actualización de los archivos del núcleo: se sustituyen los archivos de WordPress por los correspondientes a la nueva versión.
Actualización de la base de datos: WordPress ejecuta las rutinas necesarias para adaptar la base de datos a la nueva versión.

Ambos procesos están relacionados, pero no son exactamente lo mismo.

De hecho, el propio sistema de actualización de WordPress comprueba la versión de la base de datos y, cuando es necesario, ejecuta el proceso de actualización correspondiente. :contentReference[oaicite:1]{index=1}

La diferencia entre la versión de WordPress y la versión de la base de datos

Aquí existe una confusión bastante habitual.

WordPress maneja varios conceptos de versión diferentes:

Versión de WordPress: identifica la versión del núcleo instalado.
Versión del esquema de la base de datos: identifica la versión de estructura de datos que tiene preparada la instalación.
Versión del servidor MySQL/MariaDB: identifica el software de base de datos utilizado por el servidor.

Estos valores no representan lo mismo.

La versión de la base de datos de WordPress se almacena como la opción db_version dentro de la tabla wp_options. Además, el prefijo wp_ no es obligatorio: una instalación puede utilizar cualquier otro prefijo configurado en wp-config.php. :contentReference[oaicite:2]{index=2}

Por tanto, si tu instalación utiliza, por ejemplo, el prefijo serna_, la tabla será:

serna_options

y no:

wp_options

¿Qué es `$wp_db_version`?

Durante el proceso de carga de WordPress existe una variable denominada $wp_db_version que representa la versión de esquema de base de datos que espera la versión actual del núcleo.

Por otro lado, WordPress obtiene de la base de datos el valor almacenado en la opción:

db_version

De forma simplificada, podemos imaginar la comprobación de esta manera:

Versión esperada por WordPress
            ↓
      $wp_db_version

            VS

Versión registrada en la base de datos
            ↓
        db_version

Si ambas versiones coinciden, WordPress considera que la base de datos está actualizada.

Si no coinciden, WordPress sabe que existen rutinas de actualización de la base de datos que deben ejecutarse.

Internamente, el proceso de actualización compara precisamente estos valores y, cuando son diferentes, ejecuta las rutinas necesarias para actualizar el esquema. :contentReference[oaicite:3]{index=3}

Cómo comprobar el valor almacenado en la base de datos

Podemos consultar directamente el valor almacenado en la tabla de opciones.

Por ejemplo, utilizando phpMyAdmin, Adminer o cualquier otra herramienta de administración de MySQL/MariaDB, podemos ejecutar:

SELECT option_name, option_value
FROM wp_options
WHERE option_name = 'db_version';

Si tu instalación utiliza otro prefijo, sustituye wp_options por el nombre real de tu tabla.

También podemos consultar únicamente el valor:

SELECT option_value
FROM wp_options
WHERE option_name = 'db_version';

El resultado será un número entero que representa la versión del esquema de base de datos que WordPress tiene registrada actualmente.

Importante: no confundas `db_version` con MySQL o MariaDB

Este punto merece especial atención.

Cuando hablamos de db_version estamos hablando de la versión del esquema de la base de datos de WordPress, no de la versión del servidor MySQL o MariaDB.

Por ejemplo:

WordPress database version:
db_version = XXXXX

es completamente diferente de:

MariaDB = 10.x
MySQL = 8.x

La propia documentación de WordPress diferencia explícitamente la versión de la base de datos de WordPress de la versión del software de base de datos MySQL/MariaDB. :contentReference[oaicite:4]{index=4}

La solución recomendada: ejecutar la actualización de la base de datos

Si los archivos de WordPress se han actualizado pero la base de datos todavía no, lo primero que debemos intentar es permitir que WordPress ejecute su proceso normal de actualización.

No deberíamos modificar manualmente db_version simplemente para hacer desaparecer el aviso.

Esto es importante porque cambiar el número almacenado en la base de datos no ejecuta las migraciones necesarias.

El número únicamente indica qué versión del esquema cree WordPress que tiene la base de datos. Las modificaciones reales las realizan las rutinas de actualización.

WordPress dispone de una función interna denominada wp_upgrade(), encargada de ejecutar las rutinas necesarias cuando detecta que la base de datos está por detrás de la versión esperada. Entre otras operaciones, el proceso ejecuta las actualizaciones del esquema y diferentes rutinas de migración. :contentReference[oaicite:5]{index=5}

Acceder directamente a `upgrade.php`

En determinadas situaciones WordPress puede indicarnos que necesitamos actualizar la base de datos.

Si el panel de administración no nos permite continuar normalmente, podemos probar a acceder directamente a:

https://tu-dominio.com/wp-admin/upgrade.php

Sustituye tu-dominio.com por el dominio real de tu instalación.

Si WordPress detecta que la base de datos necesita una actualización, esta página puede iniciar el proceso correspondiente.

Una vez finalizado, vuelve a intentar acceder al panel:

https://tu-dominio.com/wp-admin/

¿Por qué ocurre después de una actualización?

Existen varias situaciones que pueden provocar que los archivos y la base de datos queden temporalmente desincronizados.

1. Actualización interrumpida

Una actualización puede interrumpirse por diferentes motivos:

pérdida de conexión con el servidor,
timeout del hosting,
problemas de permisos,
falta de espacio en disco,
error de PHP,
problemas con plugins,
o una interrupción manual del proceso.

En estos casos es posible que los archivos nuevos hayan llegado al servidor mientras que la actualización de la base de datos no haya terminado.

2. Actualización manual de WordPress

También puede ocurrir cuando sustituimos manualmente los archivos del núcleo por una versión nueva.

WordPress proporciona mecanismos para actualizar los archivos y posteriormente ejecutar la actualización de la base de datos. Si únicamente copiamos los archivos y no completamos el segundo paso, podemos encontrarnos con esta situación. :contentReference[oaicite:6]{index=6}

3. Restauración de una copia de seguridad

Otra situación habitual aparece cuando restauramos archivos y base de datos desde copias que no corresponden exactamente al mismo momento.

Por ejemplo:

Archivos WordPress → versión nueva

Base de datos → versión anterior

En este caso podemos terminar con una instalación cuyos componentes no están sincronizados.

4. Problemas durante el proceso automático

Las actualizaciones automáticas de WordPress realizan pasos adicionales durante el proceso. Si alguna parte falla, WordPress puede necesitar completar posteriormente la actualización de la base de datos. El propio sistema de actualización del núcleo realiza la actualización de la base de datos como una fase separada del proceso. :contentReference[oaicite:7]{index=7}

Antes de tocar nada: haz una copia de seguridad

Este punto no debería ser opcional.

Antes de realizar cualquier modificación manual sobre una instalación de WordPress, realiza como mínimo:

Copia completa de la base de datos.
Copia de los archivos de WordPress.
Copia de wp-content.
Copia de wp-config.php.

La documentación oficial de WordPress recomienda realizar copias de seguridad de la base de datos y de los archivos antes de iniciar una actualización. :contentReference[oaicite:8]{index=8}

Una copia de seguridad que nunca hemos probado a restaurar tampoco debería considerarse una copia de seguridad completamente fiable.

¿Debemos modificar manualmente `wp-includes/version.php`?

No como primera opción.

Este era precisamente uno de los puntos más peligrosos del procedimiento original de este artículo.

El archivo:

wp-includes/version.php

contiene información fundamental del núcleo de WordPress, incluida la versión del software y la versión de esquema esperada por esa versión.

Modificar manualmente $wp_db_version para que coincida con el valor almacenado en la base de datos puede parecer una solución rápida, pero puede ocultar el problema real.

Si la nueva versión de WordPress necesita ejecutar determinadas migraciones y simplemente cambiamos el número para hacer creer al sistema que ya se han ejecutado, esas migraciones seguirán sin ejecutarse.

En otras palabras:

Cambiar el número
        ≠
Actualizar la estructura de la base de datos

Por eso, no recomendamos editar manualmente $wp_db_version salvo que sepamos exactamente qué estamos haciendo y exista una razón técnica concreta para ello.

La forma correcta de entender el proceso

Podemos representar el funcionamiento simplificado de WordPress de esta manera:

1. WordPress carga su versión actual
              ↓
2. Obtiene la versión de esquema esperada
              ↓
3. Consulta "db_version" en wp_options
              ↓
4. Compara ambos valores
              ↓
        ¿Coinciden?
         ↙       ↘
       SÍ         NO
       ↓           ↓
   Continúa    Ejecuta las
   normalmente  rutinas de
               actualización
                    ↓
             Actualiza la BD
                    ↓
             Actualiza db_version

El objetivo no es simplemente conseguir que los dos números sean iguales. El objetivo es que las operaciones necesarias para llevar la base de datos al nuevo esquema se ejecuten correctamente.

Solución mediante WP-CLI

Si tenemos acceso SSH al servidor y utilizamos WP-CLI, la solución puede ser todavía más sencilla.

Desde el directorio de instalación de WordPress podemos ejecutar:

wp core update-db

Este comando está pensado precisamente para ejecutar las actualizaciones pendientes de la base de datos de WordPress.

Después podemos comprobar el estado de WordPress:

wp core version
wp db check

Si el servidor lo permite, esta es una de las formas más limpias de realizar la operación porque evitamos editar manualmente los archivos internos del núcleo.

¿Y si no puedo acceder al panel de WordPress?

No poder entrar en /wp-admin/ no significa necesariamente que tengamos que modificar archivos internos.

Podemos trabajar desde otros niveles:

WP-CLI: si disponemos de acceso SSH.
phpMyAdmin: para inspeccionar la base de datos.
FTP/SFTP: para revisar los archivos del núcleo.
Panel del hosting: para restaurar copias o consultar errores.
Logs de PHP: para investigar errores producidos durante la actualización.

Lo importante es identificar por qué la actualización de la base de datos no se completó antes de empezar a modificar valores manualmente.

Comprobar la tabla de opciones

Una comprobación sencilla desde phpMyAdmin consiste en ejecutar:

SELECT option_name, option_value
FROM wp_options
WHERE option_name = 'db_version';

También podemos comprobar la existencia de la opción:

SELECT *
FROM wp_options
WHERE option_name = 'db_version';

Si la consulta no devuelve ningún resultado, hay que detenerse y revisar la instalación antes de realizar modificaciones.

Comprobar el prefijo de las tablas

Otro error bastante común consiste en asumir que todas las instalaciones utilizan wp_ como prefijo.

El prefijo se define en wp-config.php mediante:

$table_prefix = 'wp_';

Pero podría ser, por ejemplo:

$table_prefix = 'serna_';

En ese caso la tabla correcta sería:

serna_options

Por tanto, no ejecutes consultas contra wp_options sin comprobar primero cuál es el prefijo real de tu instalación.

¿Qué pasa si la actualización de la base de datos falla?

Si accedemos a upgrade.php o ejecutamos la actualización mediante WP-CLI y aparece un error, no debemos limitar el diagnóstico a db_version.

El problema podría estar relacionado con:

una tabla dañada,
permisos insuficientes,
una versión incompatible de PHP,
una versión incompatible de MySQL/MariaDB,
un plugin que modifica el proceso de actualización,
un tema con código incompatible,
una actualización anterior incompleta,
falta de espacio en disco,
o un error producido por una migración concreta.

WordPress también comprueba que la versión del servidor MySQL sea compatible con la versión instalada de WordPress. Este valor es completamente independiente de db_version. :contentReference[oaicite:9]{index=9}

Revisar los registros de errores

Cuando la actualización falla, los registros del servidor pueden proporcionar información mucho más útil que modificar directamente la base de datos.

Dependiendo del hosting, podemos encontrar los errores en:

el log de PHP,
el log de Apache,
el log de Nginx,
el panel de control del hosting,
o el archivo debug.log de WordPress si tenemos habilitada la depuración.

Para activar temporalmente el registro de errores de WordPress podemos utilizar en wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

De esta manera los errores se registran sin mostrarse directamente a los visitantes.

Importante: la depuración debe utilizarse con cuidado en producción y conviene desactivarla una vez finalizado el diagnóstico.

Después de solucionar el problema

Una vez completada correctamente la actualización de la base de datos, conviene realizar varias comprobaciones.

1. Acceder al panel

Comprueba que:

/wp-admin/

funciona correctamente.

2. Comprobar la versión de WordPress

Comprueba que el núcleo instalado corresponde con la versión que pretendías instalar.

3. Revisar plugins y temas

Comprueba que los plugins y el tema activo funcionan correctamente y que no existen errores PHP.

4. Comprobar el sitio público

No debemos limitar la comprobación al panel de administración.

Revisa también:

página principal,
entradas,
páginas,
formularios,
imágenes,
menús,
enlaces permanentes,
REST API si tu instalación la utiliza,
y cualquier funcionalidad crítica del sitio.

¿Y la caché del navegador?

Limpiar la caché del navegador puede ser útil si estamos viendo una versión antigua de una página o algún recurso almacenado localmente.

Sin embargo, la caché del navegador no soluciona una base de datos que realmente necesita ser actualizada.

Si el problema está en la sincronización entre el núcleo de WordPress y la base de datos, debemos solucionar primero el problema del servidor.

También puede existir caché a otros niveles:

caché de WordPress,
OPcache de PHP,
caché del servidor web,
Redis/Memcached,
CDN,
o sistemas de caché proporcionados por el hosting.

Por tanto, limpiar únicamente la caché del navegador no siempre será suficiente después de una actualización.

Un procedimiento seguro para resolverlo

Si te encuentras con este problema, este sería el orden recomendado:

No modificar todavía wp-includes/version.php.
Realizar una copia de seguridad completa.
Comprobar que los archivos del núcleo corresponden a la versión que queremos utilizar.
Intentar acceder a /wp-admin/upgrade.php.
Si tenemos SSH, ejecutar wp core update-db.
Comprobar el valor de db_version en la tabla de opciones.
Revisar los logs si la actualización falla.
Comprobar compatibilidad de PHP y MySQL/MariaDB.
Revisar plugins y temas si existe un error durante la migración.
Comprobar finalmente el panel y la parte pública del sitio.

Lo que NO deberíamos hacer

Hay una tentación bastante grande cuando encontramos una discrepancia de versiones: abrir wp-includes/version.php, buscar:

$wp_db_version

y cambiar el número manualmente hasta que coincida con el valor de la base de datos.

No es una solución general.

El número no es el proceso de actualización. Es simplemente una referencia que WordPress utiliza para determinar si debe ejecutar determinadas rutinas.

Forzar artificialmente la coincidencia puede provocar que WordPress considere la base de datos actualizada cuando todavía existen cambios pendientes.

Por eso, si una actualización normal no funciona, es mucho mejor investigar por qué no se ha ejecutado la migración que ocultar la diferencia modificando el número.

Conclusión

Que los archivos de WordPress estén actualizados y que la base de datos todavía no lo esté no significa necesariamente que hayamos perdido información o que la instalación esté irremediablemente dañada.

En muchas ocasiones simplemente estamos ante una actualización incompleta que puede solucionarse ejecutando correctamente el proceso de actualización de la base de datos.

La clave está en entender que la versión de WordPress, la versión del esquema de la base de datos y la versión del servidor MySQL/MariaDB son conceptos diferentes.

WordPress utiliza el valor db_version almacenado en la tabla de opciones para determinar qué versión del esquema tiene registrada la instalación y compara ese valor con la versión esperada por el núcleo. Cuando existe una diferencia, WordPress dispone de rutinas específicas para actualizar la estructura y los datos necesarios. :contentReference[oaicite:10]{index=10}

Por tanto, antes de editar archivos internos o ejecutar consultas SQL de modificación, lo recomendable es dejar que WordPress haga su propio trabajo.

Y si ese proceso falla, entonces sí: toca ponerse el mono de trabajo, revisar logs, PHP, MySQL/MariaDB, permisos, plugins, temas y el estado real de la base de datos hasta encontrar la causa.

¿Tienes otros problemas con WordPress?

Si estás teniendo otros problemas con tu instalación, también puedes consultar nuestra recopilación de consejos útiles para WordPress, donde encontrarás diferentes soluciones y procedimientos para diagnosticar problemas habituales.

Consejo final: antes de actualizar WordPress, realiza siempre una copia de seguridad y, especialmente en instalaciones importantes, comprueba que puedes restaurarla. Una actualización de WordPress debería ser un procedimiento controlado, no una operación de cirugía a corazón abierto a las tres de la mañana. 😄

Serna Studio

Website | + posts

Automation & Data Specialist | Web Development | Data Processing & Integration