El botón «Publicar» de WordPress ha desaparecido: cómo encontrar el problema
Hola.
Hoy vamos a tocar un problema que puede dejarnos bastante desconcertados cuando estamos trabajando con WordPress:
Entramos al editor de una entrada, queremos publicarla y, de repente, el botón «Publicar» ha desaparecido. En su lugar solamente aparece algo como «Pendiente de revisión».
¿Qué demonios está pasando?
Lo primero es no empezar a desactivar cosas a lo loco. WordPress puede estar ocultando la posibilidad de publicar por diferentes motivos y, en algunos casos, el problema no está realmente en el editor, sino bastante más abajo.
Antes de empezar: las comprobaciones habituales
Cuando buscamos este problema por Internet encontraremos prácticamente siempre las mismas recomendaciones.
- Desactivar los plugins y comprobar si alguno está provocando el conflicto.
- Desactivar temporalmente el tema activo y utilizar uno de los temas predeterminados de WordPress.
- Comprobar el rol y las capacidades del usuario.
- Comprobar que el usuario tenga permisos suficientes para publicar entradas.
- Actualizar WordPress, plugins y tema.
- Comprobar si existe algún error de JavaScript en el navegador.
- Revisar los errores de PHP y del servidor.
- Comprobar la base de datos.
Son comprobaciones perfectamente válidas y deberían formar parte de nuestro diagnóstico.
El problema es que, en mi caso, ninguna de las primeras comprobaciones solucionaba el problema.
Desactivar plugins también puede darnos una pista
Una de las pruebas que hice fue desactivar Yoast SEO directamente desde el backend de WordPress.
Y funcionó.
Durante un momento pensé que ya teníamos localizado al culpable.
Pero no.
El problema volvió a aparecer.
Esto es importante porque una prueba que aparentemente funciona no significa necesariamente que hayamos encontrado la causa real. Puede existir un error subyacente que simplemente deja de manifestarse al cambiar determinadas condiciones.
Cuando WordPress se comporta de forma extraña: activa la depuración
Cuando WordPress empieza a hacer cosas que no tienen demasiado sentido, una de las primeras herramientas que debemos utilizar es su sistema de depuración.
Para ello podemos editar nuestro archivo:
wp-config.php
Y activar el modo de depuración:
define('WP_DEBUG', true);
Normalmente esta constante se encuentra cerca de la configuración relacionada con el modo de depuración de WordPress.
Si ya existe:
define('WP_DEBUG', false);
podemos cambiar temporalmente false por true.
Importante
No es recomendable dejar WP_DEBUG activado indefinidamente en una web de producción, especialmente si los errores se muestran directamente a los visitantes. Utilízalo para diagnosticar el problema y después vuelve a configurar la depuración correctamente.
Mejor todavía: registrar los errores en un archivo
En un entorno de desarrollo podemos mostrar los errores directamente, pero en producción es preferible registrarlos en un archivo y evitar que información interna de nuestra instalación aparezca públicamente.
Una configuración bastante más apropiada para investigar un problema en una instalación de WordPress sería:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Con esta configuración, WordPress puede registrar los errores en:
wp-content/debug.log
De esta forma podemos reproducir el problema, revisar el registro y buscar la causa sin mostrar información sensible a los visitantes.
El error que estaba provocando mi problema
En mi caso, después de activar la depuración apareció finalmente la pista que necesitábamos:
WordPress database error Duplicate entry '0' for key 'PRIMARY' INSERT INTO `wp_posts` ...
Y aquí estaba el verdadero problema.
WordPress estaba intentando insertar una nueva entrada en la tabla wp_posts, pero la base de datos estaba encontrando un problema con el valor de la clave primaria.
¿Qué significa «Duplicate entry … for key PRIMARY»?
La tabla wp_posts utiliza un campo identificador para cada entrada, página, revisión y otros tipos de contenido almacenados por WordPress.
En una instalación estándar, ese campo es:
ID
Y normalmente está definido como una clave primaria con incremento automático.
Podemos comprobar la estructura de la tabla ejecutando:
SHOW CREATE TABLE wp_posts;
También podemos hacerlo desde phpMyAdmin entrando en la tabla wp_posts y consultando su pestaña Estructura.
Lo que debemos comprobar es que el campo ID tenga las características esperadas:
- Sea de tipo entero.
- Sea la PRIMARY KEY.
- Tenga activado AUTO_INCREMENT.
El problema: ID no estaba funcionando como AUTO_INCREMENT
En mi caso, el problema estaba precisamente en la estructura del identificador.
WordPress esperaba que MySQL generase automáticamente el siguiente ID al insertar una nueva entrada, pero el campo no estaba configurado correctamente para hacerlo.
Como consecuencia, la inserción terminaba intentando utilizar un valor que ya existía y MySQL devolvía:
Duplicate entry '0' for key 'PRIMARY'
Y, aunque el mensaje puede parecer completamente desconectado del botón «Publicar», ahí estaba la relación.
WordPress no podía completar correctamente la inserción de la nueva entrada en wp_posts.
Cómo comprobarlo desde phpMyAdmin
Si utilizamos phpMyAdmin, podemos comprobarlo de una forma bastante sencilla.
- Seleccionamos la base de datos de WordPress.
- Localizamos la tabla
wp_posts. - Entramos en Estructura.
- Localizamos el campo
ID. - Comprobamos que sea la clave primaria.
- Comprobamos que tenga activado AUTO_INCREMENT.
Recuerda que wp_ es solamente el prefijo habitual. Si durante la instalación utilizaste otro prefijo, la tabla podría llamarse, por ejemplo:
mi_prefijo_posts
Por tanto, no debemos asumir que nuestra tabla se llama exactamente wp_posts.
Activar AUTO_INCREMENT
Si hemos comprobado que el campo ID debería utilizar incremento automático pero no lo tiene configurado, podemos corregirlo desde la estructura de phpMyAdmin.
En la edición del campo ID, debemos asegurarnos de que:
- Es una columna numérica adecuada para los IDs.
- Está definida como PRIMARY KEY.
- Tiene activado AUTO_INCREMENT.
Una vez guardados los cambios, podemos volver a WordPress y comprobar si el problema ha desaparecido.
Antes de modificar la estructura de la base de datos
Haz siempre una copia de seguridad. Modificar directamente una tabla de WordPress no es una operación que debamos realizar a ciegas.
También podemos comprobar el AUTO_INCREMENT desde SQL
Si preferimos trabajar directamente con SQL, primero podemos consultar la estructura:
SHOW CREATE TABLE wp_posts;
Y también podemos comprobar información sobre la tabla mediante:
SHOW TABLE STATUS LIKE 'wp_posts';
El resultado nos permitirá comprobar, entre otras cosas, el valor actual de Auto_increment.
Esto es especialmente útil cuando estamos investigando problemas relacionados con IDs y queremos saber qué está ocurriendo realmente en MySQL en lugar de modificar valores sin comprobarlos previamente.
No confundamos AUTO_INCREMENT con reparar una tabla
En el artículo original intenté utilizar:
REPAIR TABLE wp_posts;
pero esta operación no solucionó el problema.
Y aquí hay un detalle importante.
REPAIR TABLE no es una especie de botón mágico para solucionar cualquier problema de una tabla MySQL. Su utilidad depende del motor de almacenamiento utilizado y del tipo de problema existente.
Las tablas modernas de WordPress normalmente utilizan InnoDB, y para InnoDB debemos abordar los problemas de estructura, índices o integridad de una forma diferente.
Por eso, antes de ejecutar comandos de reparación, debemos averiguar qué problema tenemos realmente.
¿Por qué desaparecía el botón «Publicar»?
Esta es probablemente la parte más curiosa del problema.
Desde el punto de vista del usuario, parecía un problema de permisos:
«WordPress no me deja publicar».
Pero el problema real estaba ocurriendo cuando WordPress intentaba guardar los datos en la base de datos.
El editor podía mostrar una interfaz incompleta o una acción diferente porque la operación necesaria para crear la entrada no podía completarse correctamente.
Por eso es tan importante no quedarse únicamente con lo que vemos en pantalla.
Cuando WordPress hace algo aparentemente absurdo, los logs pueden contarnos qué está ocurriendo realmente.
Una metodología mejor para diagnosticar WordPress
Este problema me dejó una lección bastante útil: antes de empezar a desactivar veinte plugins y tocar medio servidor, conviene intentar obtener información objetiva.
Un orden razonable sería:
- Reproducir el problema.
- Comprobar el rol y las capacidades del usuario.
- Comprobar si el problema ocurre con otro usuario administrador.
- Revisar la consola del navegador por si existen errores JavaScript.
- Activar temporalmente la depuración de WordPress.
- Revisar
wp-content/debug.log. - Revisar los logs de PHP y del servidor web.
- Si el error apunta a MySQL, revisar la estructura de la tabla afectada.
- Hacer backup antes de modificar la base de datos.
- Realizar una modificación concreta y comprobar el resultado.
De esta manera pasamos de:
"WordPress no publica y no sé por qué"
a algo mucho más útil:
"WordPress intenta insertar un registro en wp_posts y MySQL devuelve un error de PRIMARY KEY."
Y eso ya nos permite trabajar con una hipótesis concreta.
Un detalle importante sobre los permisos de wp-config.php
En la versión original del artículo recomendaba descargar wp-config.php, establecer determinados permisos y posteriormente devolverlos a otros valores.
Conviene matizar esto.
No existe un valor universal que debamos aplicar a wp-config.php en todas las instalaciones. Los permisos correctos dependen del servidor, del usuario que ejecuta PHP y de cómo esté configurado el alojamiento.
Además, wp-config.php contiene información especialmente sensible, como las credenciales de la base de datos y las claves de autenticación.
Por tanto:
- No debemos hacerlo escribible para todo el mundo.
- No debemos dejar permisos excesivamente abiertos.
- Debemos mantener una configuración de permisos coherente con nuestro servidor.
- Si descargamos el archivo para editarlo, debemos protegerlo y no compartirlo públicamente.
La seguridad del archivo es mucho más importante que aplicar mecánicamente un número como 644 o 444.
Después de solucionar el problema
Una vez solucionado el problema, debemos volver a revisar la configuración de depuración.
Si no necesitamos mantener el registro de errores activo, podemos dejar:
define('WP_DEBUG', false);
Y eliminar o conservar el resto de constantes de depuración según las necesidades del entorno.
En producción, nuestra prioridad debe ser evitar que los errores internos de PHP o WordPress sean mostrados directamente a los visitantes.
También conviene revisar el archivo:
wp-content/debug.log
y eliminarlo si contiene información sensible y ya no necesitamos conservarlo.
Conclusión
Cuando el botón «Publicar» desaparece de WordPress y solamente tenemos disponible «Pendiente de revisión», no debemos asumir automáticamente que el problema está en un plugin, en el tema o en los permisos del usuario.
Puede existir un problema mucho más profundo.
En mi caso, la clave estuvo en activar la depuración y descubrir este error:
Duplicate entry '0' for key 'PRIMARY'
A partir de ahí pudimos seguir el rastro hasta la tabla wp_posts y comprobar la configuración del campo ID.
El problema estaba relacionado con el mecanismo de incremento automático del identificador y, una vez corregida la estructura, WordPress volvió a poder crear nuevas entradas correctamente.
La moraleja: cuando WordPress haga algo que no tenga ningún sentido, antes de empezar a desactivar plugins a lo loco, mira los logs.
Muchas veces el error está ahí delante, esperando a que lo leamos.
Y, como siempre cuando vamos a tocar una base de datos de producción: backup antes de tocar nada.
Visitas: 789
Automation & Data Specialist | Web Development | Data Processing & Integration