Hab mal eine Verständnis-Frage.
Wenn man den SEO-Index manuell neu aufbaut, weil z.B. neue Artikel hinzugekommen sind, warum werden dann in der Datenbank unter s_core_rewrite_urls die IDs für bestehende Einträge geändert?
Unsere Hauptkategorien hatten stets niedrige, 2stellige IDs, weil es sie schon ewig gibt. Seit kurzem sind diese IDs im mittleren 6stelligen Bereich.
Ist nichts schlimmes, möchte es nur verstehen.
Hat jemand eine Erklärung dafür?
Keiner eine dee?
Oder mache ich was falsch, um die URLs neuer Artikel zu generieren?
Generell werden bei neuen Artikeln die URLs direkt erzeugt, wenn man den Seo Cache leert. Shopware hat ja das Datum des letzten Durchlaufs und und prüft / aktualisiert alles, was neuer ist. Manuellen lauf braucht man da eigentlich nie im Betrieb. Der wurde eher dafür gemacht, nach einer URL Aufbauänderung alles upzudaten.
zur Frage ID: welche ID meinst du? SEO URL ID oder die ID der Kategorie?
Sebastian
Generell werden bei neuen Artikeln die URLs direkt erzeugt, wenn man den Seo Cache leert. Shopware hat ja das Datum des letzten Durchlaufs und und prüft / aktualisiert alles, was neuer ist. Manuellen lauf braucht man da eigentlich nie im Betrieb. Der wurde eher dafür gemacht, nach einer URL Aufbauänderung alles upzudaten.
zur Frage ID: welche ID meinst du? SEO URL ID oder die ID der Kategorie?
Sebastian
Kann ich nicht bestätigen, wir müssen jedesmal manuell die SEO URL neu aufbauen. Cache leeren allein reicht da nicht aus, oder ist da bei den neuen Versionen anders?
Die ID des DB-Eintrage in s_core_rewrite_urls meine ich.
Wie gesagt, es ist nicht wirklich wichtig, wollte nur verstanden haben, was da passiert.
Ich werd es dann mal ohne manuelle Generierung veruchen und nur den SEO-Cache leeren, wenn ich neue Artikel aktiviere.
Kann man die IDs der Einträge in s_core_rewrite_urls eigentlich „zurücksetzen“?
Hi,
das war schon immer so (seit shopware 3.0.5).
Daher gibt es ja extra das Datum, wann der Seo Index letztmalig lief. Leert man den Seo Cache manuell werden nur neue URLs hinzugefügt. Das passiert sonst auch automatisch, wenn Seo Cache Intervall abgelaufen ist (im Standard 24h).
Klappt das bei euch nicht, ist was im Ablauf nicht korrekt oder irgendwas anderes klemmt in er Umgebung.
Es kann natürlich sein, dass du im Frontend die neue url noch nicht siehst, da durch den Produktivmodus (httpCache) ganze Seite gecacht werden. Der Cache müsste dann ggf. auch aktualisiert werden.
Generell funktioniert das schon immer so, wie gerade von mir geschrieben. Sonst müsste man da in der jeweiligen Umgebung auf Problemsuche gehen 
Hi,
das war schon immer so (seit shopware 3.5).
Daher gibt es ja extra das Datum, wann der Seo Index letztmalig lief. Leert man den Seo Cache manuell werden nur neue URLs hinzugefügt. Das passiert sonst auch automatisch, wenn Seo Cache Intervall abgelaufen ist (im Standard 24h).
So hatte ich das eigenlich auch in Erinnerung und mir ist noch nie aufgefallen, dass da neue IDs generiert werden.
Ist mir dieser Tage das erste Mal aufgefallen.
Wie eingangs geschrieben:
Unsere Hauptkategorien hatten stets niedrige, 2stellige IDs (die IDs der Einträge in der Tabelle s_core_rewrite_urls, weil es sie schon ewig gibt. Seit kurzem sind diese IDs im mittleren 6stelligen Bereich.
Wir haben kein Plugin am Laufen, das auf diese Einstellungen zugriff hat.
Hast Du die Möglichkeit, dass in Eurem Demoshop zu testen oder in einem eigenen Testshop?
SEO-Index neu aufbauen: manuell und die IDs vorher/nachher vergleichen
Können wir gerne checken. Kann ich so aktuell nicht genau sagen oder prüfen.
Ist das bei dir denn so jedes Mal? Also manueller Aufbau und die ID vorher und nachher checken und dann ist die höher?
Aus dem Kopf würde ich sagen, dass das nicht korrekt ist. Kann aber sein, dass es aus bestimmten Gründen in eine der letzten Versionen eingebaut wurde. Vom Handy kann ich das gerade leider nicht prüfen
Ja, wäre toll, wenn ihr das checken könntet.
Hab’s gerade noch mal in unserem Testshop getestet:
fast alle IDs mit main =1 erhöhen sich nach dem manuellem Neuaufbau vom SEO-Index.
Es gibt noch ein paar Einträge mit main = 1 (52 Stück) wie z.b. sViewport=newsletter, da bleibt die ID gleich.
Komisch.
Einträge mit main = 0 werden nicht angefasst.
Hab einen gelösten Bugeintrag gefunden: Shopware Issuetracker
Kann es damit zusammenhängen?
Das wäre ggf. denkbar. Also das die Aktiven (main 1) entfernt und neu erstellt werden. Inaktive, wichtig für Weiterleitungen mit main=0, bleiben unberührt.
Ich versuche das morgen mal rauszubekommen
Hab mir das gerade mal angesehen, du hast recht, die aktiven URLs werden alle neu erzeugt.
Ich geb das mal intern weiter, warum das so ist.
Hi @simplybecause!
Das Verhalten ist gewünscht. Bei dem Ticket das Du verlinkt hast wurde das Verhalten dahingehend geändert das, während vorher eine einmal bestehende SEO-URL nicht mehr angefasst wurde, diese nun aktualisiert wird. Hier kannst Du die konkrete Änderung sehen: SW-18532 - Fix wrong seo URLs when categories are renamed without rei… · shopware/shopware@845a667 · GitHub
Der Eintrag wird seitdem neu geschrieben um mögliche Änderungen der SEO-URL für eine interne URL auch übernehmen zu können, das erhöht die ID auch wenn nichts geändert wurde.
Viele Grüße
Hendrik
Okay, danke für die Erklärung.
Wollte sicher sein, dass bei uns nicht irgendwas schief läuft.
Wie hoch können die IDs in der Tabelle s_core_rewrite_urls gezählt werden?
Gibt es da Einschränkungen?
Und die Frage, was ich tun muss, damit möglichst schnell die URLs von neu aktivierten Artikeln generiert werden ohne sie über den Button “manuell” neu zugenerieren.
Habe nämlich - wie Vitago - das Gefühl, dass das nicht automatisch funktioniert.
Hallo,
habe das gerade nochmal getestet mit der automatischen Erstellung fehlender URLs sowie mit Cache Löschen.
Das klappt wie oben von mir geschrieben. Es hängt aber mit dem HttpCache zusammen, ob die URL im Frontend dann auch sichtbar ist oder ob die alte URL in der gecachten Seite noch vorliegt.
Folgenden Test habe ich dann noch einmal durchgeführt: Kategorie angelegt und einen Artikel angelegt -> Dann die Cache-Detail/Einstellungen geöffnet und bei den Checkboxen folgendes gesetzt:
Cache dann gelöscht. URLs waren alle dann als SEO-Urls korrekt vorhanden. Wichtig: Es kann sein, dass der http-Proxy-Cache noch einmal geleert werden muss. Da beim ersten Frontend-Aufruf die Seite noch mit dem non-Seo-Link gecacht wird!
VG
Sebastian
Okay, dann werd ich das dann auf dem Weg machen.
Über den “kurzen Weg” Shopcache leeren ging es nämlich nicht.
Das funktioniert bei uns nicht wie von Sebastian beschrieben.
Ich hab jetzt ein halbe Stunde gewartet, aber es tut sich nichts.
[@Vitago GmbH](http://forum.shopware.com/profile/21824/Vitago GmbH “Vitago GmbH”)
Du hattest geschreiben, dass das bei Euch auch nicht funktioniert.
Welche Shopversion nutzt ihr?
Hallo,
der beschrieben Workflow funktionierte bisher wirklich in jeder Version von Shopware.
Dann muss dort ein anderes Problem vorliegen. Ggf. ein Problem mit dem Datum (fehlerhaft oder nicht gesetzt) des Artikels oder mit der Umgebung. Evtl. ist die SEO-URL Erzeugung auch einfach auf Manuell oder Cronjob umgestellt?! Es gibt schon einige Punkte, die da reinspielen können.
Da muss man sich vermutlich den Shop einfach ansehen
Sebastian
In den Performanceeinstellungen steht die Aktualisierungsstrategie auf Cronjob, wie empfohlen. Ist das nicht korrekt?
Das Datum der letzten Aktualisierung steht auf heute, weil ich die URLs jetzt manuell erzeugt habe.
Das funktioniert bei uns nicht wie von Sebastian beschrieben.
- Neu Artikel aktivieren
- Cache wie beschreiben leeren
- Kategorie aufrufen: URL der neuen Artikel wird nicht umgeschrieben
- httpCache erneut leeren
- Kategorie aufrufen: URL der neuen Artikel wird nicht umgeschrieben
- Browsercache leeren, Browser schliessen
- Kategorie aufrufen: URL der neuen Artikel wird nicht umgeschrieben
Ich hab jetzt ein halbe Stunde gewartet, aber es tut sich nichts.
[@Vitago GmbH](http://forum.shopware.com/profile/21824/Vitago GmbH „Vitago GmbH“)
Du hattest geschreiben, dass das bei Euch auch nicht funktioniert.
Welche Shopversion nutzt ihr?
Wir nutzen die Version 5.1.6 
Eben noch einmal getestet, wie von Sebastian beschrieben funktioniert es bei uns nicht. Vielleicht liegt es auch an einen der zahlreichen Plugins oder diversen Änderungen, es stört uns aber nicht wirklich da manuell generieren ja nicht so viel Aufwand ist.
