Das heißt, dass man nichts dagegen unternehmen kann, das liegt alles am Caching des Browsers.
Wieso kommt eigentlich ein Hinweis, statt der Beitrag selbst mit einem 'neu'/'ungelesen' label?
Edit: ich glaub ich weiß die Antwort, wegen des 'als gelesen markieren's?
Wieso kommt eigentlich ein Hinweis, statt der Beitrag selbst mit einem 'neu'/'ungelesen' label?
Edit: ich glaub ich weiß die Antwort, wegen des 'als gelesen markieren's?
Ich vermute folgendes: Als du die Seite zum ersten mal aufgerufen hattest, hattest du ja noch keinen Beitrag geschrieben und die Beiträge davor werden als statische Seite ausgegeben und gecached.
Nun öffnest du den Editor, der über js/Ajax nachgeladen wird und somit keine neue Seite erzeugt und wird somit auch nicht gecached. Du schickst deinen Beitrag ab und dieser wird dir per Ajax an die bestehende Seite angehängt und (vereinfacht gesagt) in die Datenbank geschrieben.
Deine Statische HTML Seite hat sich aber nicht neu geladen oder ähnliches. Wenn du nun auf ne andere seite gehst und den zurück Button nutzt nimmt dein Browser wieder die statische Seite vom Anfang (zwischendrin wurde die seite ja nicht neu geladen) und dann kommt wieder Ajax und sieht, da ist ein neuer Beitrag, der bisher (also zum Zeitpunkt des Ladens der statischen Seite) noch nicht da war und bäms, so erzeugst du diese Ansicht.
Das wäre zumindestens das einzige was ich mir vorstellen könnte 
Was als Lösung gehen könnte wäre da folgendes: Bei der Ajaxabfrage die UserID mitschicken und wenn die dann mit der Autorenid übereinstimmt, den Beitrag vollständig anzeigen. 
ist aber nur eine Idee
Gibt es nicht generell mehrere Möglichkeiten per jQuery die History nach einem ajax-Request anzupassen sodass der aktuelle (neue) status der seite im Browser auch per Zurück Button aufrufbar ist ?
@Weltraumente Die Erklärung war zu 100% korrekt, exakt so läuft es auch ab.
@Morik Grundsätzlich ja, aber damit kann man den Browser nicht zur Erzeugung einer neuen Cache-Version zwingen. Ich habe es schon mit history.pushState() bzw. history.replaceState() probiert, aber ohne Erfolg.
@Weltraumente, @Alexander Ebert:
ich weiß, ich habe mich anscheinend schon wieder nicht gut genug ausgedrückt.
Ich fragte, wieso ein Hinweis "durch Ajax" erscheint, und nicht der Beitrag selbst ("durch Ajax!!!").
Und deshalb mein Edit:
Es wäre schwieriger festzustellen, ob der durch Ajax geladene Beitrag gelesen wurde, oder nicht (z.B. würde es vielleicht als gelesen markiert werden, ohne dass man runtergescrollt hat und die Seite schließt).
Ich hoffe ihr habt mich ausnahmsweise mal verstanden xD
es wäre jedoch auch möglich die Caches anzupassen, aber dann müsste jede Seite neu geladen werden, wenn man auf zurück klickt.
Ahhh ok 
jetzt hab ich auch gerallt worauf du rauswolltest
Was als Lösung gehen könnte wäre da folgendes: Bei der Ajaxabfrage die UserID mitschicken und wenn die dann mit der Autorenid übereinstimmt, den Beitrag vollständig anzeigen. ist aber nur eine Idee
So würde er ja zumindestens den Eigenen Beitrag anzeigen, der ja standardmäßig für einen selber als gelesen markiert ist
Beiträge werden glaub ich via den LastVisit Zeitpunkt als gelesen Markiert und da beim Zurückbutton ja die Alte zeit gilt könnte man höchstens via irgendeiner ajax-api alle beiträge mit erstellungszeit vor dem eigenen beitrag auch noch als gelesen markieren und dementsprechend auch als "ausgeklappter Beitrag" angezeigt werden. Aber das ist halt alles so ein bisschen problematisch Mit den zeiten und bei nachladenden inhalten
Don’t have an account yet? Register yourself now and be a part of our community!
