Cómo diagnostiqué un problema en WordPress donde un editor solo veía entradas antiguas

En soporte técnico WordPress hay fallos que parecen simples, pero que en realidad esconden una causa muy específica. Uno de ellos ocurre cuando un usuario con rol de editor entra al panel de administración, accede a Entradas > Todas las entradas y solo ve contenido viejo, mientras que las publicaciones nuevas, los borradores actuales o las notas recientes parecen haber desaparecido.

A primera vista, este problema puede hacer pensar en permisos, caché, errores del rol de usuario, consultas rotas o incluso fallos de base de datos. Sin embargo, en la auditoría que realicé recientemente encontré una causa mucho más puntual: una preferencia persistida en el perfil del usuario estaba alterando silenciosamente el comportamiento del listado del administrador.

En este artículo explico cómo audité el problema paso a paso usando ChatGPT como asistente técnico, PowerShell, SSH y WP-CLI, cómo fui descartando hipótesis, qué encontré exactamente y cuál fue la solución definitiva.

El síntoma: el editor solo veía entradas viejas

El problema reportado era claro. Un usuario con rol de editor indicaba que, al ingresar al panel de WordPress, no podía ver las notas nuevas ni los borradores recientes. Solo le aparecían entradas antiguas, de semanas o meses atrás.

Lo importante era que el fallo parecía afectar únicamente a su cuenta. Eso ya nos daba una pista clave: si el problema no era general del sitio, entonces probablemente no estábamos ante un error global de WordPress, sino frente a algo vinculado con el estado particular de ese usuario.

En auditorías de este tipo, lo primero que conviene evitar es tocar muchas cosas al mismo tiempo. La mejor práctica es validar hipótesis de forma quirúrgica, un paso a la vez.

Primer análisis: qué podía estar pasando realmente

Antes de ejecutar comandos, armé una lectura técnica inicial del caso. Las hipótesis más probables eran estas:

• que el usuario no tuviera realmente el rol esperado
• que existieran capacidades o permisos alterados
• que hubiese preferencias guardadas en el admin afectando el listado
• que algún código personalizado estuviera modificando la query del administrador
• que el problema estuviera en el user meta del usuario y no en el contenido

También descarté rápidamente algunos escenarios menos probables. Si otros usuarios sí podían ver el contenido actual, entonces no tenía sentido pensar primero en una base de datos dañada o en una pérdida real de publicaciones. Tampoco parecía un problema de caché de frontend, porque el fallo ocurría dentro del panel de administración.

Herramientas utilizadas en la auditoría

La auditoría se realizó con un enfoque muy práctico:

• ChatGPT como asistente de razonamiento y apoyo en la estrategia de diagnóstico
• PowerShell como entorno de trabajo local
• SSH para conectarme al servidor
• WP-CLI para inspeccionar usuarios, roles y metadatos directamente
• lectura de evidencias reales antes de tomar decisiones

Cuando el problema está dentro del administrador de WordPress, inspeccionar por línea de comandos suele ahorrar muchísimo tiempo.

Comandos utilizados en la auditoría

1. Conexión SSH

ssh usuario-servidor

2. Verificación del usuario

wp user get usuario@dominio.com --fields=ID,user_login,roles

3. Listado de metadatos

wp user meta list ID_USUARIO

4. Eliminación de meta sospechoso

wp user meta delete ID_USUARIO clave_meta_sospechosa

5. Búsqueda en código

grep -R "clave_meta_sospechosa" wp-content/

Paso 1: confirmar el rol real del usuario

El primer paso fue verificar si el usuario tenía efectivamente el rol correcto. La comprobación confirmó que el usuario sí tenía el rol de editor. Ese dato fue importante porque nos permitió descartar, bastante temprano, una explicación basada puramente en permisos mal asignados.

Paso 2: revisar los metadatos del usuario

Con el rol validado, el siguiente paso lógico fue revisar el user meta. Esta parte es crítica, porque muchas veces WordPress y los plugins almacenan preferencias persistentes en la cuenta del usuario: columnas visibles, orden del listado, preferencias del editor, filtros guardados, comportamiento del panel, etcétera.

Al listar los metadatos del usuario apareció una pista muy interesante: existían varias claves personalizadas vinculadas al sistema del sitio, y entre ellas surgía una especialmente sospechosa, relacionada con preferencias de ordenado del listado. La preferencia guardada indicaba un orden no estándar para las entradas, vinculado a categorías y orden ascendente.

El punto clave: no era un dato de WordPress core

No estábamos viendo un ajuste interno común del core de WordPress, sino una preferencia persistida por una capa personalizada del sistema. Muchas incidencias raras en WordPress no se deben al núcleo del CMS, sino a la combinación entre preferencias antiguas guardadas en el usuario, código personalizado, cambios recientes en el sitio y filtros persistidos que dejan de ser compatibles.

En otras palabras, el problema no parecía estar en las entradas en sí, sino en cómo el panel estaba intentando listarlas para ese usuario concreto.

Paso 3: formular la hipótesis correcta

Una preferencia persistida en el perfil del usuario estaba alterando la consulta del administrador y, al combinarse con lógica personalizada del sitio, estaba haciendo que el listado mostrara entradas antiguas o dejara fuera el contenido reciente.

Esto explicaba varios síntomas a la vez: por qué el fallo afectaba solo a un usuario, por qué las entradas existían pero no aparecían correctamente, y por qué el problema había empezado “de repente”.

Paso 4: aplicar una corrección mínima y reversible

En lugar de desactivar muchas cosas o hacer cambios globales, opté por una medida mínima, controlada y reversible: eliminar únicamente la preferencia sospechosa del metadato del usuario.

Una vez eliminada esa clave, el usuario volvió a ingresar al administrador y el listado de entradas comenzó a mostrarse de forma correcta. Las publicaciones recientes aparecieron nuevamente, al igual que los borradores y el contenido actual. Eso confirmó la hipótesis.

Qué aprendí de esta auditoría

• Un problema visible en el administrador no siempre implica un error global del sitio. Muchas veces el fallo está encapsulado en el estado de un usuario concreto.
• El user meta puede ser mucho más determinante de lo que parece.
• Diagnosticar bien suele requerir menos acciones, no más: validar una hipótesis puntual y aplicar una corrección mínima.
• Trabajar por SSH con WP-CLI y un enfoque ordenado ahorra tiempo y reduce errores.

Conclusión

El problema no estaba en el rol del usuario, ni en la base de datos, ni en el contenido. Estaba en una preferencia persistida del usuario que alteraba la forma en que el administrador listaba las publicaciones. Cuando un editor dice que “solo ve entradas viejas”, la respuesta correcta no es asumir que faltan notas: a veces el problema está en cómo el panel interpreta una preferencia guardada desde hace tiempo.