Artikel funktionieren nicht mehr

Es wird auf der Newspage GAR NICHTS aktualisiert im Chrome. Bin eben mit dem Firefox auf die Startseite gegangen und habe mich über die Biostar-News gefreut. Dann habe ich den Chrome aufgemacht und der zeigte den Webwatch von gestern. Weder die heutige News war sichtbar, noch die Pressemittteilung, noch war der Kasten "Forum Aktuell" und "Partnernews" auf dem neuesten Stand. Erst nach manuellem betätigen des Reload-Buttons zeigte Chrome den gleichen Status wie Firefox.
Dass auch unsere eigenen News nicht aktualisiert werden, spricht gegen unseren Verdacht.
Bisher sah es so aus, dass die Teile der Startseite nicht aktualisiert werden, die an Wordpress vorbei geladen werden.
Wie gesagt so kürzlich ist es nicht! Es sind bei mir schon mehrere Wochen!
Das zählt für mich noch zu kürzlich. Wenn es die Art und Weise wäre, wie wir Dinge an Wordpress vorbei laden und in die Startseite einfügen, müsste das Problem nämlich schon seit der Umstellung, also seit August 2013 existieren.

Habe selber noch ein wenig gegoogelt und folgenden Leidensgenossen gefunden:
https://wordpress.org/support/topic/page-not-updating-in-certain-browsers-caching-problem
Interessant ist da vielleicht der letzte Beitrag.
Danke für den Hinweis, wir werden das mal prüfen.
 
Soll ich Nero mal kontaktieren, dass er sich das live bei mir ansieht? Der alte Sack ;D wohnt ja nicht weit weg von mir. Oder bringt das nichts?
 
Zuletzt bearbeitet:
Ich habe die letzten Tage mal etwas herumprobiert und konnte folgendes beobachten:

Windows 7 x86_64: Palemoon 25.2 (FF Derivat) und Iron (Chromium 40.0.2214 Derivat) : Startseite bleibt auf altem Stand.

Ubuntu 14.04 x86_64: Firefox 35.01 und Chromium 40.0.2214: Aktuelle Inhalte werden geladen.

@Marrrrtin: Du benutzt doch auch Win7, oder? Würde imich interessieren, ob bei dir unter Linux das Problem evtl. auch weg ist.
 
Das Client-Betriebssystem kann damit nichts zu tun haben. Ich vermute ein Problem mit dem Software-Stack auf dem Server, am wahrscheinlichsten in Wordpress oder vielmehr in der Art und Weise wie wir es einsetzen.
Sollte meine Vermutung stimmen, sind Browser-Vergleichstests nichtssagend, denn dann wird das Ergebnis meines Wissens schon verfälscht, wenn zwischendurch mal ein anderer User Strg+F5 drückt und damit den Server-seitigen Cache implizit mit aktualisiert.
 
Ich vermute hier zumindest ein Wechselspiel. Wenn es nämlich nur daran liegen würde müsste doch zum Beispiel mein Win7 Rechner nach einem Reboot nachdem ich den Browser öffne und unsere Startseite aufrufe einen aktuellen Cache laden, vor allem wenn ich vorher unter Linux schon mehrfach STRG+F5 gedrückt habe, was ja den Cache nach deinen Worten implizit aktualisiert. Das passiert aber nicht, es wird ein alter Stand angezeigt.

Ubuntu hat dagegen nach dem Booten gleich eine aktuelle Seite geladen, in beiden Browsern.
 
An welcher Stelle soll sich denn das Client-Betriebssystem einklinken? Der Browser sendet einen Request an den Server. Der Browser bestimmt dabei über die HTTP-Header mit, wie der Server seinen Cache nutzt. Der Server wiederum gibt dem Browser über die HTTP-Header in der Antwort Hinweise, wie der Browser-Cache genutzt werden sollte. Weder das Client-Betriebssystem noch das Server-Betriebssystem spielen da mit.
Wenn es Unterschiede zwischen den Betriebssystemen gibt, dann liegt das daran, dass z.B. die Ubuntu-Version von Firefox sich anders verhält als die Windows-Version (anders konfiguriert, vielleicht sogar anders kompiliert). Meinst du vielleicht sowas?
 
Tjo, aktuell fehlt mir auch noch die rechte Idee, wo es hakt. Ich denke aber, dass es eher an der jeweiligen Browserversion liegt und das Verhalten des Browser vom jeweiligen Clientbetriebssystem abhängt und dadurch das Problem entsteht, weniger durch das Betriebssystem selber, ja.

Ich habe nur leider selber keinen zweiten Windows-PC zur Hand um zu testen. Interessant wäre es zu wissen wie sich das selbe Firefoxprofil einmal unter Windows und einmal und Linux verhält, bei Benutzern die von dem Problem betroffen sind.

Ich hab schon überlegt ob es irgendeinen Bug bzgl. der Tab-Wiederherstellung geben könnte, dass die Browser statt die Seite wirklich neu zu laden auf alte Daten zurückgreifen. Leider habe ich keine Möglichkeit gefunden diese Funktion abzuschalten.
Möglicherweise spielt auch der normale Browsercache doch eine Rolle, in einem "Incognito" Fenster wurde - wenig überraschend - auch unter Win7 jeweils eine aktuelle Version geladen.
Als völlig absurde Idee könnte ich mir höchstens noch vorstellen, dass die HTTP-Header bzgl. der Caches bei den Windows Versionen nicht richtig ausgewertet werden, aber das ist echt nur eine absurde Idee.

Übrigens:
Dass es einen Unterschied bei der Kompilierung gibt, davon kannst du zumindest in meinem Fall ausgehen, das ich ja zumindest beim Firefox unter Windows keinen Originalclient am laufen habe, ebenso kein Chromium sondern eben Iron.
 
Zuletzt bearbeitet:
Es kann nicht sein, dass serverseitig das Problem ist.
Ein Server führt hier php dh. eine Skriptsprache aus. Das enthält keine Möglichkeit etwas nicht auszuführen!
Statische Elemente unterliegen Caches aber nicht Skriptergebnisse die von php kommen.
 
Es kann nicht sein, dass serverseitig das Problem ist.
Es kann also nicht sein, was nicht sein darf? Probier's doch selber erstmal. :P Ich versuche hier konstruktiv auf ein Problem hinzuweisen und als Antwort kommt nur "kann nicht sein". Dass ich das Problem nur hier auf P3D habe, anderswo aber nicht und den Chrome auch schon frisch neu aufgesetzt habe, zählt also nicht?
 
Zurück
Oben Unten