Actualizaste un plugin, corregiste una traducción o cambiaste una configuración, y la pantalla sigue igual. La mayoría de las veces el problema no está en lo que cambiaste, está en la caché del GLPI, que sigue entregando la versión anterior.
El GLPI no tiene "una caché". Tiene tres.
Este es el primer punto que suele confundir. Cuando alguien dice "limpia la caché del GLPI", hay tres cosas distintas detrás, con finalidades diferentes, y limpiar la equivocada no resuelve nada:
- Caché de opcode (PHP): guarda el bytecode de los archivos
.phpya compilados, para que PHP no reinterprete el código en cada petición. Es la extensión Zend OPcache, del propio PHP, no del GLPI. - Caché de datos de usuario: guarda datos de la aplicación, como configuraciones y listas que el GLPI consulta todo el tiempo. Internamente el GLPI llama a ese contexto
core, y puede estar en disco o en Redis/Memcached. - Caché de traducciones: guarda los catálogos de idioma ya procesados, para que el GLPI no lea los archivos
.moen cada pantalla. Es el responsable del síntoma más frecuente, el texto que sigue en el idioma anterior.
La regla práctica: si lo que cambió fue código, el sospechoso es el opcode. Si fue texto de interfaz, es el de traducciones. Si fue configuración o dato, es el de datos de usuario.
Dónde están esos archivos
La caché en disco del GLPI vive dentro de la carpeta de archivos de la instalación, en files/_cache/. Allí dentro existe un directorio con un nombre parecido a este:
files/_cache/11.0.7-49a93008-production/
app/
templates/
translations/Una advertencia sobre esas tres carpetas: no se corresponden una a una con las tres cachés de la pantalla. La carpeta translations sí guarda los catálogos de idioma, pero app es la caché interna del framework (contenedor de inyección de dependencias, anotaciones), no la caché de datos de usuario. Y si el entorno está configurado con Redis o Memcached, los datos de usuario no están en ese directorio en absoluto: viven en el servicio externo, y la carpeta en disco sigue existiendo con la caché del framework. Buscar ahí, en ese caso, lleva al lugar equivocado.
Fíjate en el nombre de la carpeta: lleva la versión del GLPI, un hash y el entorno. Esto tiene una consecuencia práctica poco conocida: al actualizar el GLPI, el espacio de nombres cambia y la caché antigua deja de consultarse sola. Por eso una actualización de versión rara vez sufre con caché vieja, mientras que actualizar un plugin, que no cambia la versión del GLPI, sufre con frecuencia.
Atención si estás en GLPI 10: esa organización en un único directorio versionado es de la línea 11 y 12, que corren sobre el Kernel de Symfony. En GLPI 10 el mismo files/_cache tiene otro diseño, con carpetas separadas y sin el sufijo de entorno:
files/_cache/core/
files/_cache/templates/
files/_cache/installer-10.0.24/
files/_cache/translations-10.0.24/Fíjate en que allí solo el instalador y las traducciones llevan la versión en el nombre, y las versiones antiguas se acumulan: es común encontrar media docena de translations-10.0.x de actualizaciones pasadas. Las rutas cambian, pero el razonamiento del artículo es el mismo, y los botones de la interfaz y el comando de consola funcionan igual.
Los plugins también usan ese directorio. En una instalación con el NexTool, por ejemplo, conviven allí archivos como nextool_boot_manifest.cache y entradas por módulo, cada uno con su propia estrategia de invalidación.
Disco o Redis: dónde está tu caché
La caché de datos de usuario y la de traducciones no están necesariamente en disco. El GLPI permite apuntarlas a Redis o Memcached, y la propia pantalla de Rendimiento informa qué sistema está en uso, algo como "La extensión de caché redis está instalada" o "Sistema de caché filesystem está en uso".
Esto cambia el diagnóstico en dos escenarios comunes. En una instalación con más de un servidor de aplicación detrás de un balanceador, caché en disco significa una caché por servidor: limpiar en un nodo no limpia en los otros, y el usuario ve el contenido antiguo o nuevo según dónde cayó la petición. Con Redis compartido, en cambio, una limpieza vale para todos.
El otro escenario es el contenedor. Si la caché está en disco dentro del contenedor y no en un volumen, recrear el contenedor limpia la caché de paso, lo que a veces "resuelve" el problema por accidente y esconde la causa real.
Para verificar o cambiar la configuración por línea de comandos:
php bin/console cache:configureLos plugins también tienen caché
Además de las tres cachés del núcleo, cada plugin puede mantener la suya. El GLPI ofrece un contexto propio por plugin, y por eso el comando de limpieza acepta --context=plugin:nombre_del_plugin.
Vale una advertencia: ese contexto solo existe si el plugin usa la API de caché del propio GLPI. Muchos plugins mantienen caché propia en archivos sueltos, fuera de ese mecanismo, y en esos casos el --context=plugin:nombre no tiene ningún efecto sobre ellos. Si después de limpiar todo el comportamiento persiste, busca archivos de caché del propio plugin en el directorio files/_cache.
En la práctica, esto significa que un comportamiento extraño después de actualizar un plugin no siempre se resuelve limpiando las cachés del GLPI: puede ser necesario limpiar el contexto de ese plugin específicamente. Los plugins con muchos módulos suelen guardar manifiestos de inicialización y esquemas en caché justamente para no recalcular todo en cada petición, y es ese archivo el que queda desactualizado después de un cambio de versión.
Por qué no aparecen los botones de limpieza
Aquí está el detalle que hace que mucha gente concluya que la opción no existe en su versión. La pantalla existe, los bloques aparecen, y aun así no hay ningún botón para hacer clic.
El motivo es que los botones de limpieza se muestran solo cuando el usuario está en modo de depuración. En el código del GLPI 11, cada uno de los tres bloques está dentro de una condición que verifica el modo de la sesión. En modo normal, la pantalla muestra el diagnóstico, memoria, tasa de aciertos, extensión en uso, pero no ofrece la acción.
Es decir: no es permiso, no es versión, no es un fallo. Es el modo de la sesión.
Cómo activar el modo de depuración
El modo está en el perfil del usuario, no en una configuración global:
- Haz clic en tu nombre, arriba a la derecha, y abre las Preferencias.
- Localiza el campo Utilizar GLPI en modo.
- Cambia de Normal a Depuración y guarda.
Dos observaciones importantes. La primera: ese campo solo aparece para quien tiene perfil de administrador. Si no lo encuentras, el camino es pedirlo a un administrador del entorno. La segunda: el modo de depuración hace que el GLPI muestre información técnica en varias pantallas y añade sobrecarga al procesamiento. Vuelve a Normal en cuanto termines, especialmente en producción.
Limpiando desde la interfaz
Con el modo de depuración activo, ve a Configuración > General y abre la pestaña Rendimiento. Los tres bloques aparecen ahora con el botón de limpieza, cada uno limpiando solo su caché.
Si después de guardar la preferencia los botones todavía no aparecen, recarga la página de configuración. La pestaña de rendimiento carga el contenido de forma asíncrona, y puede haberse montado antes del cambio de modo.
Limpia solo el bloque correspondiente a tu síntoma. Limpiar los tres "por si acaso" es un hábito caro: tirar la caché de opcode obliga a PHP a recompilar toda la aplicación en las siguientes peticiones, y en un entorno con usuarios activos eso aparece como lentitud durante algunos minutos.
Limpiando por línea de comandos
Quien tiene acceso al servidor cuenta con un camino más directo, que no exige modo de depuración ni pasar por la interfaz. En la raíz de la instalación del GLPI:
# limpia todos los contextos de caché
php bin/console cache:clearEl comando acepta limitar el alcance, lo que es preferible en producción por el mismo motivo de la sección anterior:
# limpia solo la caché de traducciones, el caso más común
php bin/console cache:clear --context=translations
# limpia solo los datos de usuario
php bin/console cache:clear --context=core
# limpia la caché de un plugin específico
php bin/console cache:clear --context=plugin:nombre_del_pluginUn cuidado que evita dolores de cabeza: ejecuta el comando con el mismo usuario que corre el servidor web (normalmente www-data o apache). Ejecutarlo como root recrea archivos de caché pertenecientes a root, y el servidor web pasa a no poder escribir en ellos, transformando un problema temporal en uno permanente.
Vale notar que el cache:clear actúa sobre las cachés gestionadas por el GLPI. La caché de opcode de PHP es de la propia extensión, y se reinicia al recargar el servicio PHP-FPM.
Cuál limpiar para cada síntoma
| Qué está pasando | Caché a limpiar |
|---|---|
| El texto sigue en el idioma anterior después de actualizar un plugin | Traducciones |
| Una traducción nueva que agregaste no aparece | Traducciones |
Un cambio en un archivo .php no surte efecto | Opcode (PHP) |
| Configuración guardada pero la pantalla muestra el valor anterior | Datos de usuario |
| Menú o entrada de plugin que no desaparece tras desinstalar | Datos de usuario |
¿Y en GLPI 12?
Comparando el código de las dos versiones, el método descrito aquí sigue siendo válido por completo en GLPI 12: las mismas tres cachés, los mismos contextos core y translations, la misma exigencia de modo de depuración para que aparezcan los botones y el mismo comando de consola. El directorio en disco sigue el patrón de la línea 11, con la versión en el nombre, como en files/_cache/12.0.0-rc1-08464f22-production/.
Dos diferencias merecen la atención de quien administra entornos con muchos plugins.
La primera es sobre memoria. En GLPI 12, la limpieza de caché pasó a saltarse la precompilación de las plantillas, con una justificación explícita en el propio código: son más de 400 plantillas, y calentarlas todas de una vez superaba el límite de memoria por defecto de PHP. En su lugar, cada plantilla se compila la primera vez que se abre la página. En la práctica esto hace la limpieza más liviana y confiable, pero transfiere el costo a quien acceda a cada pantalla primero después del clear.
La segunda es sobre plugins. En GLPI 12, activar, desactivar o instalar cualquier plugin pasó a vaciar la caché de plantillas compiladas por completo, no solo la de ese plugin. El propio código registra la limitación, con una anotación pidiendo separar la caché por espacio de nombres en el futuro. El efecto colateral es que, en un entorno con muchos módulos, tocar un solo plugin hace que todas las plantillas se recompilen bajo demanda después. Nada se rompe, pero las primeras aperturas de pantalla quedan más lentas.
El caso que engaña: media pantalla traducida
Existe una situación en la que la caché de traducciones engaña incluso a quien conoce bien el sistema. La pantalla abre con parte de los textos en el idioma correcto y parte en el idioma original, mezclados, a veces en campos vecinos. La conclusión natural es que la traducción del plugin está incompleta.
Casi siempre no lo está. Cuando un plugin se actualiza solo y sobrescribe sus propios archivos, necesita invalidar dos cachés, no una: la de opcode, para que PHP pase a ejecutar el código nuevo, y la de traducciones, para que el GLPI relea los catálogos. Invalidar solo la primera produce exactamente ese resultado: las cadenas que ya existían antes se siguen sirviendo desde la caché, traducidas, mientras que las cadenas nuevas de esa versión todavía no están en el catálogo en memoria y aparecen en el idioma de origen.
Lo que delata el caso es justamente la mezcla. Una traducción realmente incompleta suele dejar bloques enteros en el idioma original, siguiendo la estructura del archivo de traducción. Una caché desactualizada deja el texto antiguo traducido y el nuevo no, sin lógica aparente, porque la división no es por pantalla: es por lo que ya estaba en memoria.
La confirmación es simple: limpia la caché de traducciones y recarga. Si la pantalla queda consistente, era caché. Si la mezcla permanece, ahí sí vale investigar el catálogo de idioma de esa versión.
Cuidados en producción
Tres recomendaciones que valen para cualquier entorno con usuarios trabajando:
- Prefiere la caché específica en lugar de limpiar todo. El síntoma casi siempre apunta a una sola.
- Evita el horario pico al limpiar el opcode, y en GLPI 12 también al limpiar la caché general, ya que las plantillas pasan a compilarse en el primer acceso a cada pantalla. La recompilación ocurre bajo demanda, así que el costo recae justamente sobre quien está usando el sistema en ese momento.
- No dejes el modo de depuración encendido. Además de la sobrecarga, expone detalles técnicos del entorno en pantalla.
Cuando el problema no es la caché
Si limpiaste la caché correcta y el comportamiento continúa, vale revisar dos cosas antes de seguir investigando. Primero, si el cambio realmente llegó al servidor: en el caso de los plugins, confirma la versión instalada, no la versión publicada. Segundo, si tu idioma tiene catálogo: si el plugin traduce a es_ES y tu perfil usa una variante regional sin catálogo propio, el GLPI cae al texto original.
Revisado por el equipo NexTool Solutions.
