Você atualizou um plugin, corrigiu uma tradução ou mudou uma configuração, e a tela continua igual. Na maioria das vezes o problema não está no que você alterou, está no cache do GLPI, que segue entregando a versão anterior.
O GLPI não tem “um cache”. Tem três.
Esse é o primeiro ponto que costuma confundir. Quando alguém diz “limpa o cache do GLPI”, existem três coisas diferentes por trás, com finalidades distintas, e limpar a errada não resolve nada:
- Cache de opcode (PHP): guarda o bytecode dos arquivos
.phpjá compilados, para o PHP não reinterpretar o código a cada requisição. É a extensão Zend OPcache, do próprio PHP, não do GLPI. - Cache de dados de usuário: guarda dados da aplicação, como configurações e listas que o GLPI consulta o tempo todo. Internamente o GLPI chama esse contexto de
core, e ele pode ficar em disco ou em Redis/Memcached. - Cache de tradução: guarda os catálogos de idioma já processados, para o GLPI não ler os arquivos
.moa cada tela. É o responsável pelo sintoma mais frequente, o texto que continua no idioma antigo.
A regra prática: se o que mudou foi código, o suspeito é o opcode. Se foi texto de interface, é o de tradução. Se foi configuração ou dado, é o de dados de usuário.
Onde esses arquivos ficam
O cache em disco do GLPI vive dentro da pasta de arquivos da instalação, em files/_cache/. Lá dentro existe um diretório com um nome parecido com este:
files/_cache/11.0.7-49a93008-production/
app/
templates/
translations/Um alerta sobre essas três pastas: elas não correspondem um a um aos três caches da tela. A pasta translations guarda mesmo os catálogos de idioma, mas app é o cache interno do framework (contêiner de injeção de dependências, anotações), não o cache de dados de usuário. E se o ambiente estiver configurado para Redis ou Memcached, os dados de usuário não estão nesse diretório de forma alguma: eles vivem no serviço externo, e a pasta em disco continua existindo com o cache do framework. Procurar ali, nesse caso, leva ao lugar errado.
Repare no nome da pasta: ele carrega a versão do GLPI, um hash e o ambiente. Isso tem uma consequência prática pouco conhecida: ao atualizar o GLPI, o namespace muda e o cache antigo deixa de ser consultado sozinho. Por isso atualização de versão raramente sofre com cache velho, enquanto atualização de plugin, que não muda a versão do GLPI, sofre com frequência.
Atenção se você estiver no GLPI 10: essa organização em um único diretório versionado é da linha 11 e 12, que rodam sobre o Kernel do Symfony. No GLPI 10 o mesmo files/_cache tem outro desenho, com pastas separadas e sem o sufixo de ambiente:
files/_cache/core/
files/_cache/templates/
files/_cache/installer-10.0.24/
files/_cache/translations-10.0.24/Repare que ali apenas o instalador e as traduções levam a versão no nome, e as versões antigas se acumulam: é comum encontrar meia dúzia de translations-10.0.x de atualizações passadas. Os caminhos mudam, mas o raciocínio do artigo é o mesmo, e os botões da interface e o comando de console funcionam igual.
Plugins também usam esse diretório. Em uma instalação com o NexTool, por exemplo, convivem ali arquivos como nextool_boot_manifest.cache e entradas por módulo, cada um com sua própria estratégia de invalidação.
Disco ou Redis: onde o seu cache está
O cache de dados de usuário e o de tradução não ficam necessariamente em disco. O GLPI permite apontá-los para Redis ou Memcached, e a própria tela de Desempenho informa qual sistema está em uso, algo como “A extensão de cache redis está instalada” ou “Sistema de cache filesystem está em uso”.
Isso muda o diagnóstico em dois cenários comuns. Em instalação com mais de um servidor de aplicação atrás de um balanceador, cache em disco significa um cache por servidor: limpar em um nó não limpa nos outros, e o usuário vê o conteúdo antigo ou novo dependendo de onde a requisição caiu. Já com Redis compartilhado, uma limpeza vale para todos.
O outro cenário é o contêiner. Se o cache está em disco dentro do contêiner e não em um volume, recriar o contêiner limpa o cache junto, o que às vezes “resolve” o problema por acidente e esconde a causa real.
Para verificar ou mudar a configuração pela linha de comando:
php bin/console cache:configurePlugins também têm cache
Além dos três caches do núcleo, cada plugin pode manter o seu. O GLPI oferece um contexto próprio por plugin, e é por isso que o comando de limpeza aceita --context=plugin:nome_do_plugin.
Vale uma ressalva: esse contexto só existe se o plugin usar a API de cache do próprio GLPI. Muitos plugins mantêm cache próprio em arquivos soltos, fora desse mecanismo, e nesses casos o --context=plugin:nome não tem efeito algum sobre eles. Se depois de limpar tudo o comportamento persistir, procure por arquivos de cache do próprio plugin no diretório files/_cache.
Na prática, isso significa que um comportamento estranho depois de atualizar um plugin nem sempre se resolve limpando os caches do GLPI: pode ser preciso limpar o contexto daquele plugin especificamente. Plugins com muitos módulos costumam guardar manifestos de inicialização e esquemas em cache justamente para não recalcular tudo a cada requisição, e é esse arquivo que fica desatualizado depois de uma troca de versão.
Por que os botões de limpeza não aparecem
Aqui está o detalhe que faz muita gente concluir que a opção não existe na sua versão. A tela existe, os blocos aparecem, e mesmo assim não há botão nenhum para clicar.
O motivo é que os botões de limpeza são exibidos somente quando o usuário está em modo de depuração. No código do GLPI 11, cada um dos três blocos está dentro de uma condição que verifica o modo da sessão. Em modo normal, a tela mostra o diagnóstico, memória, taxa de acertos, extensão em uso, mas não oferece a ação.
Ou seja: não é permissão, não é versão, não é bug. É o modo da sessão.
Como ativar o modo de depuração
O modo fica no perfil do usuário, não em uma configuração global:
- Clique no seu nome, no canto superior direito, e abra as Preferências.
- Localize o campo Usar o GLPI no modo.
- Troque de Normal para Depuração e salve.
Duas observações importantes. A primeira: esse campo só aparece para quem tem perfil de administrador. Se você não o encontra, o caminho é pedir a um administrador do ambiente. A segunda: o modo de depuração faz o GLPI exibir informações técnicas em várias telas e adiciona sobrecarga ao processamento. Volte para Normal assim que terminar, especialmente em produção.
Limpando pela interface
Com o modo de depuração ativo, vá em Configuração > Geral e abra a aba Desempenho. Os três blocos agora aparecem com o botão de limpeza, cada um limpando apenas o seu cache.
Se após salvar a preferência os botões ainda não aparecerem, recarregue a página de configuração. A aba de desempenho carrega o conteúdo de forma assíncrona, e ela pode ter sido montada antes da troca de modo.
Limpe somente o bloco correspondente ao seu sintoma. Limpar os três “por garantia” é um hábito caro: derrubar o cache de opcode obriga o PHP a recompilar toda a aplicação nas próximas requisições, e em um ambiente com usuários ativos isso aparece como lentidão por alguns minutos.
Limpando pela linha de comando
Quem tem acesso ao servidor tem um caminho mais direto, que não exige modo de depuração nem passar pela interface. Na raiz da instalação do GLPI:
# limpa todos os contextos de cache
php bin/console cache:clearO comando aceita limitar o escopo, o que é preferível em produção pelo mesmo motivo da seção anterior:
# limpa apenas o cache de traduções, o caso mais comum
php bin/console cache:clear --context=translations
# limpa apenas os dados de usuário
php bin/console cache:clear --context=core
# limpa o cache de um plugin específico
php bin/console cache:clear --context=plugin:nome_do_pluginUm cuidado que evita dor de cabeça: execute o comando com o mesmo usuário que roda o servidor web (normalmente www-data ou apache). Rodar como root recria arquivos de cache pertencentes ao root, e o servidor web passa a não conseguir escrever neles, transformando um problema temporário em um permanente.
Vale notar que o cache:clear atua nos caches gerenciados pelo GLPI. O cache de opcode do PHP é da própria extensão, e é reiniciado ao recarregar o serviço PHP-FPM.
Qual limpar para cada sintoma
| O que está acontecendo | Cache a limpar |
|---|---|
| Texto continua no idioma antigo depois de atualizar um plugin | Tradução |
| Tradução nova que você adicionou não aparece | Tradução |
Alteração em arquivo .php não surte efeito | Opcode (PHP) |
| Configuração salva mas a tela mostra o valor anterior | Dados de usuário |
| Menu ou entrada de plugin que não some após desinstalar | Dados de usuário |
E no GLPI 12?
Comparando o código das duas versões, o método descrito aqui continua valendo por inteiro no GLPI 12: os mesmos três caches, os mesmos contextos core e translations, a mesma exigência de modo de depuração para os botões aparecerem e o mesmo comando de console. O diretório em disco segue o padrão da linha 11, com a versão no nome, como em files/_cache/12.0.0-rc1-08464f22-production/.
Duas diferenças merecem atenção de quem administra ambientes com muitos plugins.
A primeira é sobre memória. No GLPI 12, a limpeza do cache passou a pular a pré-compilação dos templates, com uma justificativa explícita no próprio código: são mais de 400 templates, e aquecer todos de uma vez estourava o limite padrão de memória do PHP. Em vez disso, cada template é compilado na primeira vez que a página é aberta. Na prática isso torna a limpeza mais leve e confiável, mas transfere o custo para quem acessar cada tela primeiro depois do clear.
A segunda é sobre plugins. No GLPI 12, ativar, desativar ou instalar qualquer plugin passou a zerar o cache de templates compilados inteiro, não só o daquele plugin. O próprio código registra a limitação, com uma anotação pedindo para no futuro separar o cache por namespace. O efeito colateral é que, em um ambiente com muitos módulos, mexer em um único plugin faz todos os templates serem recompilados sob demanda depois. Nada quebra, mas as primeiras aberturas de tela ficam mais lentas.
O caso que engana: metade da tela traduzida
Existe uma situação em que o cache de traduções engana até quem conhece bem o sistema. A tela abre com parte dos textos no idioma certo e parte no idioma original, misturados, às vezes em campos vizinhos. A conclusão natural é que a tradução do plugin está incompleta.
Quase sempre não está. Quando um plugin se atualiza sozinho e sobrescreve os próprios arquivos, ele precisa invalidar dois caches, não um: o de opcode, para o PHP passar a executar o código novo, e o de traduções, para o GLPI reler os catálogos. Invalidar apenas o primeiro produz exatamente esse resultado: as strings que já existiam antes continuam sendo servidas do cache, traduzidas, enquanto as strings novas daquela versão ainda não estão no catálogo em memória e aparecem no idioma de origem.
O que denuncia o caso é justamente a mistura. Tradução incompleta de verdade costuma deixar blocos inteiros no idioma original, seguindo a estrutura do arquivo de tradução. Cache desatualizado deixa o texto antigo traduzido e o novo não, sem lógica aparente, porque a divisão não é por tela: é por o que já estava em memória.
A confirmação é simples: limpe o cache de traduções e recarregue. Se a tela ficar consistente, era cache. Se a mistura permanecer, aí sim vale investigar o catálogo de idioma daquela versão.
Cuidados em produção
Três recomendações que valem para qualquer ambiente com usuários trabalhando:
- Prefira o cache específico ao invés de limpar tudo. O sintoma quase sempre aponta para um só.
- Evite o horário de pico ao limpar o opcode, e no GLPI 12 também ao limpar o cache geral, já que os templates passam a ser compilados no primeiro acesso de cada tela. A recompilação acontece sob demanda, então o custo cai justamente sobre quem está usando o sistema naquele momento.
- Não deixe o modo de depuração ligado. Além da sobrecarga, ele expõe detalhes técnicos do ambiente em tela.
Quando o problema não é cache
Se você limpou o cache correto e o comportamento continua, vale checar duas coisas antes de seguir investigando. Primeiro, se a alteração realmente chegou ao servidor: no caso de plugins, confirme a versão instalada, não a versão publicada. Foi exatamente esse o caso que originou este artigo, uma tradução que faltava porque o ambiente ainda estava na versão anterior do módulo. Segundo, se o seu idioma tem catálogo: se o plugin traduz para es_ES e o seu perfil usa uma variante regional sem catálogo próprio, o GLPI cai no texto original.
Revisado pela equipe NexTool Solutions.
