Startseite nicht im Seitencache?

[JvH]

Ich setze eine Seite mit Contao 3.5.24 auf. Die Ladezeiten sind sehr lang, daher habe ich den Cache (nur Server) aktiviert und auf 24 Stunden gesetzt. Das funktioniert auch bei "Unterseiten" sehr gut, die Ladezeit liegt dann beim Neuladen oft unter einer halben Sekunde.

Aber bei der Startseite funktioniert das nicht. Ich gehe zunächst ins Backend, lösche den Seitencache, melde mich aus dem Backend ab, lade die Seite xyz.de - das dauert ca. 5 Sekunden (und das meiste auf der Seite ist schon deaktiviert...).
Wenn ich die Seite dann neu lade, dauert das (mit Schwankungen) genau so lange. Melde ich mich dann im Backend an, sehe ich, dass der Seitencache jetzt eine Seite hat.

Mache ich das gleiche mit xyz.de/index.php (also die gleiche Seite unter anderem Namen) so dauert das erste Laden ebenfalls ca. 5 Sekunden - das Neuladen dann aber nur ca. eine halbe Sekunde.

Das sieht für mich so aus, als würde die Seite in beiden Fällen im Seitencache hinterlegt - aber im ersten Fall nicht von dort geholt.

Muss ich da noch was einstellen oder wie kann ich erreichen, dass die Seite xyz.de auch aus dem Seitencache kommt?

Vielen Dank für Eure Ideen dazu!

[Spooky]

Welche Contao Version?

[JvH]

Das ist die Version 3.5.24

[Spooky]

Also ich kann das Problem nicht nachvollziehen. Die Seite wird auch auf example.org/ vom Cache geladen.

Versuche das Ganze nochmal im Abgesicherten Modus.

[JvH]

Im abgesicherten Modus werden beide Seiten aus dem Cache geholt und gleich schnell geladen.

Wenn ich den abgesicherten Modus einschalte, kommt ja der Hinweis, dass der interne Cache noch nicht aufgebaut ist.
Wenn ich im abgesicherten Modus bleibe, aber den internen Cache aufbauen lasse, wird die Startseite als xyz.de/index.php weiter aus dem Seitencache geholt, aber als xyz.de wird die Startseite neu aufgebaut.

Wenn ich wieder in den normalen Modus gehe und in den Einstellungen den internen Cache deaktiviere, werden auch beide Seiten aus dem Seitencache geholt.

Scheint also irgendwie mit der Verwendung des internen Caches bei der Startseite in der Form xyz.de zusammen zu hängen. Als Theme verwende ich Rocksolid Tao - falls das wichtig sein sollte.

Selbst wenn ich alle Inhalte auf der Startseite deaktiviere, inkl. der Inhalte des Seitenlayouts, bleibt es dabei, dass die Seiten sich beim Neuladen unterschiedlich verhalten.

[Spooky]

Wie gesagt, das Problem kann ich nicht nachvollziehen. Und aus deiner Beschreibung bin ich mir jetzt auch nicht sicher, ob es im abgesicherten Modus nun funktioniert hat oder nicht.

[JvH]

Danke für die Info, dass es bei Dir funktioniert!

Wenn ich den internen Cache abschalte, funktioniert es bei mir sowohl im abgesicherten Modus als auch im normalen Modus.

[Spooky]

Deaktiviere mal manuell alle (nicht-core) Erweiterungen, baue den Internen Cache neu auf und teste nochmal.

[JvH]

Das Verhalten zeigt sich weiterhin, auch wenn ich die Erweiterungen deaktiviere. Sobald ich den internen Cache aufbaue, dauert das Laden der Startseite unter xyz.de bei Neuladen ca. viermal so lange wie das Laden der Startseite unter xyz.de/index.php.

Schalte ich den internen Cache aus, geht beides gleich schnell.

[tab]

Hast du mal explizit mit dem entsprechenden Browser-Tool (z.B. bei Firefox Entwicklerwerkzeuge - Netzwerkanalyse) verglichen oder nur anhand der gefühlten oder gestoppten Ladezeit? Vielleicht kann man da auch Unterschiede sehen. Ansonsten glaube ich mich dunkel zu erinnern, dass das vor einiger Zeit mal ein Problem war mit der Startseite im Cache, was allerdings mittlerweile gelöst sein sollte. Kann aber auch sein, dass das nur bei Mehrsprachigen Seiten war, ich finde die entsprechenden Issues bei Github gerade nicht. Hat deine Startseite eigentlich den Alias "index"?

[Spooky]

Um definitiv festzustellen, ob eine Seite aus dem Cache kommt oder nicht, könnte man hier ein

echo 'FROM CACHE'; 

einfügen. Wenn die Seite im Front-end aus dem Cache kommt, steht dann ganz oben

FROM CACHE

[JvH]

Ja, die Zeiten habe ich mit der Firefox-Netzwerkanalyse verglichen. Und die Startseite hat den Alias index

Ich habe gerade mal "Die Sprache zur URL hinzufügen" aktiviert, danach funktionierten beide Zugriffe auf die Startseite bei Neuladen gleich schnell.

Nachdem ich das dann wieder rausgenommen habe, werden zur Zeit beide Versionen sehr schnell neu geladen, immer noch mit einem Faktor 4-5 zwischen den HTML-Seiten beider Versionen, aber beide unter einer Sekunde. Wenn es so bleibt, bin ich glücklich!

Zur Not würde ich auf "Die Sprache zur URL hinzufügen" ausweichen - da funktionert beides gleich schnell.

Das mit "From Cache" werde ich gleich mal ausprobieren! Vielen Dank, Spooky

[JvH]

Ja, das war wie vermutet:

Interner Cache an:
xyz.de wird beim Neuladen nicht aus dem Cache geholt.
xyz.de/index.php wird aus dem Cache geholt.
In der Dateiwartung wird bei Seitencache angezeigt, dass ZWEI Seiten im Cache sind.

Interner Cache aus:
Beide werden aus dem Cache geholt

"Die Sprache zur URL hinzufügen" an UND interner Cache an:
Beide werden aus dem Cache geholt


Nachdem ich "Die Sprache zur URL hinzufügen" wieder ausgeschaltet habe und den internen Cache geleert und neu aufgebaut habe, werden nun beide Schreibweisen NICHT aus dem Cache geholt und der Seitencache hat nur noch EINE Seite. Die beiden verschiedenen Schreibweisen scheinen nun intern auf die gleiche Seite zu verweisen, war vorher wohl nicht so.

In der FrontendIndex.php wird an der Stelle
if (!$blnFound)
{
return;
}
(ungefähr Zeile 430)
ausgestiegen.

Wenn ich das nachverfolge wird nach $strCacheFile mit diesem Namen gesucht:
system/cache/html/7/7d8553a5646df2c939034e778dbab463.html

Per FTP sehe ich, dass an der Stelle nur die Datei
system/cache/html/7/7ae1b94336779888f336ddb4a64dbd4a.html

liegt.

[Spooky]

Poste folgende Informationen:

• Die genaue URL zur Seite, wo der Cache nicht funktioniert.
• Die Informationen aus dem Cache, also aus der Datei system/cache/html/7/7ae1b94336779888f336ddb4a64dbd4a.html (nur die erste Zeile)

[JvH]

Hier mal die erste Zeile der Datei aus dem Cache:
<?php /* xyz.de/empty.de */ $expire = 1491653962; $content = 'text/html'; $type = 'regular'; $files = ''; $assets = ''; ?>
der Aufruf lautete auf xyz.de

Die Seite ist noch nicht öffentlich, daher würde ich den Namen hier nicht gerne veröffentlichen.

Und bin gleich erst mal unterwegs.

[Spooky]

Ok, konnte das Problem nun nachvollziehen, werde dazu demnächst ein Ticket machen.

[Spooky]

https://github.com/contao/core/issue...ment-292555484

und

https://github.com/contao/core/issues/8694

[JvH]

Super, vielen Dank!

[Spooky]

Es gibt nun einen Fix hier: https://github.com/contao/core/pull/8695

Hinweis: wenn der Interne Cache nicht aktiv und aufgebaut ist, dann bleibt dieses Problem weiterhin bestehen. Wenn man allerdings den Fix anwendet, dann sollte zumindest wenn der Interne Cache aktiv und aufgebaut ist die Startseite (also der Leere Request) immer aus dem Cache kommen.

[JvH]

Bei mir war im FrontendTemplate an der im Fix angesprochenen Stelle $strCacheKey nicht */empty.de, sondern bereits "xyz.de/empty.de". Daher kam die Startseite nicht aus dem Seitencache.

Ich habe in der FrontendIndex.php an der Stelle hier (ca. Zeile 370)
// Fall back to the first accepted language
if ($strCacheKey === null)

gesehen, dass $strCacheKey = */empty.de ist. Die Fallback-Lösung wurde daher nicht ausgeführt.

Die Abfrage habe ich ersetzt durch
if ($strCacheKey === null || $strCacheKey == "*/empty.de")

und jetzt funktioniert der Seitencache auch für die Startseite.

Vielen Dank an Spooky für die Unterstützung!

[Spooky]

Das sollte aber nur notwendig sein, wenn du den internen Cache nicht benutzt. Nachdem du den Fix eingespielt hast, musst du

• Den Internen Cache löschen und neu aufbauen.
• Den Seitencache löschen.

Deine Änderung sollte dann nicht mehr notwendig sein. Deine Änderung funktioniert außerdem nicht für allgemeine Fälle - falls du das tatsächlich brauchst (solltest du aber nicht, wenn du den internen Cache benutzt), kannst du das Update Sicher über den getCacheKey Hook machen (siehe https://github.com/contao/core/issue...mment-84048472).

Beachte außerdem, dass ich den Pull Request nochmal aktualisiert habe, da war ursprünglich ein Fehler drin.

[JvH]

Hm, bei mir kommt im FrontendTemplate an der geänderten Stelle gar kein * , sondern
xyz.de/empty.de
und davon wird der MD5 Wert berechnet.

Wenn ich meine Änderung in FrontendIndex zurücknehme, den Seitencache lösche, den internen Cache lösche und wieder aufbaue, ist $strCacheKey an der Stelle hier (ca. Zeile 385):
// HOOK: add custom logic

*/empty.de und davon wird später der MD5-Wert berechnet und somit bekommt man einen anderen Wert.

Danke für den Hinweis mit dem Update-sicher, schaue ich mir an.

[Spooky]

Hm, bei mir kommt im FrontendTemplate an der geänderten Stelle gar kein * , sondern
xyz.de/empty.de
und davon wird der MD5 Wert berechnet.

Ja das ist normal - weil du wahrscheinlich die DNS Einstellung im Website Root gemacht hast. Wie sieht deine /system/cache/config/mapping.php aus?

[JvH]

Bewusst angelegt habe ich keine DNS Einstellung im Website Root. Vielleicht noch der Hinweis, dass ich auf einer Subdomain arbeite, also genau genommen abc.xyz.de - falls das von Bedeutung sein sollte.

Die mapping.php hat
<?php

return array (
'*/empty.fallback' => '*/empty.de',
'*/empty.de' => '*/empty.de',
);

[Spooky]

Interessant, das würde aber bedeuten, dass nicht das hier zum Einsatz kommt, sondern das hier. Letzteres sollte aber nur passieren, wenn es nicht der leere Request ist - also nicht http://example.org/ sondern http://example.org/foo.html.

Füge hier mal ein

var_dump(\Environment::get('request')); 

ein, lösche den Seitencache, rufe die Seite im Frontend auf und poste dann das Ergebnis.

Überprüfe außerdem, ob es nicht schon eine Extension gibt, die einen getCacheKey Hook verwendet. Solch eine Extension könnte meinen Fix natürlich aushebeln. Dazu kannst du in der selben Funktion (gleich nach dem var_dump bspw.) auch ein

var_dump($GLOBALS['TL_HOOKS']['getCacheKey']); 

einfügen.

[JvH]

\Environment::get('request') liefert
string(0) ""

Die Abfrage des getCacheKey Hook liefert NULL

Allerdings gibt es in meiner Version des FrontendTemplate in Zeile 216:
$strCacheKey = \Environment::get('host') . '/empty.' . $objPage->language;
statt
$strCacheKey = ($objPage->domain ?: '*') . '/empty.' . $objPage->language;

Wenn ich das einsetze kommt
*/empty.de
und der Cache funktioniert.

Ich benutze 3.5.24 - aktuell ist 3.5.25 - eventuell eine Anpassung dort?
Der Changelog zeigt allerdings nichts in der Richtung an.

[Spooky]

Achso, ich habe dir ja hier gesagt, dass es einen Fix gibt . Den hast du nicht eingespielt.

Wie schon gesagt, du musst:

• Den Fix einspielen.
• Den Internen Cache löschen und neu aufbauen lassen.
• Den Seiten Cache löschen.

Danach sollte es ohne sonstige Änderung funktionieren.

[JvH]

Ich hatte nur den Ausschnitt mit den Zeilen 251 - 254 (neu) gesehen, der sofort angezeigt wird (ltrim...), wenn man den Link öffnet. Die Änderung hatte ich von Hand eingebaut.

Und nicht bemerkt, dass oben noch angezeigt wird, dass es einen geänderten File gibt. Erst als ich jetzt da drauf geklickt habe, sah ich noch weitere Änderungen.

Vielen Dank!!!

[Spooky]

Ja, das wird deshalb in der "Conversation" angezeigt, weil ich dort einen Kommentar hinzugefügt habe. Die gesamten Änderungen siehst du immer nur unter /files.