Seitencache und Spracherkennung

[dmolineus]

Nach dem Update von einer Contao-Installation 3.3.7 auf 3.4.3 funktionierte der Seiten-Cache nicht mehr. Nach einigen Debuggen fiel mir auf, dass Contao nun die Seite mit "de-DE" cachte, in den Seiteneinstellungen jedoch das Sprachkürzel "de" hinterlegt war.

Daher hat Contao die Seite nicht aus dem Cache geladen obwohl die Seite auch als Sprachenfallback arbeitet.

Durch die Umstellung in den Seiteneinstellungen besteht jedoch das Problem, dass ein Browser, der lediglich ein "de" als Accept-Language sendet, wieder eine ungecachte Seite lädt.

[dmolineus]

Das ist ein grundsätzliches Problem bei einer nicht unterstützten und damit gecachten Sprache (Accept-Language). Diese werden immer ungecacht ausgeliefert anstatt die gecachte Fallbackseite zu laden.

[Toflar]

@dmolineus PR? ;)

[dmolineus]

Wenn wir uns im Voraus auf eine Lösung verständigen können, mach ich das. Mein Vorschlag ist folgender:

• Bei einer Fallback-Seite sollte für einen leeren Request sowohl ein Cache Item empty.LANG als auch nur empty angelegt werden (FrontendTemplate)
• Beim Laden vom Cache wird bei einem erfolglosen Laden von empty.LANG versucht empty zu laden.
• Natürlich auch für die mobile Variante

Dadurch erspart man sich eine Datenbankabfrage beim Laden vom Cache, um die Standardsprache zu ermitteln. Die doppelten Cache-Einträge sind imho zu verschmerzen.

[aschempp]

Woher soll das System denn wissen dass für empty.LANG keine Seite existiert, oder ob die einfach noch nicht gecacht wurde?

[dmolineus]

Woher soll das System denn wissen dass für empty.LANG keine Seite existiert, oder ob die einfach noch nicht gecacht wurde?

Danke für den Einwand, hatte ich nicht bedacht.

Ich seh erstmal keine Möglichkeit ohne Datenbankabfrage dies festzustellen (es sei denn man hat eine Cache-Datei mit allen verfügbaren Sprachen).

[Toflar]

@leofeyer up for discussion-Label?

[leofeyer]

Eine Datenbank-Abfrage kommt jedoch beim Laden aus dem Cache keinesfalls in Frage.

[BugBuster1701]

(es sei denn man hat eine Cache-Datei mit allen verfügbaren Sprachen).

bzw. der Rootseiten Sprach Definition inkl. Fallbacksprache. Dann käme man zumindest für den Fall hier #7650 schon weiter.

[leofeyer]

Wir haben heute auf Mumble darüber gesprochen, verstehen aber das Problem nicht so ganz. Könntest Du uns das nochmal erklären bzw. beim nächsten Mumble-Termin mit uns besprechen?

[dmolineus]

Es ist das gleiche Problem, wie @amenk in #7650 detaillierter beschrieben hat und hier ja auch verlinkt ist. Doch gern noch einmal konkreter.

1. Der Cache ist aktiviert und es wird die Startseite angesurft.
2. Diese wird mit den Spracheinstellung gecacht (de).
3. Der Browser ruft die Startseite auf mit folgenden Accept-Language Header de-DE,de.
4. In outputFromCache wird nun empty.de-DE versucht aus dem Cache zu laden, was nicht existiert.

Dies tritt auch auf, wenn Accept-Language Header en ist und dafür keine gecachte Datei existiert.

Die Probleme dabei sind:

1. Es findet kein Mapping zwischen de-DE und de statt, auch nicht in die andere Richtung.
2. Nicht existierende Sprachen für die der Fallback greift werden nie gecacht ausgeliefert.

Der ursprünglich vermutete Zusammenhang mit dem Update auf Contao 3.4 konnte nicht bestätigt werden. Der Fehler wurde jedoch erst durch den massiven Performance-Verlust nach dem Update sichtbar (Ladezeit ~0.9sec gegebüber ~0.35sec davor).

Gern erläutere ich es auch bei einem nächsten Mumble-Termin, bin aber zu den 19 Uhr Terminen donnerstags nicht verfügbar.

[leofeyer]

Meiner Meinung nach vertust Du Dich in Punkt 2:

Diese wird mit den Spracheinstellung gecacht (de).

Wenn die Primärsprache aus dem Accept-Language-Header de-DE ist, wird die Seite unter empty.de-DE im Cache abgelegt.

[aschempp]

Ich habe mir den Code nicht angesehen, aber ich bin der Überzeugung die Seite wird unter empty.de (nämlich der Sprache der Root-Seite) gecacht.

[dmolineus]

Wenn die Primärsprache aus dem Accept-Language-Header de-DE ist, wird die Seite unter empty.de-DE im Cache abgelegt.

Nein, wird sie nicht. https://github.com/contao/core/blob/master/system/modules/core/classes/FrontendTemplate.php#L204

Wäre auch fahrlässig, da man durch einen gefakten Header den Cache zuspammen könnte.

[leofeyer]

Da habt ihr beide Recht.

[amenk]

Ich denke man sollte wie in #7618 (comment) beschrieben die Root Seiten und Fallback Struktur separat cachen.

[aschempp]

Das nützt nichts, weil wir ja nicht wissen ob es eine Sprache de-DE gibt und sie einfach noch nicht gecacht wurde…

[amenk]

Ich dachte jetzt an ein Array, Serialisiert in einer Datei abgelegt in der die Root Seiten und deren Sprachen gecacht werden. So braucht man keine Datenbankabfrage. Ein andere Möglichkeit wird es denke ich nicht geben, denn man braucht ja die Infos über die Fallback Struktur.
Statt dem Array könnte man auch leere Dateien mit den anderen Sprachen anlegen um sie als "Existent aber nicht gecacht" zu markieren und dann bei Bedarf cachen.

[dmolineus]

Ich dachte jetzt an ein Array, Serialisiert in einer Datei abgelegt in der die Root Seiten und deren Sprachen gecacht werden. So braucht man keine Datenbankabfrage. Ein andere Möglichkeit wird es denke ich nicht geben, denn man braucht ja die Infos über die Fallback Struktur.

Genau das war auch meine Idee, die ich oben vorgeschlagen hatte.

[amenk]

Und generell braucht man wohl noch irgendwo ein Stück Code was von de-DE auf de mappt, oder?

[dmolineus]

Ein Mapping zwischen de <-> de-DE gäre gut, auch wenn nicht ganz trivial. Angenommen man hat eine Seite mit de-AT und eine mit de-DE stellt sich die Frage auf was de dann gemappt wird.

[leofeyer]

Behoben in ed1a73a. Beim Aufbau des internen Cache wird jetzt eine Mapper-Datei angelegt, die bestehende Sprachen plus Fallback-Sprache auf die jeweiligen Cache-Keys mappt. Nur wenn der interne Cache gar nicht aufgebaut ist, fällt der Frontend-Controller auf die bisherige Lösung mit der ersten akzeptierten Sprache zurück.

[leofeyer]

@ALL Bitte testen und Feedback geben.
@contao/developers Sollen wir das in die 3.2 portieren?

[Toflar]

@contao/developers Sollen wir das in die 3.2 portieren?

Ich stimme für Nein. Begründung:

• Das aktuelle Verhalten ist zwar nicht korrekt, beeinflusst aber die Funktionalität nicht wesentlich.
• Der Change ist mir persönlich zu aufwändig für ein Bugfix-Release.
• Die 3.5 wird die neue LTS und ist in 2 Monaten fällig.

[leofeyer]

@Toflar So einfach ist das nicht.

• Das eigentliche Feature (Seiten aus dem Cache laden) ist in Contao 3.2 schon drin. Die Änderung ist teils ein Bugfix und teils eine Erweiterung, die jedoch auch wieder einen Fehler behebt (nämlich die hohe Anzahl an Cache-Misses bei leeren URLs). Trotzdem verstehe ich Deinen Punkt.
• Die Änderung ist momentan im hotfix/3.4.5-Zweig enthalten, also auch nicht in einem Feature-Release. Entweder müssten wir also beide Hotfix-Releases oder keinen damit ausliefern, oder?

[fritzmg]

@Toflar

Das aktuelle Verhalten ist zwar nicht korrekt, beeinflusst aber die Funktionalität nicht wesentlich.

Auf einer Seite, die nur einen Seitenbaum hat und als Sprache de festgelegt hat + Sprachenfallback, bekommt ein User nie eine Seite aus dem Cache von Contao, wenn er mit einem HTTP Accept-Language header ungleich de daher kommt.

Wenn eine Contao Seite von der Cache Funktionalität abhängig ist (warum auch immer) besteht imho eine starke Beeinträchtigung.

[Toflar]

Es geht ja nicht um die Frage ob's ein Bug ist oder nicht. Selbstverständlich ist es einer und wenn es ein Bug ist dann beeinflusst der selbstverständlich auch die Funktionalität. Ist doch logisch. Ich hab nur gesagt er beeinträchtigt die Funktionalität von Contao nicht wesentlich weil es keinen Grund gibt, warum der Cache auf die Funktionsweise einen Einfluss haben sollte. Er reduziert nur Server- und/oder Bandwidth-Load.

[fritzmg]

Ja ok, verstehe.

Würde auch verstehen, wenn dieser Fix letztendlich auch erst in der nächsten LTS version auftaucht (wie von leofeyer erwähnt).

[aschempp]

Auf einer Seite, die nur einen Seitenbaum hat und als Sprache de festgelegt hat + Sprachenfallback, bekommt ein User nie eine Seite aus dem Cache von Contao, wenn er mit einem HTTP Accept-Language header ungleich de daher kommt.

Nicht ganz, das trifft natürlich nur auf die Startseite zu (ev. nur falls diese ein Alias index hat?).

[aschempp]

Fände auch dass das in die 3.5 sollte. Es ist nicht wirklich ein Bug, sondern ein known limitation (siehe #7650)

[fritzmg]

Nicht ganz, das trifft natürlich nur auf die Startseite zu (ev. nur falls diese ein Alias index hat?).

Ah ok, da hab ich wohl zu wenig getestet :)

[dmolineus]

Ich hab nur gesagt er beeinträchtigt die Funktionalität von Contao nicht wesentlich weil es keinen Grund gibt, warum der Cache auf die Funktionsweise einen Einfluss haben sollte

Auf die Funktionsweise nicht, auf die wahrgenommene Performance jedoch schon. Gerade wenn man auf der Startseite ein weniger perfomantes Contao Modul einsetzt (Events-Modul mit > 5000 Events), hat man schnell Ladezeiten, die wenig erfreulich sind.

[Toflar]

Das ist richtig. Das wäre dann aber, wie gesagt, der Speed und nicht die Funktionsweise :-)
Ich würd’s nur gerne in der 3.5 haben, weil’s ein grösserer Change ist und die 3.5 sowieso im Mai kommt.
Bleibt es in der 3.4 in einem Bugfix-Release so muss es natürlich auch auf die 3.2 gebackported (Denglish ftw) werden :)

[dmolineus]

Für mich wäre 3.5 auch in Ordnung. In den Projekten, wo dies ein Problem war, läuft eh seit längerem ein Workaround, sodass das Problem dort nicht mehr relevant ist.

[leofeyer]

Hab die Änderungen in der 3.4 zurückgenommen und nach 3.5 portiert.

[fritzmg]

@dmolineus : wie sieht dieser workaround aus? wäre vielleicht auch für andere interessant

[dmolineus]

@fritzmg Dieser Workaround macht nichts anderes, als über den getCacheKey Hook den Cache-Key zu manipulieren. In meinem Fall, wo es nur eine Sprache gibt, sehr einfach.

    public function hookGetCacheKey($cacheKey)
    {
        if (\Environment::get('request') === '' || \Environment::get('request') === 'index.php') {
            $cacheKey = 'empty.de-DE';
        }

        return $cacheKey;
    }

Wenn man mehrere Sprachen hat, müsste man hier halt das Mapping zwischen den 2 und 5 Zeichen Sprache-Codes und auf die Fallback-Sprache mit implementieren.

[SpeGal]

There is still a bug in this issue! See #7909.
Page caching doesn't work with multiple languages!

[fritzmg]

This is still a problem in Contao 3.5.25 (see https://community.contao.org/de/showthread.php?66351-Startseite-nicht-im-Seitencache for example).

Reproduction

1. Create a new Contao installation.
2. Create a theme and page layout.
3. Create a new website root with the language set to en.
4. Set the previously generated page layout.
5. Enable the page cache within the website root.
6. Create a start page with alias index within the website root.
7. For debugging purposes, add echo 'FROM CACHE'; here and echo 'NOT FROM CACHE'; here.
8. Set the primary Accept-Language of your browser to de.
9. Clear the internal cache and do not rebuild (it won't work with the internal cache either, but that is a different issue: inconsistent cache key generation #8694).
10. Open the front end (without a request parameter) in a new browser session or while being logged out of the back end. You will see NOT FROM CACHE.
11. Reload the page. You will see NOT FROM CACHE again, even though a cache file is present.

[fritzmg]

This is due to the fact, that Contao will search for a cache key that consists of …/empty. plus the primary Accept-Language here: system/modules/core/controllers/FrontendIndex.php#L367-L371. If the page's language differs from that, the page cannot be served from cache.

However, since this only happens, when the internal cache is not active (after applying #8695), I consider this not much of an issue. You are unlikely to not use the internal cache in the productive environment.