Sprung zum ersten ungelesenen Beitrag aus dem Dashboard fehlerhaft

Wir nutzen als Startseite das Dashboard.

Chrome-Nutzer (Mobil) melden, dass der Sprung zum ersten ungelesenen Beitrag aus der Box „ungelesene Themen“ sporadisch nicht funktioniert. Der Sprung erfolgt stattdessen zum ersten Beitrag auf der letzten Seite des Threads bzw. auf den ersten Beitrag des Threads.

Hier sind die Meldungen: https://unknowns.de/forum/thre…?postID=815797#post815797

Könnt ihr das bitte mal prüfen und ggf. korrigieren?

Quote from Alexander Ebert

Hallo,

diese Art von Fehlern treten durch fehlerhafte Cache-Header seitens des Webservers auf. Diese haben zur Folge, dass der Browser die Umleitung noch im Cache hat und somit bei einem späteren Aufruf nicht den Server abfragt, sondern direkt die Umleitung aus dem Cache verwendet. Dies führt dann zum Sprung zum ursprünglich neusten Beitrag und nicht zum aktuell neusten Beitrag.

Wir setzen zu diesem Zweck bereits sehr restriktive Cache-Header, um dies bestmöglich zu unterdrücken, aber mit einer entsprechenden Server-Konfiguration lässt sich dies überschreiben. Auch Erweiterungen wie mod_pagespeed und Konsorten können dies implizit verursachen.

Hallo,

ich muss leider noch einmal nachfragen, da nach anfänglichen einzelnen Problemen das Problem größer wird.

Noch einmal kurz die Fehlerbeschreibung:

Aus der Dashboardbox "Ungelesene Themen" ruft man einen noch ungelesenen Beitrag auf (alternativ aus der Forenübersicht):

Der Link, den man anklickt sieht wie folgt aus:

https://unknowns.de/forum/thread/17180-human-punishment-the-beginning/?action=firstNew

Der Browser öffnet den entsprechenden Thread und springt auf der letzten Seite des Themas zum ersten Beitrag auf dieser Seite, aber nicht zum neuesten.

Im Browser steht folgender Link:

https://unknowns.de/forum/thread/17180-human-punishment-the-beginning/?postID=855404#

Die postID passt schon. Lösche ich das # und schicke den Link ab hängt er das # wieder ran und bleibt oben auf der Seite. Eigentlich wäre der richtige Link:

https://unknowns.de/forum/thread/17180-human-punishment-the-beginning/?postID=855404#post855404

Irgendwie generiert er das post...... hinter dem # nicht.

Dieses Problem scheint auch nicht mit jedem Browser aufzutreten. Und es scheint auch in den betroffenen Browsern nur bei ausgewählten Links aufzutreten. Es ist aber nicht erkennbar, was der Unterschied ist wann es geht und wann nicht - also was den einzelnen ungelesenen Thread besonders macht.

Gesichtet wurde es schon bei Chrome und kleineren Browsern. Zum Firefox haben wir noch keine Meldungen erhalten.

Das Problem ist auch nicht immer reproduzierbar. Auch die User, die es melden haben das Problem nicht immer.

Ehrlich gesagt sind wir etwas ratlos ob der Fehler nun auf Client, Server oder Woltlab Seite liegt.

Wir nutzen kein mod_pagespeed.

Anbei noch unsere Rewrite-Regeln, falls es eventuell daran liegen könnte, da ja die angeklickte URL schon irgendwie zu einer anderen URL im Browser wird.

Quote

RewriteEngine On

# BurningBoard rewrites

# wbb2 => 5.4

RewriteCond %{REQUEST_URI} ^/wbb2/thread.php [NC]

RewriteCond %{QUERY_STRING} ^threadid=(\d+).*$ [NC]

RewriteRule ^wbb2/thread.php.*$ https://unknowns.de/forum/thread/%1 [NC,NE,QSD,R=301,END]

# postid ohne threadid funktioniert nicht!

# RewriteCond %{REQUEST_URI} ^/wbb2/thread.php [NC]

# RewriteCond %{QUERY_STRING} ^postid=\d+$ [NC]

# RewriteRule ^wbb2/thread.php https://unknowns.de/forum/thread/ [NC,NE,R=301,END]

# 4.0 => 5.4

RewriteCond %{REQUEST_URI} ^/wbb4/index.php/Thread/\d+ [NC]

RewriteRule ^wbb4/index.php/Thread/(\d+).*$ https://unknowns.de/forum/thread/$1/ [NC,NE,QSA,R=301,END]

# 4.1 => 5.4

RewriteCond %{REQUEST_URI} ^/wbb4/index.php [NC]

RewriteCond %{QUERY_STRING} ^thread/(\d+).*/.*[=#](\d+)$ [NC]

RewriteRule ^wbb4/index.php$ https://unknowns.de/forum/thread/%1/?postID=%2#post%2 [NC,NE,R=301,END]

RewriteCond %{REQUEST_URI} ^/wbb4/index.php [NC]

RewriteCond %{QUERY_STRING} ^thread/(\d+).*/$ [NC]

RewriteRule ^wbb4/index.php$ https://unknowns.de/forum/thread/%1/ [NC,NE,QSD,R=301,END]

# 5.3 => 5.4

RewriteCond %{REQUEST_URI} ^/wbb4/forum/index.php [NC]

RewriteCond %{QUERY_STRING} ^thread/(\d+).*/&?postID[=#](\d+)$ [NC]

RewriteRule ^wbb4/forum/index.php.*$ https://unknowns.de/forum/thread/%1/?postID=%2#post%2 [NC,NE,R=301,END]

# general rewrites

RewriteCond %{REQUEST_URI} ^/wbb4/ [NC]

RewriteCond %{QUERY_STRING} ^thread/(\d+).*(&.*)$ [NC]

RewriteRule ^.*$ https://unknowns.de/forum/thread/%1/%2 [NC,NE,QSD,R=301,END]

RewriteCond %{REQUEST_URI} ^/wbb4/(.*)/index.php$ [NC]

RewriteRule ^wbb4/.*$ https://unknowns.de/%1 [NC,NE,R=301,END]

RewriteCond %{REQUEST_URI} ^/wbb4/ [NC]

RewriteRule ^wbb4/(.*)$ https://unknowns.de/$1 [NC,NE,R=301,END]

# www => no www

RewriteCond %{HTTP_HOST} ^www\.unknowns\.de$ [NC]

RewriteRule (.*) https://unknowns.de/$1 [R=301,END]

# SSL-ZWANG

RewriteCond %{SERVER_PORT} !=123

RewriteRule (.*) https://unknowns.de/$1 [R=301,END]

Display More

Über Hilfe würden wir uns freuen, da es die Usability des Forums doch im weiter einschränkt.

Chrome spukt das hier aus:

Quote

WCF.Combined.min.js?v=1667458746:4 [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

Hat aber wahrscheinlich nichts damit zu tun - oder?

Ok, noch eine Beobachtung...

Chrome hängt auch an die Hauptadresse immer ein "#" ran.

Wenn ich dann Chrome schließe und wieder öffne ist das # erst mal wieder weg. Könnte also ein Chrome Cache Thema sein?

Unter Edge gibt es diese Probleme nicht.

Deshalb tippe ich auch nicht auf ein Server-Thema. Scheint Chrome spezifisch zu sein. Darauf deuten auch die zahlreichen User-Meldungen hin. Nervig ist halt, dass es mal geht und mal nicht, was die Fehlersuche schwierig macht.

Ich nutze keinerlei Addons unter Chrome.

Ergänzung: öffnet man den Link mit rechter Maustaste und wählt „in einem neuen Browserfenster“; dann geht es.

Derzeitige Vermutung ist, dass eventuell Probleme auftreten, wenn das Timing beim Laden der Inhalte, JS, … mal anders ist…laienhaft ausgedrückt.

So. Zwischenstand: das Plugin „Erweiterte Suche“ scheint das Problem zu verursachen. Und hier insbesondere die Funktion „kontextsensitive Suche“. Wir haben diese im ACP deaktiviert und es scheint nun zu gehen.

Kann sein, aber die Probleme gab es nur bei Chrome - warum auch immer.