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. Todo el caso está narrado de forma anónima y convertido en una guía práctica que puede ayudarte si administras sitios WordPress con usuarios editores, entornos personalizados o paneles modificados.
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 metadel 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, usando un flujo que hoy considero especialmente eficiente para mantenimiento WordPress profesional:
- 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
Este tipo de metodología permite trabajar con mucha precisión, sin depender exclusivamente de plugins visuales o de intuiciones. 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
A continuación, se detallan los comandos reales ejecutados durante la auditoría técnica mediante SSH y WP-CLI.
1. Conexión SSHssh usuario-servidor
2. Verificación del usuariowp user get usuario@dominio.com --fields=ID,user_login,roles
3. Listado de metadatoswp user meta list ID_USUARIO
4. Eliminación de meta sospechosowp user meta delete ID_USUARIO clave_meta_sospechosa
5. Búsqueda en códigogrep -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. Para eso usé WP-CLI y consulté los datos básicos del usuario.
El objetivo era confirmar tres cosas:
- que el usuario existía correctamente
- que su rol era realmente editor
- que no tuviera una mezcla de roles o algo inesperado
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.
Lo importante aquí no era solamente que existiera esa clave, sino qué contenía. La preferencia guardada indicaba un orden no estándar para las entradas, vinculado a categorías y orden ascendente. Eso ya nos sacaba claramente del comportamiento normal de WordPress.
El punto clave: no era un dato de WordPress core
Cuando apareció esa preferencia, la lectura técnica cambió mucho. No estábamos viendo un ajuste interno común del core de WordPress, sino una preferencia persistida por una capa personalizada del sistema, probablemente asociada a una funcionalidad de administración avanzada, un plugin auxiliar o una personalización del panel.
Ese detalle es fundamental porque 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
- 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
Con esos datos, la hipótesis principal pasó a ser esta:
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 perfectamente 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
- por qué el problema había empezado “de repente”
- por qué no tenía sentido culpar al contenido o al rol de editor
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.
Este enfoque es especialmente recomendable en sitios productivos. Si un problema parece estar acotado a una cuenta concreta, lo más prudente es intervenir primero sobre ese estado puntual, no sobre todo el sistema.
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é había ocurrido realmente
Técnicamente, lo que pasó fue esto:
- el usuario tenía guardada una preferencia persistente vinculada al orden o criterio de visualización del listado de entradas
- esa preferencia no pertenecía al comportamiento estándar de WordPress, sino a una capa personalizada del sistema
- por algún cambio reciente en el entorno, esa preferencia dejó de comportarse de forma compatible
- el resultado fue una consulta anómala en el admin, que devolvía un listado engañoso o incompleto
- al borrar la preferencia, WordPress volvió a usar un comportamiento normal y el problema desapareció
Dicho de forma simple: el contenido no faltaba, el panel estaba leyendo mal cómo debía mostrarlo para ese usuario.
Posibles causas que llevaron a este fallo
Aunque la solución fue concreta, es importante entender qué pudo haber originado el problema. Hay varios escenarios técnicamente plausibles.
1. Una preferencia guardada por una funcionalidad personalizada
Muchos sitios WordPress, sobre todo en medios, portales o entornos editoriales, incorporan personalizaciones para ordenar contenido, aplicar filtros, guardar vistas, modificar columnas o mejorar el flujo de redacción. Esas funciones suelen persistir información en user meta.
Si una de esas preferencias queda mal guardada o apunta a una estructura que luego cambia, puede romper el comportamiento del listado.
2. Cambios recientes en plugins, snippets o código del admin
Otra posibilidad muy fuerte es que el sitio haya recibido cambios recientes en:
- snippets
- plugins
- mu-plugins
- funciones de
pre_get_posts - filtros del administrador
- lógica editorial personalizada
En ese contexto, una preferencia antigua que antes funcionaba puede volverse incompatible sin que nadie lo note de inmediato.
3. Persistencia defectuosa de ordenados o filtros
En algunos sistemas, el usuario cambia el orden del listado una vez y el panel lo guarda de manera persistente. Si esa persistencia no valida correctamente qué valores son válidos, puede terminar almacenando un criterio problemático o no previsto.
4. Interacción entre taxonomías, orden y paginación
Cuando la consulta del admin se aparta del orden por fecha y empieza a mezclar criterios por taxonomía, orden ascendente o joins personalizados, puede aparecer un efecto visual muy confuso: el contenido no desaparece realmente, pero queda fuera de la lógica esperada de orden y paginación, lo que lleva al usuario a pensar que “solo hay notas viejas”.
Por qué usar ChatGPT en la auditoría fue útil
En este caso, ChatGPT no reemplazó el diagnóstico técnico, pero sí fue muy útil como apoyo metodológico. Sirvió para:
- ordenar hipótesis
- priorizar qué revisar primero
- no saltar a conclusiones apresuradas
- mantener la auditoría paso a paso
- traducir evidencias técnicas en una explicación clara
Cuando se usa bien, ChatGPT puede ser un excelente copiloto para soporte WordPress, sobre todo si el técnico ya tiene criterio para validar las evidencias reales en servidor y no depende ciegamente de una respuesta automática.
La clave está en usarlo como herramienta de razonamiento, no como sustituto del análisis.
Qué aprendí de esta auditoría
Este caso deja varias lecciones muy valiosas para cualquier profesional que mantenga sitios WordPress de clientes.
La primera es que 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.
La segunda es que el user meta puede ser mucho más determinante de lo que parece. En instalaciones con personalizaciones, plugins avanzados o paneles adaptados, el comportamiento del admin depende mucho de preferencias persistidas.
La tercera es que diagnosticar bien suele requerir menos acciones, no más. En vez de desactivar plugins al azar o modificar roles enteros, conviene validar una hipótesis puntual y aplicar una corrección mínima.
La cuarta es que trabajar por SSH con WP-CLI y un enfoque ordenado ahorra tiempo, reduce errores y permite documentar mejor cada paso.
Cómo prevenir que vuelva a ocurrir
Después de encontrar un caso así, lo recomendable no es quedarse solo con la solución puntual. También conviene revisar la causa estructural para evitar reincidencias.
Estas son algunas buenas prácticas:
Revisar dónde se usa esa preferencia en el código
Si existe una clave personalizada en user meta, lo ideal es buscar en el proyecto qué parte del código la crea, la lee o la aplica. Eso permite entender si el origen está en un plugin, un mu-plugin, un snippet o una funcionalidad del panel.
Validar valores permitidos
Si un sistema guarda preferencias de orden o filtros en metadatos del usuario, debería validar que esos valores sigan siendo válidos antes de aplicarlos en la consulta del admin.
Definir fallbacks seguros
Si el sistema recibe un criterio de orden desconocido, inválido o inconsistente, debería volver automáticamente al criterio por defecto, normalmente fecha descendente.
Evitar que estados antiguos rompan la experiencia actual
Cuando un sitio evoluciona, conviene contemplar que existan metadatos viejos guardados en usuarios. Un buen desarrollo no debería romperse por una preferencia heredada de semanas o meses atrás.
Conclusión
El problema no estaba en el rol del usuario, ni en la base de datos, ni en el contenido, ni en una supuesta desaparición de entradas. El problema estaba en una preferencia persistida del usuario que alteraba la forma en que el administrador listaba las publicaciones.
La auditoría permitió aislar la causa real, resolverla sin afectar el resto del sitio y confirmar que el contenido seguía intacto. También dejó una enseñanza importante: en WordPress, especialmente en instalaciones personalizadas, los metadatos de usuario pueden modificar mucho más de lo que parece.
Por eso, cuando un editor dice que “solo ve entradas viejas”, la respuesta correcta no es asumir que faltan notas o que hay un error general del sistema. A veces el problema está en cómo el panel interpreta una preferencia guardada desde hace tiempo.
Y ahí es donde una auditoría ordenada, apoyada por SSH, WP-CLI, PowerShell y una buena metodología, marca toda la diferencia.
