Keine SEO-URL nach Attributfilterung, dafür force_sid-Links

Ich bin weder im Forum noch im Bugtracker fündig geworden, daher eröffne ich ein neues Thema:

Nach Auswahl eines Attributes in einer Kategorie wird z.B. aus der URL:
<Shop-URL>/Geschenke/Wohnen/Uhren/
in der Browser-Adresszeile die URL:
<SHOP-URL>/index.php?

Zuerst fiel mir dies bei einer lokalen Test-Installation der CE auf, hier kam noch hinzu, dass dann auf der “neuen” Seite sämtliche Links zwar korrekte SEO-Schreibweisen aufwiesen, diesen jedoch ein “?force_sid=<Zeichenkolonne>” angehängt war. Nach Auswählen eines Links waren auf der folgenden Seite aber wieder alle Links reine SEO-URLs. Dies konnte ich anschließend auch auf Zunderweb-Demo 3 nachvollziehen. wobei ich diesen Attributfilter nicht installiert habe. Danach trat dieses Phänomen nicht mehr auf. Weder bei Zunderweb-Demo 2 noch in o.g. Demoshop – und auch nicht mehr bei Zunderweb-Demo 3 oder meiner lokalen CE-Testumgebung.

Nach einem Neustart des Browsers (Firefox Portable) gab es aber auch wieder die Force-SID-Links. Allerdings wieder nur zweimal: Das erste Mal getestet mit meiner lokalen CE, das zweite Mal bei der Onlinedemo der Community Edition. Anschließend gab es nur noch das zuerst genannte Problem der “index.php?” statt SEO-URL. Im Internet Explorer konnte ich die force_sid-Links bei drei Shops erkennen, bevor beim vierten diese fehlten (und auch beim anschließenden Aufruf der vorherigen Shopseiten).

Dass die Url auf index.php wechselt, liegt einfach daran, dass in oxviewconfig->getSelfActionLink() “index.php” als Ziel für alle POST-Requests zurückgegeben wird. Also bei Attributfiltern, Suche, Preisalarm etc. Im Grunde kann man das Ziel (Action) auch leer lassen, ich habe das mal hier gemacht: http://zunderweb.de/oxiddemo3/Uhren/
SEO-Urls sind aber ja eigentlich für Suchmaschinen gedacht, und diese setzen keine POST-Requests ab.

Das mit dem force_sid liegt wahrscheinlich daran, dass der Shop an diesem Punkt eine Session startet, und da er nicht weiß, ob cookies aktiviert sind, sendet er beim ersten Mal die SID mit. Kommt die SID über den Cookie zurück, kann er sie wieder weglassen, falls nicht, wird sie weiterhin an jede Url angehängt. Daher erscheint der Zusatz mit der SID auch nur einmal pro Browsersession.

Die Filter aus den Beispielen kannst du übrigens bei mir erwerben.

Danke für den Tipp! Eigentlich sollte das meines Erachtens auch Standard sein. Denn korrekte Links sind auch für den Besucher nützlich.

Dass man beim Speichern einer Seite in den Lesezeichen nicht die Filterung mitspeichert, ist noch zu akzeptieren. Aber in dem Fall würde man über das Lesezeichen ja wegen des “index.php?”-Links nur auf der Startseite des Shops landen.

[QUOTE=Unioxid;45442]Danke für den Tipp! Eigentlich sollte das meines Erachtens auch Standard sein. Denn korrekte Links sind auch für den Besucher nützlich.

Dass man beim Speichern einer Seite in den Lesezeichen nicht die Filterung mitspeichert, ist noch zu akzeptieren. Aber in dem Fall würde man über das Lesezeichen ja wegen des “index.php?”-Links nur auf der Startseite des Shops landen.[/QUOTE]

Das ist Stand der Technik und nicht nur im Oxid Shop so: Das Formular sendet POST-Parameter. Demnach sind die in der URL nicht enthalten. Sonst wären es ja GET-Parameter, die jedoch aus bestimmten Gründen dort nicht gewollt sind. Da muß der Shopbesucher mit leben. Immerhin stellt er ja auch die Anforderung, dass die Shopsoftware sicher und stabil läuft.
Das leer lassen wird zwar im Großteil der Fälle funktionionieren. Bei Aktionen über verschiedene Domains hinweg kann das aber zu ungewollten Fehlern führen. Daher rate ich eher davon ab.

Wenn wenigstens die Action die ursprüngliche SEO-URL (inkl. der Unterrubriken) zurückgeben würde, wäre ja alles in Ordnung.

Und wie soll es über mehrere Domains hinweg Probleme geben? OXID generiert alle Links doch mit der Domain, über die der Shop aufgerufen wurde?

[QUOTE=DanielS;45450]Das ist Stand der Technik und nicht nur im Oxid Shop so: Das Formular sendet POST-Parameter. Demnach sind die in der URL nicht enthalten. Sonst wären es ja GET-Parameter, die jedoch aus bestimmten Gründen dort nicht gewollt sind. Da muß der Shopbesucher mit leben. Immerhin stellt er ja auch die Anforderung, dass die Shopsoftware sicher und stabil läuft.
[/QUOTE]
Was für Gründe sprechen an dieser Stelle eigentlich für POST? Für GET würde sprechen, dass es sich bei Filtern um eine reine Ansicht handelt. Ich habe mich mal kurz umgesehen, bei Amazon, Ebay, Dell, Endless wird GET für Filter verwendet (Endless.com benutzt zwar Ajax, trotzdem wird die Url bei jeder Aktion aktualisiert, damit das Ergebnis bookmarkbar ist.

[QUOTE=DanielS;45450]
Das leer lassen wird zwar im Großteil der Fälle funktionionieren. Bei Aktionen über verschiedene Domains hinweg kann das aber zu ungewollten Fehlern führen. Daher rate ich eher davon ab.[/QUOTE]
Wie sollen hier Aktionen über Domaingrenzen entstehen?