Hallo,
ich habe das Problem, dass durch die verzögerte Generierung der URL doppelte Eintrage entstehen. Dies ist vor allem beim RSS Export zu Twitter, facebook (und von da zu zahlreichen andern Seiten) lästig. Das gleiche Produkt wird zweimal gelistet, da ein neuer Eintrag entsteht, wenn über Nacht die reguläre URL generiert wird...
Lösung?
Das mit der Verzögerung der RSS wäre nur eine Teillösung, da auch andere Exporte generiert werden, die zuerst mit der provisorischen URL, am nächsten Tag dann mit der regulären URL ausgeliefert werden.....
PS: Grundsätzlich hilfreich wäre auch, dass beim ersten genieren der URL keine Änderung mehr passiert. Also wenn ich den Title ändere (z.B. schriebfehler) sich die URL nicht mit ändert.... ich hab sonst immer und immer wieder Links, die ins Nirvana laufen, wenn irgendjemand am titel arbeitet...
ich habe das Problem, dass durch die verzögerte Generierung der URL doppelte Eintrage entstehen. Dies ist vor allem beim RSS Export zu Twitter, facebook (und von da zu zahlreichen andern Seiten) lästig. Das gleiche Produkt wird zweimal gelistet, da ein neuer Eintrag entsteht, wenn über Nacht die reguläre URL generiert wird...
Lösung?
[li]Die URL wird beim erstmaligen Freischalten des Produktes generiert, d.h. die Engine wird angestoßen[/li]
[li]Die RSS-Feeds werden mit einem Tag Verzögerung ausgeliefert[/li]
Das mit der Verzögerung der RSS wäre nur eine Teillösung, da auch andere Exporte generiert werden, die zuerst mit der provisorischen URL, am nächsten Tag dann mit der regulären URL ausgeliefert werden.....
PS: Grundsätzlich hilfreich wäre auch, dass beim ersten genieren der URL keine Änderung mehr passiert. Also wenn ich den Title ändere (z.B. schriebfehler) sich die URL nicht mit ändert.... ich hab sonst immer und immer wieder Links, die ins Nirvana laufen, wenn irgendjemand am titel arbeitet...
Den ersten der beiden Vorschläge halte ich für sehr gut:
- Generieren der URL beim erstmaligen aktivieren Real-time nur für diesen Artikel, damit werden auch Änderungen im Title solange er deaktiviert bleibt irrelevant!
Wäre eine prima Lösung!
Anmerkung zum PS, dazu hätte ich noch einen erweiterten Vorschlag :
Bei jeder Änderung eines aktiven Artikels im Artikelnamen eine 301-Weiterleitung automatisch auf die neue URL generieren, ist sauberer da sich der Artikelname bei Änderung entweder aus SEO Gründen oder wegen einer korrekteren/lesbaren Schreibweise ändert.
- Generieren der URL beim erstmaligen aktivieren Real-time nur für diesen Artikel, damit werden auch Änderungen im Title solange er deaktiviert bleibt irrelevant!
Wäre eine prima Lösung!
Anmerkung zum PS, dazu hätte ich noch einen erweiterten Vorschlag :
Bei jeder Änderung eines aktiven Artikels im Artikelnamen eine 301-Weiterleitung automatisch auf die neue URL generieren, ist sauberer da sich der Artikelname bei Änderung entweder aus SEO Gründen oder wegen einer korrekteren/lesbaren Schreibweise ändert.
OK, werden uns drum kümmern, dass die Generierung direkt mit speichern des Blog-Beitrags passiert!
Was ich nicht anbieten kann ist, dass der Titel geändert werden kann und die URL bleibt. Sorry, aber da es wahrscheinlich nur selten passiert, dass man einen Titel im Nachhinein ändert, lohnt der Aufwand nicht, der bedeuten würde, dass wir sogar die Tabelle dafür erweitern müssten..
Finde der Titel eines Beitrag kann auch vor dem Speichern so gut überlegt sein, dass man ihn nicht ändern muss. Ich glaube hier im Forum habe ich bei den 1.000 Beiträgen die ich geschrieben habe 2 mal den Titel kurz nach dem Speichern geändert.. Zitat dstoll : 'we have bigger fish to catch'
zum ps: Siehe www.powergap.de/forum/index.php?topic=1148, technisch natürlich machbar das bei einer Änderung des Artikelnamens zu generieren. Sicher nur ca. 1-2 Stunden Aufwand es zu entwickeln. Ich würde es von uns aber nicht anbieten, da Artikelnamen-Änderungen sicher öfter passieren und wir damit diese Tabelle dann in allen Shops aufbauschen. Diese Tabelle wird bekanntlich bei jedem Klick im Shop durchsucht und würde damit über alle Shops gesehen Performance kosten. Shopbetreibern mit eigenen Servern würden wir es natürlich programmieren können.
Ich finde jedoch, hier kann man sich der eben genannten Funktion bei Bedarf manuell bedienen, wenn es denn bei einem Artikel so wichtig ist den Artikelnamen zu ändern. Und wenn man eben weiß, dass die Änderung des Artikelnamens diese Folgen hat, dann kann man ja auch abwegen, ob es denn wirklich nötig ist.
Solche Anforderungen erinnern mich immer daran, dass man versucht die "Wirkung", aber nicht die "Ursache" abzustellen. Wie bei Medikamenten, wo jeder weiß, dass es nach Einnahme wieder neue Nebenwikkungen gibt. In dem Fall sollte also dem jenigen auf die Finger geklopft werden, der einen Artikel mit einem unsinnigen Artikelnamen anlegt >:D, ober anders gesagt, besser ein Kondom als die Pille danach..
Was ich nicht anbieten kann ist, dass der Titel geändert werden kann und die URL bleibt. Sorry, aber da es wahrscheinlich nur selten passiert, dass man einen Titel im Nachhinein ändert, lohnt der Aufwand nicht, der bedeuten würde, dass wir sogar die Tabelle dafür erweitern müssten..
Finde der Titel eines Beitrag kann auch vor dem Speichern so gut überlegt sein, dass man ihn nicht ändern muss. Ich glaube hier im Forum habe ich bei den 1.000 Beiträgen die ich geschrieben habe 2 mal den Titel kurz nach dem Speichern geändert.. Zitat dstoll : 'we have bigger fish to catch'
zum ps: Siehe www.powergap.de/forum/index.php?topic=1148, technisch natürlich machbar das bei einer Änderung des Artikelnamens zu generieren. Sicher nur ca. 1-2 Stunden Aufwand es zu entwickeln. Ich würde es von uns aber nicht anbieten, da Artikelnamen-Änderungen sicher öfter passieren und wir damit diese Tabelle dann in allen Shops aufbauschen. Diese Tabelle wird bekanntlich bei jedem Klick im Shop durchsucht und würde damit über alle Shops gesehen Performance kosten. Shopbetreibern mit eigenen Servern würden wir es natürlich programmieren können.
Ich finde jedoch, hier kann man sich der eben genannten Funktion bei Bedarf manuell bedienen, wenn es denn bei einem Artikel so wichtig ist den Artikelnamen zu ändern. Und wenn man eben weiß, dass die Änderung des Artikelnamens diese Folgen hat, dann kann man ja auch abwegen, ob es denn wirklich nötig ist.
Solche Anforderungen erinnern mich immer daran, dass man versucht die "Wirkung", aber nicht die "Ursache" abzustellen. Wie bei Medikamenten, wo jeder weiß, dass es nach Einnahme wieder neue Nebenwikkungen gibt. In dem Fall sollte also dem jenigen auf die Finger geklopft werden, der einen Artikel mit einem unsinnigen Artikelnamen anlegt >:D, ober anders gesagt, besser ein Kondom als die Pille danach..
Es ist so weit, ich führe jetzt mal Selbstgespräche: 
Lieber Robert,
wer lesen kann ist klar im Vorteil. Denn hier meint Rasenmäher nicht den shopinternen Blog, sondern die Artikelanlage!
Beim Stichwort RSS hatte ich an Blog-News gedacht. Beim Blog haben wir ja so eine Generierungs-Möglichkeit eingebaut. Blog-Beiträge werden auch im Vergleich zu den Artikeln selten erfasst oder gar geändert. Bei Artikeln kann ich das aus Gründen der DB-Performance nicht anbieten. Es tut mir leid.
Hintergrund: die DHE-Tabelle (also da wo die schönen .html-Endungen zu allen Seiten des Systems gespeichert sind) ist bei einigen Shops schon sehr groß. Abhängig von der Anzahl Artikel, Kategorien, Sprachen usw.. Bei Vinexus z.B. aktuell 80.727 Einträge! Die Tabelle wird bei "jedem" Klick eines Besuchers durchforstet um eben zu erfahren, z.B. welcher Artikel nun angezeigt werden soll.
Damit das performant passiert, sorgt der sogenannte MySQL-Cache dafür, dass die meisten Anfragen direkt aus dem RAM beantwortet werden. Klickt ein Besucher auf eine AUG, dann holt die DB-Engine die Information "ein Mal" von der Festplatte (langsam) und ab dem nächsten Besucher dann aus dem RAM (irre schnell). Bei einer Änderung der Tabelle wird dieser Cache geleert. Sprich der Geschwindigkeits-Vorteil geht verloren. Das ist auch der Grund, warum diese DHE-Tabelle von uns auch nur nachts aufgefrischt wird. Denn auch dabei geht der Cache natürlich verloren. Morgens ist mit den ersten Besuchern das System (was die DHE-Engine angeht) also mehr belastet, bzw. wird tagsüber immer schneller.
Der Vorschlag:
ist tatsächlich die einzige Möglichkeit hier nachzubessern. Bzw. wir könnten RSS-Feed-Exporte so umprogrammieren, dass Artikel immer nur dann exportiert werden, wenn diese eine DHE-URL (mit .html-Endung) besitzen. Schon wäre das Thema erledigt. Bitte um Info, ob ich das so umschreiben soll. Wäre in 2 Minuten erledigt..
Lieber Robert,
wer lesen kann ist klar im Vorteil. Denn hier meint Rasenmäher nicht den shopinternen Blog, sondern die Artikelanlage!
Beim Stichwort RSS hatte ich an Blog-News gedacht. Beim Blog haben wir ja so eine Generierungs-Möglichkeit eingebaut. Blog-Beiträge werden auch im Vergleich zu den Artikeln selten erfasst oder gar geändert. Bei Artikeln kann ich das aus Gründen der DB-Performance nicht anbieten. Es tut mir leid.
Hintergrund: die DHE-Tabelle (also da wo die schönen .html-Endungen zu allen Seiten des Systems gespeichert sind) ist bei einigen Shops schon sehr groß. Abhängig von der Anzahl Artikel, Kategorien, Sprachen usw.. Bei Vinexus z.B. aktuell 80.727 Einträge! Die Tabelle wird bei "jedem" Klick eines Besuchers durchforstet um eben zu erfahren, z.B. welcher Artikel nun angezeigt werden soll.
Damit das performant passiert, sorgt der sogenannte MySQL-Cache dafür, dass die meisten Anfragen direkt aus dem RAM beantwortet werden. Klickt ein Besucher auf eine AUG, dann holt die DB-Engine die Information "ein Mal" von der Festplatte (langsam) und ab dem nächsten Besucher dann aus dem RAM (irre schnell). Bei einer Änderung der Tabelle wird dieser Cache geleert. Sprich der Geschwindigkeits-Vorteil geht verloren. Das ist auch der Grund, warum diese DHE-Tabelle von uns auch nur nachts aufgefrischt wird. Denn auch dabei geht der Cache natürlich verloren. Morgens ist mit den ersten Besuchern das System (was die DHE-Engine angeht) also mehr belastet, bzw. wird tagsüber immer schneller.
Der Vorschlag:
Die RSS-Feeds werden mit einem Tag Verzögerung ausgeliefert
ist tatsächlich die einzige Möglichkeit hier nachzubessern. Bzw. wir könnten RSS-Feed-Exporte so umprogrammieren, dass Artikel immer nur dann exportiert werden, wenn diese eine DHE-URL (mit .html-Endung) besitzen. Schon wäre das Thema erledigt. Bitte um Info, ob ich das so umschreiben soll. Wäre in 2 Minuten erledigt..
bitte umschreiben. 120,119, 118, 117..... sek ;D
.. 3, 2, 1, Deins
supi, Danke!
PS: Das mit einem Tag Verzögerung hat auch den Vorteil, dass wir als urheber der RSS "news" bei Google gelten.
(Jaja, ich hab früher mein geld damit verdient google-news zu bescheissen, indem wir spielberichte schon vor spielende ins netz gestellt haben )
PS: Das mit einem Tag Verzögerung hat auch den Vorteil, dass wir als urheber der RSS "news" bei Google gelten.
(Jaja, ich hab früher mein geld damit verdient google-news zu bescheissen, indem wir spielberichte schon vor spielende ins netz gestellt haben
)