Joomla Cache Probleme - dynamische Inhalte im Frontend - gibt es hierzu schon weiter Informationen

    Auch wir haben diverse Probleme bei aktiviertem Cache (normales Caching /Datei) und Anzeige von Darstellungen im Frontend festgestellt.

    Dies betrifft häufig dynamische Darstellungen im Frontend wie Videos und Bootstrap z.B. Auch Padding-Einstellungen von Modulpositionen sind teilweise betroffen.

    Leider gab es seither zu diesem Issue nichts Neues, was die Ursache war oder hab ich was verpasst (war mal was bei 3.7.0)?

    Cacheprobleme – Joomla! Documentation

    Ist das jetzt bei J5 wieder ein Problem?

    Ich empfehle mittleiweile den Joomla Cache nicht mehr zu nutzen aber kann ja auch keine Lösung sein.

    Hallo Dirk,

    wollte gestern dazu was schreiben, war aber zu müde.
    Auch wenn geschlossen, hole ich es hier nach:

    Mit "Cache Einstellungen" habe ich nie was getan. Sollte ich? :)
    Bei mir ist es so:


    Lediglich wenn ich z.B. in der user.css was mache, dann dauert es ein wenig.
    Paar Mal Strg+F5 - sonst nix.

    Zitat von WM-Loose

    Leider gab es seither zu diesem Issue nichts Neues, was die Ursache war oder hab ich was verpasst (war mal was bei 3.7.0)?

    Ev. war es das da:

    Remove empty locked cache file if callback function terminate process by csthomas · Pull Request #15592 · joomla/joomla-cms
    Pull Request for Issue #15544 Summary of Changes Remove empty locked file at shutdown script if cache callback function terminate process on 404. This is my…
    github.com

    bzw. https://github.com/joomla/joomla-cms/pull/15875
    führte uns zu: https://github.com/joomla-framework/cache
    (schaut älter aus).

    Liebe Grüße
    Christine

    Naja, wenn man keine Probleme mit der Performance hat, dann kann man natürlich jeglichen Cache ausstellen. Aber man senkt eben die möglichen User deutlich oder anders gesagt, der Preis pro User steigt deutlich.

    Funktionieren sollte der normale Cache eigentlich immer und der ist auch nicht anfällig.

    Cache -> normales Caching -> Datei -> Plattformspezifisch nein -> damit hatte ich auch noch nie Probleme, bringt aber einiges an Leistung


    Was immer mal wieder Probleme verursacht ist der zusätzliche Seitencache unter Plugins. Den sollte man gerade bei dynamischen Inhalten eher auf Aus stellen oder wenn man Probleme hat. Alternativ kann man da auch speziell Seiten angeben, die ausgenommen werden sollen vom Cache.

    edit: Wie schaut es den mit dem Server aus? Wird da auch noch etwas wie CSS gecached? Das könnte jedenfalls auch für Probleme Sorgen.

    Ich habe jetzt einen Ansatz. AllInkl verwendet generell Broti zut Komprimierung für https Seiten.

    Ich denke dass Gzip dann in Joomla auf jeden Fall deaktiviert werden sollte.

    Es gibt bestimmt eine Möglichkeit Broti zu nutzen und einen Eintrag in der htaccess zu platzieren.

    Muss morgen mal schauen.

    Andreas24 Haben wir alles schon ausprobiert.

    Was die Ladezeiten angeht, habe ich mit dem aktivierten Cache bisher noch keine Geschwindigkeitsvorteile fesgestellt.

    Gerade gefunden:

    Thema

    J!5.1.0 Nachinstallationshinweis Brotli compression

    Zur Info!

    .htaccess Update Brotli Compression

    Seit Version: 5.1.0

    Vor 5.1.0 unterstützte die Standarddatei htaccess.txt die Brotli-Komprimierung nicht. Dies könnte zu doppelten Komprimierungsfehlern führen, wenn Joomla auf einem Server installiert wird, der die Brotli-Komprimierung verwendet. Sie sollten die erforderlichen Änderungen manuell an einer vorhandenen .htaccess-Datei vornehmen, da diese Datei nicht automatisch aktualisiert werden kann.

    Der alte Code:

    (Quelltext, 2 Zeilen)

    Der neue…
    Elwood
    16. April 2024 um 18:51
    Zitat von WM-Loose

    Es gibt bestimmt eine Möglichkeit Broti zu nutzen und einen Eintrag in der htaccess zu platzieren.

    Da gab es mal was drüber. Müsste ich suchen.

    M.E. ist das in den aktuellen htaccess.txt schon mit drin. Bin mir aber nicht sicher:

    Spoiler anzeigen

    ## GZIP & BROTLI
    ## These directives are only enabled if the Apache mod_headers module is enabled.
    ## This section will check if a .gz file exists and if so will stream it
    ## directly or fallback to gzip any asset on the fly
    ## If your site starts to look strange after enabling this file, and you see
    ## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
    ## then your server is already gzipping css and js files and you don't need this
    ## block enabled in your .htaccess
    <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist
    # and the client accepts gzip.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

    # Serve gzip compressed JS files if they exist
    # and the client accepts gzip.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

    # Serve correct content types, and prevent mod_deflate double compression.
    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1,E=no-brotli:1]
    RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1,E=no-brotli:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
    # Serve correct encoding type.
    Header set Content-Encoding gzip

    # Force proxies to cache gzipped &
    # non-gzipped css/js files separately.
    Header append Vary Accept-Encoding
    </FilesMatch>
    </IfModule>