"Dokument erloschen" in Firefox & Co bei Listensortierung

Hallo zusammen, ein Kunde berichtete mir, dass es - aufgrund von neuen Sicherheitseinstellungen in den aktuellen Webbrowsern wie Firefox - Probleme gibt, wenn Kunden in den Listenansichten über die Browser-Back-Funktion navigieren. Hier erscheint öfters die Meldung “Dokument erloschen”. Grund dürften u.a. die Sortierungsformulare (“Anzahl der Artikel pro Seite” / “Sortierung nach”) sein, die sich via POST versenden. Schritte um das Verhalten (auf shopwaredemo.de) zu reproduzieren: 1. http://www.shopwaredemo.de/food-wine aufrufen 2. Sortierung auf “Höchster Preis” ändern 3. auf Seite 2 blättern 4. Auf die Zurück-Taste des Browsers klicken => Es erscheint im Firefox (13.0.1) die Meldung (s. Anhang) “Dokument erloschen, Dieses Dokument ist nicht mehr verfügbar.” Haben auch andere das Verhalten beobachten können? Gibt es einen Workaround? Wie geht Ihr damit um? Ich freue mich über Eurer Feedback! Viele Grüße, Rafael Kutscha

Hallo liebe Community, leider hat sich bislang noch niemand zu diesem Thema geäußert, daher Pushe ich es noch einmal. Auf http://www.camp-firefox.de/forum/viewto … 61#p801061 wird neben der Umstellung von POST- auf GET-Formulare (Bietet sich bei shopware für die Kategorielisten an) folgendes empfohlen: header("Cache-Control: max-age=300"); Bei shopware (3.5.6) hat diese Einstellung bei mir leider keinen Erfolg gebracht. Es würde mich freuen, wenn wir an dieser Stelle gemeinsam eine Lösung erarbeiten.

Ich kann den Fehler mit Firefox 15 oder Chrome 22 nicht nachvollziehen.

Upps, ist bei uns auch so. Shopversion 3.5.6 getestet mit FF 15.0.1 Klickt man auf “Erneut senden” wird die Seite wieder angezeigt. Und nu?

[quote=“tschersich”]Ich kann den Fehler mit Firefox 15 oder Chrome 22 nicht nachvollziehen.[/quote] Hallo, der Demostore ist mittlerweile auch shopware 4. Unter shopware 3.5 ist das Verhalten auf allen modernen Browsern nachvollziehbar, die dieses “Sicherheitsfeature” eingebunden haben. Die Listenansichten sind ja schnell umgestellt - bei den Artikeldetailseiten ist das Verhalten z.B. bei Konfiguratorartikeln auch zu beobachten. Hier wäre es toll, wenn irgendwer herausfinden könnte, wie sich das auf eine einfache Weise beheben lässt. Bei anderen Shops reicht es lt. Infos im Internet aus, die Cache-Dauer im PHP-Header zu setzen. Bei shopware bekomme ich das leider nicht hin. Vielleicht hat ja jemand mehr Erfolg oder shopware nennt uns einen Workaround bzw. die Stelle, wo sich die PHP-Cache-Dauer setzen lässt?

Das ist ein generelles Problem der 3.x Versionen und die Erklärung ist leider sehr technisch: Die Sortierung aber und die Variantenauswahl bei den Konfiguratorartikeln sind mit Formularen realisiert, die ihre Daten per POST an die aktuelle Seite abschicken. Das wäre an sich kein Problem wenn Shopware anschließend eine Weiterleitung machen würde - dadurch würden die Formulardaten für den Browser entwertet. Diese Weiterleitung macht Shopware 3.5 allerdings nicht. Wenn man nun nach dem Abschicken des Formulars (beispielsweise beim Ändern der Sortierung) weiter klickt und den zurück Button drückt, so hat der Browser die Formulardaten im Zwischenspeicher. Geht man nun auf einen Artikel und anschließend ber Back Button wieder auf die Liste müsste der Browser die Daten zur geänderten Sortierung erneut an den Server Schicken, um die Liste erneut anzuzeigen. Früher hat Firefox das mit der Nachfrage „Daten erneut Senden?“ quittiert. In den neueren Versionen erscheint die „Dokument erloschen“ Meldung mit dem „Erneut Senden Button“. Das Verhalten soll verhindern, dass der Browser ungefragt Daten an den Server sendet. Beheben ließe sich das leider nur durch einen Eingriff tief im Shopware Core. Wir haben uns auch schon oft über dieses Problem geärgert, weil ein Kunde der in eine „Dokument erloschen“ Meldung läuft potenziell beschließen wird, dass der Shop nicht funktioniert und abbricht. Die gute Nachricht ist, dass das Verhalten im SW4 Demoshop in der Tat nicht mehr zu beobachten ist. Offensichtlich arbeitet Shopware zwischenzeitlich bei den POST Formularen mit Weiterleitungen. Das Problem ist also zumindest mittelfristig durch ein Update auf die 4er Version zu beheben. Schöne Grüße Marco

1 Like

[quote=“tanmar”]Das wäre an sich kein Problem wenn Shopware anschließend eine Weiterleitung machen würde - dadurch würden die Formulardaten für den Browser entwertet. Diese Weiterleitung macht Shopware 3.5 allerdings nicht.[/quote] Hallo Marco, kannst Du ein Beispiel nennen, wie so eine Weiterleitung ausschauen würde? @shopware: Wird es noch einen Bugfix für die 3.5.x-Version geben?

*PUSH* Gibt es Neuigkeiten / Lösungen zu diesem Thema? Hat kein anderer Shop Probleme mit diesem Verhalten?

Oh sorry die letzte Nachricht hatte ich gar nicht gesehen. Nachdem das Verhalten tief im Shopware Core sitzt haben wir uns nie die Mühe gemacht, so weit zu graben. Es ließe sich aller Voraussicht nach ohnehin nur mit einem Hack am Core ändern. Mittelfristig dürfte die beste Lösung für das Problem ein Update auf 4.x sein. Marco

Ich hoffe immer noch auf ein Update/Fix der Shpware AG. Mich wundert nur, dass dieses Verhalten so wenige Shop-Betreiber stört. Es müssten ja eigentlich die POST-Formulare der Artikel-Detailseite auf GET umgestellt werden, oder? Für die Listenansicht ist das ja noch ein recht überschaubarer Job.

Hallo aikanet, für dieses Problem können wir dir leider keine Lösung anbieten. Es wird hierfür auch kein Fix von Seiten Shopware geben. In Shopware 4 tritt dieses Verhalten nicht mehr auf. Vielleicht solltest du so oder so mittelfristig deinen Shop auf eine 4er Version bring. Gruß Patrick

Schade, dass es keine offizielle Lösung via Shopware-Update geben wird. Da der betroffene Shop erheblich customized ist (incl. Import-Anwendung), wird der Kunde kein zeitnahes Update auf die neue Version ordern. Ich hoffe immer noch, dass sich hier jemand findet, der ein Patch oder genaue Infos geben kann, was auf der Artikel-Detailseite angepasst werden muss.

Uns betrifft das ebenfalls. Da wir sehr viele Konfigurationsartikel haben, tritt das Problem häufig auf.

Hallo, dieses Problem besteht auch bei der 4er Version von Shopware. Hier ist es genau da selbe Verhalten bei der Artikelansicht. Wenn man einen Artikel ansieht, der Varianten hat, eine Variante ändert, (die Seite lädt neu) und man klickt im Browser auf den Zurück-Button, bekommt man das “Dokument erloschen” zu sehen. Dieses bekomme ich in allen Shopware 4 Shops. Da kann man sich also einen der Referenz Seiten raus suchen, einen Artikel der Varianten hat, diese wechseln und den Button klicken.

*edit: Ich hab das was ich vorher mal hardcoded eingebaut hatte mal auf die Schnelle in ein Plugin für 3.5 gegossen. Sollte für die Kategorie- und Detailseite funktionieren und ist bitte als Workaround zu verstehen, nicht als saubere Lösung des Problems! <?php class Shopware_Plugins_Frontend_DocumentExpiredFix_Bootstrap extends Shopware_Components_Plugin_Bootstrap { public function install() { $event = $this->createEvent( 'Enlight\_Controller\_Front\_StartDispatch', 'onStartDispatch' ); $this-\>subscribeEvent($event); return true; } public static function onStartDispatch(Enlight\_Event\_EventArgs $args) { Shopware()-\>Plugins()-\>Frontend()-\>DocumentExpiredFix(); } public function init() { $event = new Enlight\_Event\_EventHandler( 'Enlight\_Controller\_Front\_PreDispatch', array($this, 'onPreDispatch') ); Shopware()-\>Events()-\>registerListener($event); } public function onPreDispatch(Enlight\_Event\_EventArgs $args) { /\* @var $request Enlight\_Controller\_Request\_RequestHttp \*/ $request = $args-\>getSubject()-\>Request(); /\* @var $response Enlight\_Controller\_Response\_ResponseHttp \*/ $response = $args-\>getSubject()-\>Response(); if(in\_array($request-\>getControllerName(), array('cat', 'detail'))) { $response-\>setHeader('Cache-Control', 'private, max-age=10800, pre-check=10800', true); $response-\>setHeader('Last-Modified', gmdate('D, d M Y H:i:s') . ' GMT', true); $response-\>setHeader('Expires', null, true); $response-\>setHeader('Pragma', null, true); } } }

Hi, für das Verhalten in Shopware 4 auf der Artikeldetailseite wurde ein Ticket erstellt. Wann dies umgesetzt wird kann ich aber nicht sagen. Gruß Patrick

[quote=“ovi”]*edit: Ich hab das was ich vorher mal hardcoded eingebaut hatte mal auf die Schnelle in ein Plugin für 3.5 gegossen. Sollte für die Kategorie- und Detailseite funktionieren und ist bitte als Workaround zu verstehen, nicht als saubere Lösung des Problems![/quote] Danke, bei meinem Test bekomme ich leider weiterhin auf der Detailseite die “Dokument erloschen”-Meldung. Kann es sein, dass ich ggf. noch weitere Controller (Ajax-Controller) hinzufügen muss? P.S.: Ich habe das Plugin in “Shopware_Plugins_Frontend_Expired_Bootstrap” umbenannt, da Shopware sonst Probleme macht.

Hi, hast du es zufällig im Chrome getestet? Firefox dürfte damit funktioniert, mir ist zumindest nichts gegenteiliges bekannt. Ein Workaround für die aktuelle Chromeversion ist mir auch nicht bekannt.

Ich habe es mit dem aktuellen Firefox getestet. Es handelt sich bei den Produkten um Konfiguratorprodukte - vermutlich ist das der Grund, da hier partiell Inhalte nachgeladen werden. Leider kenne ich die Details nicht (anscheinend immer, wenn ein POST-Befehl erfolgt ist?), anhand denen Firefox entscheidet, wann ein Dokument erloschen ist.

Ja, so ist es, allerdings funktioniert es im aktuellen Firefox mit der Änderung. Wir haben auch Konfiguratorartikel. Wenn du den Namen des Plugins geändert hast, dann musst du in der onStartDispatch Methode auch dort den Namen anpassen, vielleicht hast du das einfach nicht gemacht?