Sie haben ein Plugin aktualisiert, eine Übersetzung korrigiert oder eine Einstellung geändert, und die Oberfläche sieht unverändert aus. In den meisten Fällen liegt die Ursache nicht in dem, was Sie geändert haben, sondern am Cache von GLPI, der weiterhin die vorherige Version ausliefert.
GLPI hat nicht „einen Cache“. Es hat drei.
Das ist der erste Punkt, der häufig für Verwirrung sorgt. Wenn jemand sagt „leer mal den GLPI-Cache“, stecken dahinter drei verschiedene Dinge mit unterschiedlichen Zwecken, und den falschen zu leeren bringt gar nichts:
- Opcode-Cache (PHP): speichert den Bytecode der bereits kompilierten
.php-Dateien, damit PHP den Code nicht bei jeder Anfrage neu interpretieren muss. Es handelt sich um die Erweiterung Zend OPcache von PHP selbst, nicht von GLPI. - Benutzerdaten-Cache: speichert Anwendungsdaten wie Einstellungen und Listen, die GLPI ständig abfragt. Intern nennt GLPI diesen Kontext
core, und er kann auf der Festplatte oder in Redis/Memcached liegen. - Übersetzungs-Cache: speichert die bereits verarbeiteten Sprachkataloge, damit GLPI nicht bei jeder Seite die
.mo-Dateien lesen muss. Er ist für den häufigsten Fehler verantwortlich: Text, der weiterhin in der alten Sprache erscheint.
Die Faustregel: Wenn sich Code geändert hat, ist der Opcode-Cache verdächtig. Wenn es Oberflächentext war, der Übersetzungs-Cache. Wenn es eine Einstellung oder Daten waren, der Benutzerdaten-Cache.
Wo diese Dateien liegen
Der Festplatten-Cache von GLPI befindet sich im Dateiordner der Installation, unter files/_cache/. Darin gibt es ein Verzeichnis mit einem Namen ähnlich wie diesem:
files/_cache/11.0.7-49a93008-production/
app/
templates/
translations/Ein Hinweis zu diesen drei Ordnern: Sie entsprechen nicht eins zu eins den drei Caches der Oberfläche. Der Ordner translations enthält tatsächlich die Sprachkataloge, aber app ist der interne Cache des Frameworks (Dependency-Injection-Container, Annotationen), nicht der Benutzerdaten-Cache. Und wenn die Umgebung für Redis oder Memcached konfiguriert ist, liegen die Benutzerdaten überhaupt nicht in diesem Verzeichnis: Sie befinden sich im externen Dienst, und der Ordner auf der Festplatte existiert weiterhin mit dem Framework-Cache. Wer dort sucht, landet in diesem Fall an der falschen Stelle.
Beachten Sie den Ordnernamen: Er enthält die GLPI-Version, einen Hash und die Umgebung. Dies hat eine wenig bekannte praktische Folge: Beim Update von GLPI ändert sich der Namespace, und der alte Cache wird automatisch nicht mehr abgefragt. Deshalb leiden Versions-Updates selten unter veraltetem Cache, während Updates von Plugins, die die GLPI-Version nicht ändern, häufig darunter leiden.
Achtung, wenn Sie GLPI 10 verwenden: Diese Organisation in einem einzigen versionierten Verzeichnis gehört zu den Versionslinien 11 und 12, die auf dem Symfony-Kernel laufen. In GLPI 10 hat derselbe Ordner files/_cache einen anderen Aufbau, mit getrennten Ordnern und ohne Umgebungssuffix:
files/_cache/core/
files/_cache/templates/
files/_cache/installer-10.0.24/
files/_cache/translations-10.0.24/Beachten Sie, dass dort nur der Installer und die Übersetzungen die Version im Namen tragen und sich alte Versionen ansammeln: Es ist üblich, ein halbes Dutzend translations-10.0.x aus früheren Updates zu finden. Die Pfade ändern sich, aber die Überlegungen dieses Artikels bleiben dieselben, und die Schaltflächen der Oberfläche sowie der Konsolenbefehl funktionieren genauso.
Auch Plugins nutzen dieses Verzeichnis. In einer Installation mit NexTool zum Beispiel liegen dort Dateien wie nextool_boot_manifest.cache und Einträge pro Modul, jeweils mit eigener Invalidierungsstrategie.
Festplatte oder Redis: Wo Ihr Cache liegt
Der Benutzerdaten-Cache und der Übersetzungs-Cache liegen nicht zwingend auf der Festplatte. GLPI erlaubt es, sie auf Redis oder Memcached zu verweisen, und die Seite Leistung selbst zeigt an, welches System verwendet wird, etwa „Die Cache-Erweiterung redis ist installiert“ oder „Cache-System filesystem wird verwendet“.
Das verändert die Diagnose in zwei häufigen Szenarien. In einer Installation mit mehreren Anwendungsservern hinter einem Load Balancer bedeutet Festplatten-Cache einen Cache pro Server: Wer auf einem Knoten leert, leert die anderen nicht, und der Benutzer sieht den alten oder neuen Inhalt, je nachdem, wo die Anfrage gelandet ist. Mit einem gemeinsam genutzten Redis hingegen gilt eine Bereinigung für alle.
Das andere Szenario ist der Container. Liegt der Cache auf der Festplatte innerhalb des Containers und nicht in einem Volume, leert ein Neuerstellen des Containers den Cache mit, was das Problem manchmal zufällig „löst“ und die eigentliche Ursache verdeckt.
Um die Konfiguration über die Kommandozeile zu prüfen oder zu ändern:
php bin/console cache:configureAuch Plugins haben einen Cache
Neben den drei Caches des Kerns kann jedes Plugin einen eigenen führen. GLPI bietet einen eigenen Kontext pro Plugin, und deshalb akzeptiert der Bereinigungsbefehl --context=plugin:nome_do_plugin.
Eine Einschränkung: Dieser Kontext existiert nur, wenn das Plugin die Cache-API von GLPI selbst verwendet. Viele Plugins führen einen eigenen Cache in losen Dateien außerhalb dieses Mechanismus, und in diesen Fällen hat --context=plugin:nome keinerlei Wirkung auf sie. Wenn dieses Verhalten nach dem Leeren aller Caches bestehen bleibt, suchen Sie im Verzeichnis files/_cache nach Cache-Dateien des Plugins selbst.
In der Praxis bedeutet das, dass sich seltsames Verhalten nach einem Plugin-Update nicht immer durch Leeren der GLPI-Caches beheben lässt: Möglicherweise muss gezielt der Kontext dieses Plugins geleert werden. Plugins mit vielen Modulen speichern Initialisierungsmanifeste und Schemata häufig im Cache, gerade um nicht bei jeder Anfrage alles neu zu berechnen, und genau diese Datei ist nach einem Versionswechsel veraltet.
Warum die Schaltflächen zum Leeren nicht erscheinen
Hier liegt das Detail, das viele zu dem Schluss führt, die Option existiere in ihrer Version nicht. Die Seite existiert, die Blöcke werden angezeigt, und trotzdem gibt es keine Schaltfläche zum Anklicken.
Der Grund: Die Schaltflächen zum Leeren werden nur angezeigt, wenn sich der Benutzer im Debug-Modus befindet. Im Code von GLPI 11 steht jeder der drei Blöcke innerhalb einer Bedingung, die den Modus der Sitzung prüft. Im normalen Modus zeigt die Seite die Diagnose an, also Speicher, Trefferquote und verwendete Erweiterung, bietet aber keine Aktion an.
Anders gesagt: Es ist keine Berechtigung, keine Version und kein Bug. Es ist der Modus der Sitzung.
So aktivieren Sie den Debug-Modus
Der Modus wird im Benutzerprofil festgelegt, nicht in einer globalen Einstellung:
- Klicken Sie oben rechts auf Ihren Namen und öffnen Sie die Einstellungen.
- Suchen Sie das Feld GLPI verwenden im Modus.
- Wechseln Sie von Normal zu Debug und speichern Sie.
Zwei wichtige Hinweise. Erstens: Dieses Feld erscheint nur für Benutzer mit Administratorprofil. Wenn Sie es nicht finden, wenden Sie sich an einen Administrator der Umgebung. Zweitens: Im Debug-Modus zeigt GLPI auf vielen Seiten technische Informationen an und erzeugt zusätzliche Verarbeitungslast. Stellen Sie wieder auf Normal um, sobald Sie fertig sind, insbesondere in der Produktion.
Leeren über die Oberfläche
Bei aktivem Debug-Modus gehen Sie zu Einrichtung > Allgemein und öffnen den Reiter Leistung. Die drei Blöcke erscheinen nun mit der Schaltfläche zum Leeren, und jeder leert nur seinen eigenen Cache.
Wenn die Schaltflächen nach dem Speichern der Einstellung immer noch nicht erscheinen, laden Sie die Konfigurationsseite neu. Der Reiter Leistung lädt seinen Inhalt asynchron und wurde möglicherweise vor dem Moduswechsel aufgebaut.
Leeren Sie nur den Block, der zu Ihrem Symptom passt. Alle drei „sicherheitshalber“ zu leeren ist eine teure Gewohnheit: Ein Verwerfen des Opcode-Caches zwingt PHP, bei den nächsten Anfragen die gesamte Anwendung neu zu kompilieren, und in einer Umgebung mit aktiven Benutzern zeigt sich dies für einige Minuten als Verlangsamung.
Leeren über die Kommandozeile
Wer Zugriff auf den Server hat, hat einen direkteren Weg, der weder den Debug-Modus noch die Oberfläche erfordert. Im Stammverzeichnis der GLPI-Installation:
# clears every cache context
php bin/console cache:clearDer Befehl erlaubt es, den Umfang einzuschränken, was in der Produktion aus demselben Grund wie im vorherigen Abschnitt vorzuziehen ist:
# clears only the translation cache, the most common case
php bin/console cache:clear --context=translations
# clears only the user data
php bin/console cache:clear --context=core
# clears a specific plugin's cache
php bin/console cache:clear --context=plugin:plugin_nameEine Vorsichtsmaßnahme, die Kopfschmerzen erspart: Führen Sie den Befehl mit demselben Benutzer aus, unter dem der Webserver läuft (normalerweise www-data oder apache). Als root ausgeführt, werden Cache-Dateien neu erstellt, die root gehören, und der Webserver kann nicht mehr in sie schreiben, wodurch aus einem vorübergehenden Problem ein dauerhaftes wird.
Beachten Sie, dass cache:clear auf die von GLPI verwalteten Caches wirkt. Der Opcode-Cache von PHP gehört zur Erweiterung selbst und wird beim Neuladen des PHP-FPM-Dienstes zurückgesetzt.
Welchen Cache Sie bei welchem Symptom leeren
| Was passiert | Zu leerender Cache |
|---|---|
| Text erscheint nach einem Plugin-Update weiterhin in der alten Sprache | Übersetzung |
| Eine neu hinzugefügte Übersetzung erscheint nicht | Übersetzung |
Änderung an einer .php-Datei zeigt keine Wirkung | Opcode (PHP) |
| Einstellung gespeichert, aber die Seite zeigt den vorherigen Wert | Benutzerdaten |
| Menü oder Plugin-Eintrag verschwindet nach der Deinstallation nicht | Benutzerdaten |
Und in GLPI 12?
Ein Vergleich des Codes beider Versionen zeigt, dass die hier beschriebene Methode in GLPI 12 vollständig gültig bleibt: dieselben drei Caches, dieselben Kontexte core und translations, dieselbe Voraussetzung des Debug-Modus für die Schaltflächen und derselbe Konsolenbefehl. Auch das Verzeichnis auf der Festplatte folgt dem Muster der Versionslinie 11, mit der Version im Namen, wie in files/_cache/12.0.0-rc1-08464f22-production/.
Zwei Unterschiede verdienen die Aufmerksamkeit aller, die Umgebungen mit vielen Plugins verwalten.
Der erste betrifft den Speicher. In GLPI 12 überspringt die Cache-Bereinigung die Vorkompilierung der Templates, mit einer ausdrücklichen Begründung im Code selbst: Es sind über 400 Templates, und alle auf einmal vorzuwärmen sprengte die Standard-Speichergrenze von PHP. Stattdessen wird jedes Template beim ersten Öffnen der Seite kompiliert. In der Praxis macht dies die Bereinigung leichter und zuverlässiger, verlagert die Kosten aber auf denjenigen, der nach dem Leeren als Erster eine Seite aufruft.
Der zweite betrifft Plugins. In GLPI 12 setzt jedes Aktivieren, Deaktivieren oder Installieren eines beliebigen Plugins den gesamten Cache der kompilierten Templates zurück, nicht nur den dieses Plugins. Der Code selbst vermerkt diese Einschränkung, mit einer Anmerkung, den Cache künftig nach Namespace zu trennen. Der Nebeneffekt: In einer Umgebung mit vielen Modulen führt eine Änderung an einem einzigen Plugin dazu, dass danach alle Templates bei Bedarf neu kompiliert werden. Nichts geht kaputt, aber die ersten Seitenaufrufe werden langsamer.
Der trügerische Fall: halb übersetzte Seite
Es gibt eine Situation, in der der Übersetzungs-Cache selbst Kenner des Systems täuscht. Die Seite öffnet sich mit einem Teil der Texte in der richtigen Sprache und einem Teil in der Originalsprache, gemischt, manchmal in benachbarten Feldern. Die naheliegende Schlussfolgerung ist, dass die Übersetzung des Plugins unvollständig sei.
Fast immer ist sie das nicht. Wenn sich ein Plugin selbst aktualisiert und seine eigenen Dateien überschreibt, muss es zwei Caches invalidieren, nicht einen: den Opcode-Cache, damit PHP den neuen Code ausführt, und den Übersetzungs-Cache, damit GLPI die Kataloge neu einliest. Wird nur der erste invalidiert, entsteht genau dieses Ergebnis: Die bereits vorhandenen Strings werden weiterhin übersetzt aus dem Cache ausgeliefert, während die neuen Strings dieser Version noch nicht im Katalog im Speicher sind und in der Ausgangssprache erscheinen.
Was den Fall verrät, ist gerade die Mischung. Eine tatsächlich unvollständige Übersetzung lässt meist ganze Blöcke in der Originalsprache, entsprechend der Struktur der Übersetzungsdatei. Ein veralteter Cache lässt den alten Text übersetzt und den neuen nicht, ohne erkennbare Logik, denn die Trennung erfolgt nicht nach Seite, sondern danach, was bereits im Speicher war.
Die Bestätigung ist einfach: Leeren Sie den Übersetzungs-Cache und laden Sie neu. Wird die Seite konsistent, war es der Cache. Bleibt die Mischung bestehen, lohnt es sich, den Sprachkatalog dieser Version zu untersuchen.
Vorsicht in der Produktion
Drei Empfehlungen, die für jede Umgebung mit arbeitenden Benutzern gelten:
- Bevorzugen Sie den spezifischen Cache, statt alles zu leeren. Ihr Symptom weist fast immer auf einen einzigen hin.
- Meiden Sie Spitzenzeiten beim Leeren des Opcode-Caches und in GLPI 12 auch beim Leeren des allgemeinen Caches, da die Templates dann beim ersten Aufruf jeder Seite kompiliert werden. Die Neukompilierung erfolgt bei Bedarf, sodass die Kosten genau auf diejenigen fallen, die das System in diesem Moment nutzen.
- Lassen Sie den Debug-Modus nicht eingeschaltet. Neben der zusätzlichen Last legt er technische Details der Umgebung auf dem Bildschirm offen.
Wenn das Problem nicht der Cache ist
Wenn Sie den richtigen Cache geleert haben und das Verhalten anhält, lohnt es sich, zwei Dinge zu prüfen, bevor Sie weiter untersuchen. Erstens, ob die Änderung tatsächlich auf dem Server angekommen ist: Bei Plugins prüfen Sie die installierte Version, nicht die veröffentlichte. Genau dieser Fall war der Anlass für diesen Artikel: eine fehlende Übersetzung, weil die Umgebung noch auf der vorherigen Version des Moduls lief. Zweitens, ob Ihre Sprache einen Katalog hat: Wenn das Plugin nach es_ES übersetzt und Ihr Profil eine regionale Variante ohne eigenen Katalog verwendet, fällt GLPI auf den Originaltext zurück.
Geprüft vom Team der NexTool Solutions.
