Cache-Problem - Nutzer sehen nicht die aktuelle Version der Website

    Auf der Website edd - entdecke dein dekanat nutze ich WordPress als CMS. Seit längerer Zeit berichten mir Nutzer, dass es zu folgendem Problem kommt:
    - auf der Startseite werden nicht die aktuellen, sondern veraltete Beiträge angezeigt
    - auch auf anderen Seiten werden z.B. die neuesten Kommentare nicht angezeigt

    Mittlerweile habe ich im head-Bereich <meta name="expires" content="0"> gesetzt und auch die interne Caching-Funktion von WordPress angewiesen, die Seiten nur für einige Stunden zu cachen. Die Nutzer berichten jedoch, dass neue Artikel über Wochen nicht angezeigt werden. Bei einigen funktioniert es wieder, wenn sie den Internetcache leeren, aber das ist ja keine Lösung, wenn ich für die Nutzung einer Website immer den Cache leeren muss. Bei einigen funktioniert es nicht mal nach Leerung des Cache korrekt.

    Das Problem besteht übrigens seit Dezember 2007. Die Seite nutzt immer die aktuellste Version von WordPress, gegenwärtig 2.5. Das Problem besteht etwa seit WordPress 2.3.

    Kennt jemand die Problematik, oder hat jemand noch eine Idee, die mir weiterhilft?!

    METAFAKTEN // Netzgeschehen und freie Software

    Einmal editiert, zuletzt von Johannes Ries (8. April 2008 um 14:32)

    • Gerade eben
    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

    Die Seite sendet einen falsches Datum im Response-Header:

    Code
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
Last-Modified: Sun, 19 Nov 2006 06:56:06 GMT


    Das hat zur Folge, daß der Browser, beim nächsten Aufruf den Server mit

    Code
    If-Modified-Since: Sun, 19 Nov 2006 06:56:06 GMT


    das nächste mal den Server befragt, der aber mit

    Code
    HTTP/1.x 304 Not Modified


    antwortet.
    Warum das so ist, ist schwer nachvollziehbar. Verwendest Du irgendein WP-Cache-Plugin?
    Ansonsten könntest Du versuchsweise mal folgende Zeile ganz am Anfang noch vor dem '<!DOCTYPE html PUBLIC...' in der Datei header.php des Themes einfügen:

    PHP
    <?php nocache_headers(); ?>


    Davor oder danach dürfen keine Leerzeilen oder Leerzeichen stehen.

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Hallo Ingo,
    danke für deine ausführliche Antwort. Ich verwende kein WP-Cache-Plugin.

    Auf den Response-Header zu schauen habe ich noch gar nicht in Betracht gezogen. Danke für den Wink. Ich habe jetzt mal den nocache-Befehl mal eingefügt - aber der bringt nur was bei WP-Cache-Plugins was, oder?

    Im Moment bekomme ich:

    Code
    Last-Modified: Wed, 09 Apr 2008 07:28:55 GMT

    Wäre zu beobachten, ob sich das Problem gelöst hat?!

    Vielen Dank aufs erste
    Johannes

    METAFAKTEN // Netzgeschehen und freie Software

    Zitat von Johannes Ries

    Im Moment bekomme ich:

    Code
    Last-Modified: Wed, 09 Apr 2008 07:28:55 GMT


    Sieh nach den Cache-Headern:

    Code
    Cache-Control:	no-cache, must-revalidate, max-age=0	
Expires:	Wed, 11 Jan 1984 05:00:00 GMT	
Pragma:	no-cache
    Zitat

    Wäre zu beobachten, ob sich das Problem gelöst hat?!


    Ja. Dafür wirst du jetzt sicher einen ziemlichen Anstieg des Website-Datenaufkommens beobachten, da die Daten eben nicht mehr aus dem Cache kommen, sondern jedesmal neu von deiner Seite geladen werden.

    Die nocache_headers()-Funktion hat nichts mit WP-Cache-Plugins zu tun.

    Code
    Last-Modified: Wed, 09 Apr 2008 07:28:55 GMT


    sieht doch erstmal gut aus :-)
    Allerdings ist das nur ein Workaround, damit wird zwar die Auswirkung "bekämpft", aber die Ursache bleibt leider im Dunkeln. Konkret stellt sich halt die Frage, wer oder was eigentlich das falsche Last-Modified setzt.

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Zitat von marX


    Ja. Dafür wirst du jetzt sicher einen ziemlichen Anstieg des Website-Datenaufkommens beobachten, da die Daten eben nicht mehr aus dem Cache kommen, sondern jedesmal neu von deiner Seite geladen werden.


    Bei WP werden die Seiten, von Feeds mal abgesehen, grundsätzlich nicht aus dem Cache geladen, weil der Last-Modified Wert normalerweise ganz fehlt. Besser wäre also wahrscheinlich, die Werte anstelle des Aufrufes von nocache_headers() einfach zu löschen:

    PHP
    <?php
  @header('Expires:'); 
  @header('Last-Modified:'); 
  @header('Cache-Control:'); 
?>

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Einmal editiert, zuletzt von Putzlowitsch (9. April 2008 um 10:08)

    Ich vermute aber eher, das der Server/PHP beim Fehlen der Werte für "Expires" und "Last-Modified" diese selber setzt. Und zwar auf das Datum der index.php im WP-Wurzelverzeichnis (diese wird ja aufgerufen). Oder es ist ein großer Zufall, daß diese Datei index.php als Dateidatum den 19.11.2006 07:56 hat, zumindest wird das bei mir lokal so angezeigt :-)

    Nachtrag: Oder anders herum. Also der Server setzt im Response-Header zunächts die Werte, z.B. Last-Modified auf das Dateidatum der aufgerufenen index.php. Da WP diese Werte normalerweise nicht ändert, bleiben sie also so stehen. Es könnte also doch funktionieren, wenn man diese einfach am Anfang der header.php wieder zurücksetzt.

    Es dürfte sich also um ein Konfigurationsproblem von Server/PHP handeln.

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Einmal editiert, zuletzt von Putzlowitsch (9. April 2008 um 10:15)

    Zitat von Putzlowitsch

    Bei WP werden die Seiten, von Feeds mal abgesehen, grundsätzlich nicht aus dem Cache geladen, weil der Last-Modified Wert normalerweise ganz fehlt.


    Ist mir klar. Ist ja bei dynamischen Seiten mit ständig geänderten Inhalten auch okay. Und statische Inhalte wie Bilder sollten ja trotzdem aus dem Cache kommen. (OT: Aber warum setzt man den "Last-modified"-Header zwar bei Feeds, aber nicht bei den normalen HTML-Seiten?)

    Ich wollte oben noch dazu schreiben, dass das eben nur die Smptome bekämpft aber nicht die Ursache. Wollte aber den OP nicht verwirren. ;-)

    PS: Wenn mod_headers verfügbar ist kann man die HTTP-Header vielleicht auch in der .htaccess setzen.

    Bei Feeds ist das einfach, da kann WP direkt aus der Datenbank auslesen, wann es die letzte Änderung gab. Bei den Seiten selber allerdings nicht, gerade wegen einer Vielzahl möglicher dynamischer Inhalte, die irgendwo in der Sidebar oder sonstwo im Theme oder über Plugins eingefügt sein können.

    Ich denke mal, das die Variante mit dem Löschen der Header in der header.php am paraktikabelsten ist, wenn sie funktioniert. Nur als Workaround versteht sich, der eigentlichen Ursache sollte man schon auf die Schliche kommen.

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Zitat von Putzlowitsch
    PHP
    <?php
  @header('Expires:'); 
  @header('Last-Modified:'); 
  @header('Cache-Control:'); 
?>

    Wenn ich das so mache, dann kommt:

    Code
    Date: Wed, 09 Apr 2008 12:32:55 GMT
Server: Apache/1.3 (Unix) mod_ssl/2.8.28 OpenSSL/0.9.8f AuthPG/1.3 FrontPage/5.0.2.2635
Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html; charset=UTF-8

    METAFAKTEN // Netzgeschehen und freie Software

    Hmm, das ist natürlich schlecht, der 1. Januar 1970 liegt schon sehr weit zurück. Gab es da überhaupt schon das Internet? :-)

    Dann wirst Du es vorerst bei dem nocache_headers() belassen müssen. Ist allerdings schon komisch, man müßte herausfinden, wo die anderen Werte herkommen. Da habe ich jetzt aber erstmal auch keinen Ansatzpunkt.

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Der Last-Modified-Header wird so sicher auf 0 gesetzt, und das entspricht nunmal dem 1.1.1970. Man müsste den Last-Modified-Header vielleicht auf den aktuellen Zeitstempel setzen, z.B. per date().

    Aber vielleicht kannst du mal deinen Hoster fragen, ob der irgendwelche Server-Einstellungen vorgenommen hat die diese Header beeinflussen.

    Übergangslösung wären die No-Cache-Headers zu senden, wie Ingo schon schrieb:

    PHP
    <?php nocache_headers(); ?>


    z.B. in die functions.php des Theme, oder in die header.php als 1. Zeile.

    Danach sollte man aber schauen, ob z.B. eine Serverfehlkonfiguration dafür verantwortlich ist, das nicht die korrekten HTTP-Header gesetzt werden.

    Noch keine Lösung für dieses Problem? Komme auf jeden Fall nicht drauf, da ich das gleiche Problem seit dem 1.10 habe! Welche Plugins setzt ihr denn ein, wenn bei euch der Fehler auftritt? Ich benutze zur Zeit:

    Akismet 2.2.1
    Anarchy Media Player 2.0
    Brian's Latest Comments 1.5.8
    Clean Archives Reloaded 3.1.4
    Custom Smilies 1.2
    Google XML Sitemaps 3.1.0.1
    Gravatar 1.1
    Highslide Integration 1.4
    ImageManager 2.5.2
    Lighter Menus 2.7.2
    Myftp 1.2
    NextGEN Gallery 0.99.1
    o42-clean-umlauts 0.2.0
    PJW Mime Config 0.9
    Post Notification 1.2.24
    Readers_Post 1.1b
    runPHP 2.3.1
    Spruechklopfer 1.0
    WordPress Database Backup 2.2.1
    wordTube 2.0.0
    WP-Polls 2.31
    XSD Snapr 1.51
    Yet Another Related Posts Plugin

    Und eventuell kam das mit nem Update rein....

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden