Wenn wir das Produkt nun über den Shop -> Hersteller -> Produkt anwählen, dann wird der Artikel nicht /Produktname.html, sondern /Hersteller/Produktname.html angezeigt. Damit können wir leben. Allerdings ist danach plötzlich im Admin des Produktes auch wieder “Kategorie/Produktname.html” in der SEO URL eingetragen. Das ist so bestimmt nicht gedacht, oder?
Außerdem sind danach Meta Description und Meta Keywords leer. Ob URL fixiert an oder aus ist, ist egal. Das passiert mit beiden Einstellungen.
Man kann das Proble jederzeit nachvollziehen. Die URL des Shops liegt allerdings momentan in einer Testumgebung. Per PM könnte ich die Daten weitergeben.
Liegt es evtl. daran, dass wir den Artikel in der SEO ohne vorangestellte Kategorie definiert haben?
ich konnte das Verhalten in meiner Testumgebung nicht reproduzieren. Ich habe bei einem Artikel die SEO URL geändert. Meine URL sieht im Frontend so aus, egal ob über die Hersteller oder über die Kategorien aufgerufen wird: http://localhost/OXID_CE_4.0.0.2_14967/Flaschenverschluss-EGO.html
Auch ändert sich der Eintrag im Admin-Bereich nicht.
Gibt es einen öffentlichen Demoshop? Ich habe das inzwischen sogar auf einem zweiten Server reproduzieren können. Oder ich kann dir per Mail mal die Adresse unseres Testshops geben und dort ist das ganz einfach nachreproduzierbar. Nur falls du Zeit hast…
Gruß, Harald
Update: Ich habe jetzt eine PM gesendet und das was Admins und Programmierer so lieben ist auch passiert. Ich kann den Fehler heute selber nicht mehr reproduzieren Ich schreibe hier neu, wenn das Problem wieder auftritt (aber es war wirklich so wie ich schrieb)
Ich würde es extrem “erleichternd” finden, wenn man im Admin einstellen könnte, dass sich die Url für einen Artikel aus einem domain.de/Artikelname + eventuell Artikelnummer zusammen setzen würde. Außerdem fände ich es nett, wenn der Shop die Urls automatisch (bzw. einstellbar) einfach klein schreibt.
Optimal wäre wenn man im Adminbereich direkt bestimmten könnte aus was sich die Artikel-Url zusammen setzt.
Das Verzeichnis in der Artikel Url finde ich auch extrem störend, da ich im Moment bei Eingabe eines Artikels immer die Kategorie lösche. Alles manuelle Arbeit, die nicht sein müsste
Mit jedem “/” in einer Url kann die Relevanz des Inhaltes sinken. Das ist doch nicht beabsichtigt oder?
wollte gerade mal bei einigen Kategorien und Artikeln eine SEO URL eintragen und mußte feststellen, dass die Sonderzeichen ( z.B. - und _ ) beim Betätigen des Speichern-Buttons in ein ; umgewandelt werden.
Außerdem hängt er an eine URL, die nicht mit einem Datei-Typ abgeschlossen wird ein / an.
Ist das jemanden schon untergekommen, wenn ja gibts schon eine Lösung ?
Gruß Uwe
Ergänzung: in den Meta-Tag-Einträgen werden Umlaute wie ü -> ue umgewandelt (nicht gut)
Im Oxid-Demo-Shop sind zumindest Bindestriche möglich, Unterstriche werden beim speichern einfach entfernt.
was wie umgeschrieben wird, kannst Du zum großen Teil in den Grundeinstellungen festlegen. Schau dort mal bei Dir nach, nicht dass aus Versehen an dieser Stelle der Bindestrich zum Semikolon wird.
Bei allen anderen angeführten Punkten sehe ich nicht wirklich ein Problem. Vor allem zum Thema Unterstriche in der URL scheint es sehr einheitliche Vorstellungen zu geben. Aber natürlich ist SEO Religion. Jeder kann es so anpassen, wie er’s gern hätte.
Ver. 4.0.1.0 - Wir haben das selbe Probelm. Unabhängig ob Seo Url fixiert oder nicht, zerschlägt es immer wieder die Seo Url, d.h. Pfad wird wieder mit “Kategorie” oder “Hersteller” ergänzt und vollständig abgebildet: “Kategorie/produkt.html”.
Ferner sind danach Meta Keywords und Meta Tags Datenbankfelder leer !
Das Problem zeigt sich meistens nach dem erneuten Einlogen ins Backend.
Habe das gleiche Problem. War alles schön eingestellt, lief ein paar Tage…plötzlich war alles wieder bei null. Weiss nicht, wie das passiert ist. Habe in der Zeit bei den SEO-Einstellungen keine Änderungen vorgenommen. Habe eine neue Artikelkategorie hinzugefügt, aber das sollte nicht die Ursache dafür sein.
Gibt es mittlerweile eine Lösung des Problems?
Hatte Version 4.0.1.0, ist jetzt 4.1.3 (SEO Daten waren vorher schon “zerschossen”).
[QUOTE=WebTools de;2364]Mit jedem “/” in einer Url kann die Relevanz des Inhaltes sinken. [/QUOTE]
Das war vielleicht mal in den Anfangszeiten der ersten Suchmaschinen so. Mittlerweile gehört diese Hypothese (=einer Suchmaschine statische Seiten vorgaukeln) in das Reich der Legenden. Mittlerweile ist es schnurzpiepegal, wie Du Deine URL schreibst.
Sie (die Suchmaschinen) haben nämlich tatsächlich mittlerweise mitgekriegt, dass Websites heutzutage mittels Datenbanken erzeugt werden. Und legen daher verständlicherweise auch keinen Wert mehr darauf, auf welche Weise eine URL zusammengebaut wird. Noch dazu wo sie wissen, dass jede SEO-Bude versucht, mittels simpelster URL-Modifikation in irgendeiner Weise das Ranking zu verbessern. Das war mal.
Die Url ist schon wichtig “sprechende” sollten es schon sein, aber wie Thorsten schon sagt ist es schnurz piep wie die aussehen haupsache sprechen sollen Sie
Wir haben viele Webmaster getroffen, die wie unsere Freunde annehmen, dass statische oder statisch aussehende URLs einen Vorteil für Indexierung und Ranking mit sich bringen würden
(…)
Ihr solltet dynamische URLs, wenn möglich, dem Erstellen einer statisch aussehenden URL vorziehen.
Nun gut, egal wie die Meinungen zu den URL’s sind, fakt ist doch, es gibt ein Problem mit der Umsetzung der URL’s im Shop. Ich habe nämlich auch ein ähnliches Problem, denn die URL-Fixierung verschwindet einfach manchmal aus bereits angelegten Artikeln. Der Shop ist ein CE 4.1.4. Die Produkte wurden in einer 4er Vorgängerversion angelegt, dort gab es dieses Problem nicht.
Sicherlich könnte in der Datenbank direkt die URL geändert werden, dass ist aber nicht die Lösung zu dem Problem. Im PE 4.1.4 konnte ich das Ganze noch nicht reproduzieren, obwohl gesagt wird, dass es dort keine Unterschiede gibt. Ich habe inzwischen zwei komplett unterschiedliche Projekte mit dem CE 4.1.4 laufen bei beiden das gleiche Problem.
Es kann ja nicht sein, dass man beim Anlegen eines neuen Artikels anschließend sämtliche URL-Fixierungen der Artikel überprüfen muss. Hat hier vielleicht jemand eine Lösung dazu?
Mich würde mal interessieren ob seitens OXID an dem Problem gearbeitet wird und wann mit einer Lösung zu rechnen ist.
Bevor ich jetzt ein Modul kaufe, oder viel Arbeit in eine eigene Lösung stecke um mich dann nach dem nächsten Update zu ärgern.
Auf Longtail betrachtet, ist das ein richtiger Nachteil. Wenn man die URL nicht fixieren kann, indem man Hersteller/Kategorie aus der URL nimmt, dann darf man nie den Artikel verschieben oder umbennen, man ist immer an die jetzige Einstellung gebunden…
Ich nutze CE 4.1.5_21618. Ist dieses Problem in 4.1.6 endlich behoben??
Hm, an dieser etwas unpassenden Stelle möchte ich gerne mal kurz auf das Template-System und den Hack “Template Modification System” von vbulletin hinweisen. Damit sind, wenn es nicht gerade ein großes Major-Release ist, Updates innerhalb von einigen Minuten auszuführen, auch wenn teils recht umfangreiche Änderungen an den Templates vorgenommen wurden! Ist mal ein Blick wert ;)*
Und leider ist der von mir beschriebene Bug immer noch vorhanden! Sobald ich den Artikel im Frontend aufrufe, verschwindet im Backend das Häkchen für “URL fixieren” und der alte Pfad mit Kategorie ist wieder angegeben
Hm, ich dachte, das wurde nun behoben?
*EDIT: Sorry für den Doppelpost und die Edits…
Habe jetzt dieses hier genannte query ausgeführt. Selber Effekt, die SEO-Pfade lassen sich nicht fixieren
zunächst kurz über Bugs:
Ein Bug ist dann ein Bug, wenn er reproduziert und in den Bugtracker eingetragen wurde, vorher ist er quasi für die OXID-Entwickler nicht existent.
Der Bug wurde offiziell mit dem Release 4.1.6 gefixt. Wenn es nach wie vor bei Dir nicht funktioniert, kann das im Prinzip zwei Ursachen haben:
a) Der Bug wurde nicht richtig gefixt, was vorkommen kann und
b) bei Deinem Update ist etwas schief gelaufen, was ich in diesem Fall vermute, wenn ich mir die Fehlermeldungen im anderen Post anschaue. Darüber weiter im anderen Post.
Ich schreibe hier neu, wenn das Problem wieder auftritt (aber es war wirklich so wie ich schrieb)
