Betrifft JTL-Shop 5 mit dem Plugin EU Cookie in einer Version vor 2.6.1.
Kurzfassung
Es gibt zwei Situationen. In beiden ist der erste Schritt derselbe: den Objektcache Deines Shops leeren:
Fall A: Du hast das Update noch nicht gemacht, aber im Backend funktioniert etwas nicht. Zum Beispiel lässt sich die Seite System > Cache nicht mehr öffnen.
- Objektcache leeren, siehe Abschnitt 3.
- Danach das Plugin-Update auf 2.6.1 oder neuer installieren.
Fall B: Du hast auf "Aktualisieren" geklickt und das Update ist abgebrochen.
- Objektcache leeren, siehe Abschnitt 3.
- Noch einmal auf "Aktualisieren" klicken. Jetzt läuft es durch.
Wichtig ist die Reihenfolge: erst den Cache leeren, dann das Update. Danach ist das Thema erledigt, ab Version 2.6.1 kann das dann nicht mehr auftreten.
1. Fall A: Das Update wurde noch nicht durchgeführt
Daran erkennst Du es:
- Die Backend-Seite System > Cache lässt sich nicht öffnen oder lädt sehr lange.
- Die Systemdiagnose bricht ab.
- Die Cache-Seite im Plugin-Dashboard läuft in einen Fehler.
- Im Fehlerlog steht "Allowed memory size of ... bytes exhausted".
- Dein Frontend läuft dabei ganz normal weiter. Betroffen sind nur einzelne Seiten im Backend.
So gehst Du vor:
- Objektcache leeren, siehe Abschnitt 3.
- Danach das Plugin-Update installieren.
Leere den Cache bitte vor dem Update. Sonst bricht auch das Update ab und Du bist in Fall B.
2. Fall B: Das Update ist abgebrochen
Daran erkennst Du es:
- Du hast im Plugin-Manager oder im Lizenzmanager auf "Aktualisieren" geklickt.
- Die Seite bleibt weiß, lädt nicht fertig oder zeigt einen Speicherfehler.
- Das Plugin steht danach weiterhin auf der alten Versionsnummer.
Ist mein Shop jetzt kaputt? Nein. Dein Frontend läuft normal weiter, es gibt keinen Wartungsmodus und keine halb eingespielte Datenbank. Beim Abbruch wurde an Deinen Daten noch nichts verändert. Auf dem Server liegen zwar schon die neuen Plugin-Dateien, in der Datenbank steht aber noch die alte Versionsnummer. Das gleicht der nächste erfolgreiche Update-Durchlauf von selbst wieder an.
Reicht es, einfach noch einmal auf "Aktualisieren" zu klicken? Nicht ohne den Cache vorher zu leeren. Der Shop räumt beim Update als allererstes den Cache auf, und genau daran scheitert er. Der Versuch bricht deshalb jedes Mal an derselben Stelle ab.
So gehst Du vor:
- Objektcache leeren, siehe Abschnitt 3.
- Im Plugin-Manager erneut auf "Aktualisieren" klicken. Das Update läuft dann durch.
3. Objektcache leeren
Ein Weg genügt. Nimm den, der zu Deinem Zugang passt.
Weg A: SSH-Zugang zum Shop-Verzeichnis (empfohlen)
Führe im Shop-Wurzelverzeichnis aus:
php cli cache:clear
Der Befehl leert den kompletten Objektcache auf einen Schlag und braucht dabei kaum Speicher. Er funktioniert deshalb auch dann, wenn im Backend nichts mehr geht.
Wenn Du zusätzlich den Dateicache nutzt, danach noch:
php cli cache:file:delete
Weg B: Nur Dateicache im Einsatz, kein SSH
Lösche per FTP oder über den Dateimanager Deines Hosters den Inhalt des Verzeichnisses [Shopverzeichnis]/templates_c/filecache. Das Verzeichnis selbst bleibt bestehen, der Shop füllt es von allein wieder.
Bei sehr vielen Dateien kann schon das Öffnen des Ordners im FTP-Programm lange dauern. Mit SSH geht es deutlich schneller, dort genügt im selben Verzeichnis:
find . -maxdepth 1 -type f -delete
Weg C: Direkter Redis-Zugang
Wähle in redis-cli die vom Shop genutzte Datenbank aus und leere sie. Die Nummer findest Du im Backend unter System > Cache > Einstellungen.
SELECT <nummer> FLUSHDB
Nimm kein FLUSHALL, wenn auf derselben Redis-Instanz noch andere Datenbanken liegen, zum Beispiel für PHP-Sessions.
Weg D: Über das Backend, mit kurzzeitig erhöhtem Speicherlimit
Der Button "Gesamten Objekt-Cache leeren" liegt ausgerechnet auf der Seite, die sich nicht mehr öffnen lässt. Mit mehr Arbeitsspeicher lässt sie sich meist doch noch einmal aufrufen:
- PHP-Speicherlimit vorübergehend erhöhen, zum Beispiel auf 2048M. Je nach Hoster geht das im Kundenpanel oder über memory_limit in der .user.ini bzw. php.ini.
- Im Backend System > Cache öffnen.
- Unten auf "Gesamten Objekt-Cache leeren" klicken.
- Speicherlimit wieder auf den alten Wert zurücksetzen.
Setz hier bitte nicht nur den Haken bei "Plugins" und leere diese eine Gruppe. Genau das ist der Vorgang, der den Fehler auslöst. Nimm den Button für den gesamten Objekt-Cache.
Lädt die Seite auch mit mehr Speicher nicht, hilft dieser Weg nicht weiter. Nimm dann Weg A, C oder E.
Weg E: Kein SSH-, FTP- oder Redis-Zugang
Öffne ein Ticket bei Deinem Hoster. Du kannst den folgenden Text verwenden:
"Bitte den Objektcache des JTL-Shops leeren. Bei Redis: FLUSHDB auf der vom Shop genutzten Datenbank, nicht FLUSHALL. Alternativ ein Neustart des Redis-Dienstes, sofern keine Redis-Persistenz aktiv ist."
4. Nach dem Cache-Leeren
Der Shop ist für kurze Zeit langsamer, weil der Cache neu aufgebaut wird. Das ist normal und je nach Shopgröße nach wenigen Minuten vorbei.
Installier anschließend das Plugin-Update ganz normal über den Plugin-Manager oder den Lizenzmanager. Das Update räumt den Cache noch einmal selbst auf, das klappt auch bei knappem Speicher.
Prüf danach, ob sich System > Cache im Backend wieder normal öffnet. Wenn ja, ist die Sache erledigt.
5. Sonderfall: Das Plugin erscheint zweimal in der Übersicht
Stehen nach einem abgebrochenen Update-Versuch zwei Einträge für EU Cookie im Plugin-Manager, einer davon als fehlerhaft markiert oder mit dem Hinweis, dass das Verzeichnis fehlt:
- Objektcache leeren, siehe Abschnitt 3.
- Den fehlerhaften Eintrag über die Plugin-Verwaltung deinstallieren. Der intakte Eintrag mit gültigem Verzeichnis bleibt bestehen.
- Danach das Update erneut ausführen.
Deine Plugin-Einstellungen und die gespeicherten Consent-Daten hängen am intakten Eintrag und bleiben erhalten.
Wenn Du Dir nicht sicher bist, welcher der beiden Einträge der richtige ist, meld Dich mit einem Screenshot der Plugin-Übersicht bei unserem Support, bevor Du etwas deinstallierst.
6. Technischer Hintergrund
Das Plugin hat seine Cache-Einträge mit dem shopweiten Cache-Tag "plgn" versehen statt mit einem plugin-eigenen Tag. Zusätzlich legte der Normalisierungs-Cache der Quellen-Erkennung pro erkannter Quelle einen eigenen Eintrag an. Auf Shops mit vielen wechselnden Inline-Skripten, was bei hohem Bot-Traffic typisch ist, wuchs der Tag-Index dadurch unbegrenzt.
Der JTL-Shop liest bei jedem Tag-Flush alle Mitglieder eines Tag-Index in den PHP-Speicher, bevor er sie löscht. Bei mehreren Millionen Einträgen überschreitet allein dieser Schritt das Speicherlimit. Betroffen sind deshalb genau die Stellen, die einen solchen Flush auslösen: die Cache-Seite im Backend, die Systemdiagnose und das Plugin-Update.
Ab Version 2.6.1 gilt:
- Der Normalisierungs-Cache legt garantiert nur noch 16 Cache-Einträge an, unabhängig von der Anzahl der Seitenaufrufe.
- Die Einträge tragen ein plugin-eigenes Tag, nicht mehr das shopweite "plgn".
- Das Plugin löst keine shopweiten Tag-Flushes mehr aus.
- Ein einmaliger Aufräumschritt beim Update setzt einen bereits gewachsenen Index zurück.
Tags: