Hallo, ich teste zur Zeit Shopware 3.5 CE auf einem lokalen Server (Ubuntu 9.04 Server, php 5.2.10 als Apache Modul). In den Systeminfos werden überall grüne Haken angezeigt. Als Browser nutze ich die aktuellen Versionen von Firefox und Chrome. Bei zwei Sachen komme ich im Moment nicht weiter und bin für jede Hilfe dankbar. Ich habe einen Testartikel angelegt und würde diesen gerne exportieren. Ich gehe auf Inhalte->Import/Export und wähle beim ersten Formular ‘Artikel’ und ‘CSV’. Nach dem Klick auf ‘Start’ passiert nichts. Ich dachte erst, dass vielleicht die Daten im Shopverzeichnis abgelegt werden - nichts. Was mache ich falsch? Das zweite Problem sind die SEO-URLs von bestehenden Kategorien. Ich habe eine Testkategorie direkt nach der Installation angelegt und darin einen Testartikel. Im Frontend lautet die URL zur Kategorie ‘/cat/index/sCategory/2151’ - ist nicht schön (die URL zum Testartikel ist ‘/detail/index/sArticle/2/sCategory/2151’). Deshalb habe ich Anpassungen im SEO-Modul vorgenommen, gespeichert, alle Caches gelöscht (im SEO-Modul habe ich auch ‘Datum des letzten Updates’ geleert) - die URLs (Kategorie, Produkt) bleiben allerdings bestehen. Ich habe dann eine zweite Kategorie angelegt und den Artikel hinzugefügt. Hier lautet die URL zur Kategorie wie im SEO-Modul vorgegeben ‘/testkategorie-2/’ (Name der Kategorie) und die URL des Artikels ‘/testkategorie-1/testartikel-1-2.html’ (Name der 1. Testkategorie (?hier plötzlich richtig?) + Artikelname + Artikel-ID). In der Breadcrumb wird allerdings bei der ‘Testkategorie 1’ wieder die ‘hässliche’ URL verlinkt 
Muss ich eventuell in der Datenbank manuell noch Daten löschen, so dass die Pfade neu aufgebaut werden? Das merkwürdige ist, dass in der Tabelle s_core_rewrite_urls die richtigen Angaben bei path stehen - nur in der Frontendausgabe passen die URLs nicht. Ciao Tobias
Das zweite Problem mit den SEO URLs habe ich zwischenzeitlich auch immer wieder. Nach mehrmaligem “durchklicken” sind dann die SEO URLs plötzlich richtig. Guckt man sich aber mal an, wie das gemacht wird, stellt man fest, dass z.B. bei der Einzelproduktanzeige mit einem “externen” 301 Redirect gearbeitet wird, um die URL richtig hinzubiegen. Auch scheint es erst mindestens einen non-SEF Aufruf geben zu müssen, bevor die SEF URL in den Cache geschrieben wird. Ich glaube nicht, dass da etwas falsch eingestellt ist, sondern dass die RewriteRules grundsätzlich nicht ganz sauber umgesetzt sind. Schade auch, dass sich einzelne URLs nicht fixieren bzw. im Backend ändern lassen, wie das bei einem “Mitbewerber” der Fall ist. Schade, denn genauso, wie man META Description oder Keywords pro Produkt/Kategorie für SEO festlegen kann, sollte auch die SEF URL eintragbar sein. Erzeugung von Duplicate Content bzw. das Neugenerieren des SEF Cache ohne die Möglichkeit, einzugreifen, ist für mich fast schon ein Ausschlusskriterium.
Gut zu wissen, dass es nicht nur mir so geht 
Aber: Jetzt habe ich einen kleinen Erfolg zu melden. Nachdem ich die Daten in der Tabelle s_core_rewrite_urls gelöscht, den Cache geleert und die Seite neu aufgerufen hatte, passte die URL auch bei der ersten Kategorie und auch beim Artikel in dieser Kategorie sieht es jetzt gut aus - ich hoffe es bleibt so und ändert sich nicht laufend. Ich kann Dir nur zustimmen was die URLs betrifft: bei Magento beispielsweise ist man mit dem ‘url-key’ flexibler. Vielleicht kommt das ja noch, bisher macht Shopware eigentlich ‘viel Spaß’. Bleibt nur noch der Artikelexport Tobias
Artikel Export ist gefixed. Ich habe das Update 3.5.0.1 heruntergeladen viewtopic.php?f=17&t=209&p=1200#p1200 und jetzt geht es.
Hallo zusammen, auf den Aufbau der SEO-Urls, bzw. auch auf den einzelnen Link, hat man als Shopbetreiber schon einfluss. Da der Aufbau über ein Template definiert ist, kann dieses auch einfach abgewandelt werden. Siehe auch http://www.shopware.de/wiki/Module-SEO-Engine_detail_456.html Anbei ein kleines Beispiel für den Link zu Artikeldetailseite: Artikel-Detailseiten-Template: (Kann in den “Grundeinstellungen / Module / SEO” im Shopware Backend definiert werden) {if $sArticle.attr1}{$sArticle.attr1}{else}{sCategoryPath articleID=$sArticle.id}/{$sArticle.id}/{$sArticle.name}{/if} In Shopware können ja Artikel-Attribute angelegt werden. Attribut 1 (Freitext-1) ist standardmäßig in den Artikelstammdaten vorhanden. In diesem Fall wird für die Generierung des SEO-Links erst das Artikel-Freitext-Feld geprüft und falls dort etwas eingetragen wurde, wird daraus die URL erstellt. Ansonsten wird der Standard-Aufbau, in diesem Falle Kategorie + ID + Artikelname, genutzt. In diesen Eingabefeldern ist Smarty verfügbar und ermöglichst somit einen individuellen Aufbau der Kategorie- und Artikellinks. Ich hoffe euch damit weiterhelfen zu können… Sebastian
Hallo Sebastian, vielen Dank für das Feedback. Mit diesen ‘Magie’ ist es natürlich möglich eine eigene Struktur aufzubauen - und es ist wahrscheinlich sogar mächtiger, als wenn man es nur über ein Feld macht - aber beim überfliegen des Backends ist es zunächst verwirrend, wenn man was anderes gewohnt ist Habe jetzt auch bemerkt, dass es direkt bei Klick auf ‘Shopcache leeren’ eine Seite gibt, in der man alle Caches sauber löschen kann. Bei den ‘Feeds’ habe ich gesehen, dass diese im Frontend diese URL haben: aktuelles?sCid=1 Gibt es eine Möglichkeit diese auf ‘aktuelles/feed-headline’ umzustellen? Tobias
Hi Tobias, der Punkt “Feeds” ist eigentlich nur noch aus Kompatibilitätsgründen in Shopware enthalten. Seit Shopware 3.0.5 gibt es einen neuen Menüpunkt “Blog”, welcher das Feedmodul ablöst. Dort stehen deutlich mehr Möglichkeiten zur Verfügung inkl. alle SEO-Urls. Der Blog ist gerade für ein Aktuelles-Bereich sehr gut geeignet. Dort können auch mehrere Bilder / Downloads o.ä. angeboten werden. Sebastian
Hi Sebastian, nochmal Danke für diese Info - das Blogmodul hatte ich noch nicht angeschaut. Schönes Wochenende Tobias
Ich muss doch nochmal zu meinem SEO Problem zurückkommen, denn jetzt kann ich den Effekt wenigstens richtig nachvollziehen, denke aber nicht, dass sich das mit den SEO Einstellungen der Grundeinstellungen beheben läßt: Ausgangssituation: - Shopware Caches alle automatisch über Nacht geleert - Browser Cache leer - Browser Cookie Cache leer - Aufruf meiner Shop-Startseite http://www.foo.bar/ - Startseite wird geladen - Im Browser wird Cookie SHOPWARESID mit Inhalt z.B. m60bvg2pn4j87jrc0j1sjkhcg7 gesetzt - Das Hovern (nicht klicken!) über jeden beliebigen Link der Startseite hat jetzt den Cookie-Wert als GET Parameter anhängen: http://www.foo.bar/?sCoreId=m60bvg2pn4j87jrc0j1sjkhcg7 - Der Klick auf z.B. das Logo und damit der erneute Aufruf der Startseite hat dann auch wie erwartet ohne ein 30x Redirect leider folgende URL: http://www.foo.bar/?sCoreId=m60bvg2pn4j87jrc0j1sjkhcg7 - Beim erneuten Hovern über die Links stellt man dann glücklicherweise fest, dass der Spuk mit dem GET Paramter vorbei ist. Schätzungsweise, weil das Cookie dann bereits gesetzt ist. Ist halt etwas blöd, wenn eine Suchmaschinenbot morgens mal reinschaut, natürlich keine Cookies akzeptiert und grundsätzlich auch keine GET Paramter als URL Anhang mag. Hat jemand von Euch eine Idee, was da schief läuft? Könnt ihr das nachvollziehen?
…oder anders gefragt: Wenn ich den geleerten SEO Cache per Cron nachts selbst wieder aufbaue, ist das Problem dann weg? Es scheint ja so zu sein, dass der Cache geleert wird, sich aber erst bei Benutzung durch User wieder füllt. Hat daher das Dokument für die 3.0.5 auch Gültigkeit für die 3.5.1?: http://www.shopware.de/wiki/Auslagerung … l_510.html Ich kämpfe nämlich gerade mit den Änderungen der SEF URLs. Wenn ich etwas ändere und den Shopcache leere, bekomme ich danach trotzdem ganz wildes Verhalten (z.B. leitet sich die Startseite per 301 redirect auf eine Unterkategorie um). Eine Nacht drüber schlafen und wie von Zauberhand geht es wieder so, wie ich es eingestellt hatte. Das ist aber kein probates Mittel, wenn man am Testen/Aufbauen ist.
[quote=“tschersich”] - Aufruf meiner Shop-Startseite http://www.foo.bar/ - Startseite wird geladen - Im Browser wird Cookie SHOPWARESID mit Inhalt z.B. m60bvg2pn4j87jrc0j1sjkhcg7 gesetzt - Das Hovern (nicht klicken!) über jeden beliebigen Link der Startseite hat jetzt den Cookie-Wert als GET Parameter anhängen: http://www.foo.bar/?sCoreId=m60bvg2pn4j87jrc0j1sjkhcg7 - Der Klick auf z.B. das Logo und damit der erneute Aufruf der Startseite hat dann auch wie erwartet ohne ein 30x Redirect leider folgende URL: http://www.foo.bar/?sCoreId=m60bvg2pn4j87jrc0j1sjkhcg7 - Beim erneuten Hovern über die Links stellt man dann glücklicherweise fest, dass der Spuk mit dem GET Paramter vorbei ist. Schätzungsweise, weil das Cookie dann bereits gesetzt ist. Ist halt etwas blöd, wenn eine Suchmaschinenbot morgens mal reinschaut, natürlich keine Cookies akzeptiert und grundsätzlich auch keine GET Paramter als URL Anhang mag. Hat jemand von Euch eine Idee, was da schief läuft? Könnt ihr das nachvollziehen?[/quote] Wo wir in einem anderen Faden gerade bei der Burda-Website waren: Dort besteht das Problem mit der sCoreId bei Erstaufruf auch: http://collection.burdastyle.de/?sCoreI … 692d500f7c Auch Mabito.com com hat das Problem bei den Links, wenn auch nicht beim Logo: 1. Aufruf, hovern über “Gasgrills”: http://www.mabito.com/Gasgrills_cat_164 … 3dggt.html 2. Aufruf (Seite neu geladen): http://www.mabito.com/Gasgrills_cat_164.html Google kennt mittlerweile auch schon ein gutes dutzend meiner identischen Seiten mit unterschiedlicher sCoreId, obwohl ich es in den Webmaster Tools als unnötigen GET Parameter angegeben haben. Scheint nicht wirklich zu wirken. Es kann sich doch letztlich “nur” um eine fehlende Rewrite Rule in der .htaccess handeln, oder?
Hi tschersich, in Shopware ist eine Erkennung drin, damit für Bots keine Session gestartet wird. (Siehe: Grundeinstellungen/System/Bot-Liste) Dadurch bekommt z.B. Google nur die Links ohne “sCoreId” zu gesicht. Für den Fall, wenn Google doch mal einen Link mit einer CoreID bekommt, gibt es ein sogenannten Canonical-Tag auf vielen Shopware-Seiten. In diesem Canonical-Tag wird eine Haupt-Url hinterlegt, diese nutzt dann Google statt der Url mit der SessionId. Ich kann daher nicht nachstellen, wo das Problem bei dir liegt. Kannst du mir daher einmal die Domain des Shop mitteilen, damit ich mir das genauer anschauen kann? Viele Grüße Heiner
URL habe ich Dir per PN geschickt. Es ist doch aber grundsätzlich keine sonderlich gute Idee, die Session ID-Vergabe als GET Parameter in der URL zu übergeben und diese damit zu verunstalten und dann hinterher mit einer Bot-Liste abzugleichen, ob man den Parameter anzeigen und eine Session starten soll oder nicht. Das setzt auch voraus, dass ich ständig Überblick über die namen in der Bot-Liste haben muss und dass diese immer vollständig ist. Session Cookies lassen sich auch oder gerade ohne URL Parameter setzen. Das bekommen fast alle anderen PHP Applikationen mit Session-Management deutlich eleganter hin.
Hi tschersich, standardmäßig verwendet auch Shopware keine SessionID in der Url. Es gibt halt nur ein Fallback, wenn keine Cookies gesetzt sind. Das Problem sind bei dir die Ajax-Links. Diese haben, damit die Session nicht verloren geht, immer eine SessionID angehängt. Das sollte eigentlich kein Problem sein, da es sich ja nur um Ajax-Links handelt. Google erkennt das aber nicht und indexiert diese Links trotzdem. Mit der Shopware 3.5.3 wurde das Problem aber schon teilweise gelöst. Die ensprechenden Seiten haben nun ein Robots-Nofollow Attribut. Die Ajax-Links (siehe Quelltext): jQuery.controller = { 'ajax\_cart': 'https://www.shop.de/checkout?sCoreId=ejplidt8iea48vqlomn4n6sha7', 'ajax\_search': '/ajax\_search', 'ajax\_login': 'https://www.shop.de/account/ajax\_login', 'register': 'https://www.shop.de/register?sCoreId=ejplidt8iea48vqlomn4n6sha7', 'checkout': 'https://www.shop.de/checkout?sCoreId=ejplidt8iea48vqlomn4n6sha7', 'ajax\_logout': 'https://www.shop.de/account/ajax\_logout?sCoreId=ejplidt8iea48vqlomn4n6sha7', 'ajax\_validate': 'https://www.shop.de/register?sCoreId=ejplidt8iea48vqlomn4n6sha7' }; Das Problem kannst du aber auch schnell selber lösen, indem du in den SEO-Einstellungen die Seiten in der Einstellung “SEO-Nofollow Viewports” hinterlegtes. Vorher: login,ticket,tellafriend,note,support,basket,admin,registerFC,newsletter,search Nacher: login,ticket,tellafriend,note,support,basket,admin,registerFC,newsletter,search,account,checkout,register Viele Grüße Heiner
Also die Bots erhalten auch beim ersten Aufruf keine CoreID / SessionID - also auch nicht an die URls angehängt … Das ist wirklich nur für die normalen Shop-Besucher. Technisch kann man erst beim zweiten Request feststellen, ob das Cookie erfolgreich gesetzt wurde - deshalb muss beim ersten Request die ID übermittelt werden - die Sessionbasierten Systeme die du beschreibst, haben vermutlich garkeinen Non-Cookie Support 
[quote=„Stefan Hamann“]Also die Bots erhalten auch beim ersten Aufruf keine CoreID / SessionID - also auch nicht an die URls angehängt … Das ist wirklich nur für die normalen Shop-Besucher. Technisch kann man erst beim zweiten Request feststellen, ob das Cookie erfolgreich gesetzt wurde - deshalb muss beim ersten Request die ID übermittelt werden - die Sessionbasierten Systeme die du beschreibst, haben vermutlich garkeinen Non-Cookie Support ;)[/quote] Ich habe die Shop URL mal über die Webmaster Tools Google bekannt gemacht und obwohl ich im Shop momentan nur ca. 10 zu indizierende Seiten habe und obwohl ich Google diesen Parameter als nicht zu beachtend bekannt gemacht habe, „kennt“ Google bereits 267 URLs meiner Site und das sind 240 mal Duplikate mit einer Session ID als GET Parameter. Die Bot-Einstellungen habe ich nie angefasst und der googlebot steht auch drin. Die sessionbasierten Systeme, die ich kenne, haben keinen Fallback für Nutzer, die ihre Cookies ausgeknipst haben, das ist richtig. Die machen bei SEF URLs aber auch keinerlei Stress. [quote=„rocky“]Das Problem kannst du aber auch schnell selber lösen, indem du in den SEO-Einstellungen die Seiten in der Einstellung „SEO-Nofollow Viewports“ hinterlegtes. Vorher: login,ticket,tellafriend,note,support,basket,admin,registerFC,newsletter,search Nacher: login,ticket,tellafriend,note,support,basket,admin,registerFC,newsletter,search,account,checkout,register[/quote] Das habe ich eben geprüft. Die drei zusätzlichen Viewports waren bereits hinterlegt. War das eine Änderung von 3.5.2 auf 3.5.3?
[quote=“Stefan Hamann”]Also die Bots erhalten auch beim ersten Aufruf keine CoreID / SessionID - also auch nicht an die URls angehängt [/quote] Kleiner Zusatz: Ich habe mir mal den HTTP-Header der Antwort (Response Header) angesehen, der bei den Webmaster Tools unter “Abruf wie durch Googlebot” angezeigt wird. Hier wird definitiv versucht, ein Cookie zu setzen: (..) Set-Cookie: SHOPWARESID=s2ona5j6au8t23djodr532a8c1; path=/; domain=.foo.bar.com (..) Sieht für mich so aus, als würde Shopware den Bot nicht erkennen.
Okay, das sind dann wahrscheinlich alles URLs die auf die Empfehlungen (Recommendations) verweisen, oder? Dazu hatte Heiner ja bereits was geschrieben. Die Adressen sind im Javascript codiert und wurden bis vor kurzem garnicht durch Google indiziert - durch das Update auf 3.5.3 sollte sich das Problem aber erledigt haben, da dort die beteiligten Controller ja auf die Blacklist gesetzt wurden. [quote] Die sessionbasierten Systeme, die ich kenne, haben keinen Fallback für Nutzer, die ihre Cookies ausgeknipst haben, das ist richtig. Die machen bei SEF URLs aber auch keinerlei Stress. [/quote] Das eine hat mit dem anderen nichts zu tun - das Problem ist hier nicht die Session-ID als solches, sondern die Erfassung der Javascript / Ajax-Links durch Google - das ist aber wie gesagt in 3.5.3 erledigt! Du kannst übrigens das Anhängen der coreID auch komplett verhindern, einfach folgendes ausführen und danach den Config-Cache leeren: UPDATE `s_core_config` SET `value` = '1' WHERE `s_core_config`.`name` = 'sDONTATTACHSESSION';
Das kann durchaus sein, das dürfte aber doch egal sein? Relevant ist doch, dass in diesem Fall keine SessionID an die URLs angehängt werden, die der Bot zu sehen bekommt?
[quote=“Stefan Hamann”]Das eine hat mit dem anderen nichts zu tun - das Problem ist hier nicht die Session-ID als solches, sondern die Erfassung der Javascript / Ajax-Links durch Google - das ist aber wie gesagt in 3.5.3 erledigt! Du kannst übrigens das Anhängen der coreID auch komplett verhindern, einfach folgendes ausführen und danach den Config-Cache leeren: UPDATE `s_core_config` SET `value` = '1' WHERE `s_core_config`.`name` = 'sDONTATTACHSESSION'; [/quote] Das ist doch mal eine schöne Sache! Herzlichen Dank, probiere ich aus! Wenn jetzt noch die 404er-Logik richtig funktionieren würde, wäre ich fast glücklich