Cache fehlerhaft nach Update von 2.8.1 auf 2.8.2

Hatte erst vor wenigen Tagen eine Website mit V.2.8.1 online gebracht und alles war fein. Nun hab ich sie eben mal schnell noch auf die 2.8.2 upgedatet (nur die localconfig.php und meine Templates beibehalten) und wollte heiern gehen, da fällt mir doch glatt auf, dass genau eine Seite nach ihrem zweiten Aufruf nichts mehr ausspukt. Gähnende Leere, Nada, Null... weißes Blatt Papier sozusagen!
Also ich wiederhole: erster Seitenaufruf, alles super. Cache wird generiert, hab ihn mir mit einem Editor angeschaut, sieht auch gut aus. Aber sobald der nächste Aufruf dieser Seite getätigt wird -> NICHTS. Lösch ich den Cache, dann funktioniert der Seitenaufruf wieder, aber nur genau einmal, nämlich bis der Cache generiert ist. Dieser Fehler betrifft genau dieser eine Seite. Alle anderen Seiten funktionieren wie sie sollen. Na sowas??

Ich pack den typolight-check auf den Server, der aber ausschließlich grünes Licht gibt, von oben bis ganz unten. Alle dateien da wie sie sein sollen.

Dann überprüfe ich eine andere Website, die auf der gleichen TL Installation läuft und das gleiche Layout nutzt, aber unter einer anderer Domain läuft. Dort sind es dann doch tatsächlich 2 Seiten, die genau das gleiche Problem haben (Videos und Impressum).

Da ich ja in der Seitenstruktur (Wurzelcache = 30 min) nichts mehr seit V.2.8.1 geändert hatte war ich verdutzt. Ich habe die problematischen Seiten dort begutachtet. Nichts auffälliges (Cache checkbox nicht aktiviert). Aktivier ich aber den Cache und stelle eine individuelle Cachezeit ein -> selbes Problem.

Nun habe ich den Cache von genau diesen Seiten erstmal deaktiviert (Cache Checkbox aktiv, Cachezeit =0) und gehe ins Bett, in der Hoffnung dass morgen jmd von euch mir einen netten Hinweis gibt, wie ich das Brett vor meinem Kopf los werde :D

Grüße und gute Nacht
Chris

Ich hatte auch nach dem Update zwei drei leere Seite. Fehlermeldungen anzeigen unter Einstellungen aktiviert und schon war mir klar, dass ich noch einen Fehler in einem eigenen Template hatte.

Meine Empfehlung daher, mal die Fehlermeldung aktivieren und schauen, ob da ein Hinweis kommt.

Das hatte ich unter 2.8.1 schon einmal, konnte aber keinen Fehler finden und habe somit den Cache deaktiviert. Ich schau mir das heute Mittag noch einmal genauer an.

Ja, war spät, hab nicht an die Fehlermeldung gedacht.. sorry, hier ist sie:

Zitat:

---

Fatal error: Call to a member function resetCache() on a non-object in /var/www/afa/afa-pages/system/libraries/Controller.php on line 1710

---

Weiß jmd was hier Sache ist? Oder muss ich mich jetzt durch die TL Scripte vardumpen?

Das ist allerdings eine Funktion die es erst ab 2.8.2 gibt.
Das Problem tauchte hier in einem anderem Thread auch schon auf.
Allerdings ist Hinweis, nur wenn aus Cache geliefert, neu.

Das damalige Ticket war: http://https://contao.org/issues/1818

Wenn du das rückgängig machen willst, in der Datei
system/libraries/Controller.php

Die Zeilen 1705 und 1740 auskommentieren (1710 und 1745 siehe nächsten Beitrag), also aus

PHP-Code:

---

$this->Input->resetCache(); 


---

wird

PHP-Code:

---

// $this->Input->resetCache(); 


---

Allerdings staune ich grad bei der Fehlermeldung bei dir über die Zeilennummer.
Scheint sich noch was geändert zu haben, also nehmt ebend 1710 und 1745.

Okay, sowas hatte ich mir schon gedacht. Leider kann ich weder an der Seitenstruktur noch in den Inhalten irgendwelche Muster erkennen, die mit diesem Fehler korrelieren.

Das Auskommentieren hat gewirkt. Die Setie funktioniert wieder wie gewohnt.
(Jedoch war der Aufruf dieser Funktion nicht in Zeile 1705 sondern in 1710.)


Vielen Dank BugBuster, hat mir ne Menge Arbeit gespart :)


Nachtrag:

Zitat:

---

Allerdings staune ich grad bei der Fehlermeldung bei dir über die Zeilennummer.

---

...zwei Dumme ein Gedanke

Anstatt einfach nur Zeilen auszukommentieren, die nach dem nächsten Update wieder drin stehen, sollten wir vielleicht versuchen, die Ursache des Problems zu finden. Gehe ich recht in der Annahme, dass auf der betroffenen Seite das Inserttag {{file}} benutzt wird? Wie genau sieht der Seitenaufbau aus?

nein, es wird nirgends ein file-Tag genuzt. Muss leider gerade weg hier... melde mich heute am Spätnachmittag wieder zu Wort.
Und keine Sorge, ich hätte dir früher oder später noch ein Ticket reingeschoben.

Gruß
Chris

Hallo Leo, gibt noch einen anderen Thread, da wurde mit {{files:....}} gearbeitet.
Dort war aber nicht davon die Rede, das das nur aus dem Cache passiert.

Ich habe aus dem Ticket die Variante die damals die Probleme machte mal nachgebaut und konnte den Fehler in 2.8.2 nicht provozieren.
Hätte ich das geschafft, hätte ich das Ticket wieder geöffnet.

So allerdings tappen wir selber noch im Dunkeln.

Der hier isses.

Hallo Leo,
jetzt konnte ich es nachstellen, sobald ich für die Seite wo ich die 2 {{file::....}} eingebaut habe den Cache einschalte und einige male in der Navigation hin und her klicke, kommt es zu dieser Meldung.
Da mir das vorher nicht passiert ist und ich den Cache aus hatte, scheint es wohl so zu sein das es passiert wenn die Seite aus dem Cache kommt.

Kann das jemand (bei dem der Fehler ist) mal bei sich prüfen?
Also Cache ausschalten für diesen Punkt in der Seitenstruktur, Cache leeren und prüfen?

Zitat:

---

Zitat von chris

nein, es wird nirgends ein file-Tag genuzt.

---

Das wäre dann aber sehr seltsam, da die resetCache Funktion nur dort verwendet wird.

OK, ich kann das bestätigen, bei Seiten mit {{file::....}} bekomme ich eine leere Seite geliefert wenn sie aus dem Cache kommen. Wird der Cache für diese Seiten ausgeschaltet und geleert dann werden sie normal angezeigt.

Hoster: strato
TL-Version: 2.8.1

Nachtrag
Fehlermeldung: Fatal error: Call to a member function get() on a non-object in [pfad zum webspace]/templates/gallery-js-ansichten.php on line 2

In dieser php-Datei steht in Zeile 2

Code:

---

$folder = $this->Input->get('folder_ans');

---

Das benutze ich zum Variablen auslesen die ich mit {{file::....}} übergebe.

Hallo Leo,
da ich das Ticket nicht ReOpen konnte, habe ich unsere Erkenntnis nur angehangen.

Kann es sein, das Input nicht initialisiert ist wenn die Seite aus dem Cache kommt?
Wäre ja eigentlich auch nicht nötig.
(Nachtrag: bisher)

Alle, die diesen Fehler haben, sollen bitte testen, ob es mit dieser Methode klappt:
In Controller.php, Zeile 1709 folgendes Einfügen:

PHP-Code:

---

$this->import('Input'); 


---

Ganzer Codeblock (neu, beginnend Zeile 1708):

PHP-Code:

---

case 'file':
    $this->import('Input');
    $arrGet = $_GET;
    $this->Input->resetCache();
    $strFile = $elements[1]; 


---

Workaround ist, bei mir gings, das Caching für diese Seite abzuschalten.
System Cache leeren, dann sollte es erstmal gehen.

Nachtrag: Oder Flob seine Änderung :D
Bis zum nächsten Update, aber da sollte das dann wie auch immer wieder funktionieren.

Zitat:

---

Zitat von BugBuster

Kann es sein, das Input nicht initialisiert ist wenn die Seite aus dem Cache kommt?
Wäre ja eigentlich auch nicht nötig.

---

Doch, sonst gibt es kein Input::resetCache();.

Ja so meine ich das ja, vorher war es nicht nötig, jetzt schon, da selbst wenn die Seite aus dem Cache fix-und-fertig kommt, wird nun eine Input Methode aufgerufen.

----------

Hallo FloB,
hab jetzt nicht reingeschaut in die Klasse Input, kann die das ab, wenn man die 2 mal initialisiert? Bzw. fängt das Framework von TL sowas ab?

Würde ja bei nicht gecachten Seiten dann passieren.

Nachtrag: Ist mit Singleton Technik gemacht, sollte also nichts passieren, cool. :cool:
Bin in OOP noch nicht so fit.

Hallo FloB,

bei mir klappt es einwandfrei! :D
Danke noch mal.

Freundliche Grüße
Frank

Zitat:

---

Zitat von BugBuster

Ist mit Singleton Technik gemacht, sollte also nichts passieren.

---

Auch ohne Singleton würde nichts passieren, außer dass doppelt so viel Speicher belegt wird ;).

Okay, da bin ich wieder.... kleiner Zwischenbericht:

FloB's Vorschlag

Zitat:

---

$this->import('Input');

---

hilft!!
Damit brauche ich den Code aus den von BugBuster genannten Zeilen nicht auszukommentieren, denn dann funktioniert alles ganz normal.

Aber nur um das nochmals klar zu stellen: ich benutze {{file::....}} NICHT!
Der Fehler kommt bei mir UNABHÄNGIG DAVON!

Hast du die Zeile exakt dort eingesetzt, wo ich es gesaegt habe? Dann musst du irgendwo den File-Tag einsetzen – such mal kräftig alle Templates, Module und Inhaltselemente durch und prüfe die Erweiterungen.

FLoB, du hast Recht... Mein Fehler.
Nach systematischer Durchsicht aller Templates und Module hab ich was gefunden. Ich hab ganz am Anfang tatsächlich mal ein Modul geschraubt mit zwei File-Inserts.

Was mich aber stutzig macht ist die Tatsache, das genau dieses Modul (eigener HTML-Code) auf vielen anderen Seiten auch zur Anwendung kommt, dort aber nicht das Problem verursacht! ... (deswegen hatte ich dieses Modul am Anfang auch gar nicht auf File-Inserts geprüft.)

Zitat:

---

Hast du die Zeile exakt dort eingesetzt, wo ich es gesaegt habe?

---

Ja.

Ich tippe mal, dass diese Seiten eine recht geringe (wenn überhaupt) Cachezeit haben ;).

siehe mein erster Kommentar

Zitat:

---

Wurzelcache = 30 min

---

Zitat:

---

Ich tippe mal, dass diese Seiten eine recht geringe (wenn überhaupt) Cachezeit haben .

---

Wieso tipst du das?

Okay, ich sehe gerade dass ein Feed Probleme macht (unter den Börsenwerten sollte noch ein Wirtschafts News Feed erscheinen!) und die Ladezeit deswegen extrem in die Höhe treibt. Kann man beim Feedmodul nicht evtl eine Notbremse einbauen, die das Abholen des Feeds nach einer gewissen, vorgegebenen Zeitspanne einfach abbricht und entweder die alten Feed-Cachedaten nimmt, oder einen "Daten nicht verfügbar" Hinweis gibt?
So isses ja echt Murks. Denn wenn ein Server den erwünschten Feed nicht ausspuckt (zB wegen Wartungsarbeiten, oder weil es ihn einfach plötzlich nicht mehr gibt) dann trödelt der Seitenaufbau eine halbe Ewigkeit und am Ende steht an der Feedstelle nichts... rein gar nichts!

Zitat:

---

Zitat von chris

Okay, ich sehe gerade dass ein Feed Probleme macht (unter den Börsenwerten sollte noch ein Wirtschafts News Feed erscheinen!) und die Ladezeit deswegen extrem in die Höhe treibt. Kann man beim Feedmodul nicht evtl eine Notbremse einbauen, die das Abholen des Feeds nach einer gewissen, vorgegebenen Zeitspanne einfach abbricht und entweder die alten Feed-Cachedaten nimmt, oder einen "Daten nicht verfügbar" Hinweis gibt?
So isses ja echt Murks. Denn wenn ein Server den erwünschten Feed nicht ausspuckt (zB wegen Wartungsarbeiten, oder weil es ihn einfach plötzlich nicht mehr gibt) dann trödelt der Seitenaufbau eine halbe Ewigkeit und am Ende steht an der Feedstelle nichts... rein gar nichts!

---

Was hat das mit dem Thema zu tun? Oder sollte der Post woanders landen?

Zitat:

---

Zitat von chris

Wieso tipst du das?

---

Weil dann die Wahrscheinlichkeit geringer ist (übrigens auch bei wenig besuchten Seiten), dass der Fehler auffällt. Auftreten müsste der Fehler logischerweise schon.

du tiptest doch, dass die Seiten keine oder geringe Cachezeiten haben... das war meine Antwort.
Ich habe jetzt das Feed-Modul durch einen Hinweis ersetzt. Jetzt flutscht die Seite wieder. Aus dem Gespräch heraus hat sich sozusagen eine Verbesserungsidee ergeben, die man tatsächlich an anderer Stelle anbringen könnte.

Nachtrag:
Achsoo, du hast nicht auf die Ladezeiten angespielt.