Bestellung aktualisiert last_modified NICHT

[Haina]

modified eCommerce Shopsoftware 1.05

Das Feld last_modified in der table products wird z.B. aktualisiert wenn man den Bestand von Hand ändert, nicht aber bei einer Kundenbestellung, obwohl dies genau das selbe ist. Denke es handelt sich dabei um einen alten XTC-Bug, denke da wurde was nicht zu Ende gedacht, denn ganau dafür ist ja das Feld last_modified (nicht gleichzusetzen mit der letzten Version der modified eCommerce Shopsoftware    ) ja gemacht.

Hat man dann eine elegante Routine zum Bestandsabgleich indem man nicht den kompletten Bestand mit vielen tausend Artikel aktualisiert sodern z.B. nur die 50 Artikel die sich in den letzten 2 Tagen geändert haben kommt es natürlich zu Fehlern da nur manuelle Bestandsänderungen, nicht aber Bestellungen berücksichtigt werden.

Der Bugfix ist relativ kurz und einfach:

BugFix beim Bestandsabgleich - Feld last_modified auch bei Bestellungen mit aktualisieren in Datei \checkout_process.pgp ca. Z. 180

Code: PHP  [Auswählen]

 // shs in table Products Feld last_modified mit aktualisieren...   einsetzen in folgender Zeile nach .$stock_left."' :       ,products_last_modified = NOW()    - sieht dann so aus ..
                        xtc_db_query("update ".TABLE_PRODUCTS." set products_quantity = '".$stock_left."',products_last_modified = NOW() where products_id = '".xtc_get_prid($order->products[$i]['id'])."'");
 

Hoffe das fließt generell mit in modified eCommerce Shopsoftware ein.
Gruß



Linkback: https://www.modified-shop.org/forum/index.php?topic=9527.0

[web28]

Das Feld last_modified in der table products wird aktualisiert wenn man irgend etwas am Artikel verändert.

Und genauso verstehe ich dieses Feld auch. Mit dem Bestand kann ich das nicht in Verbindung bringen, das ist mir zu speziell. Es gibt auch viele Shops bei denen der Bestand überhaupt keine Rolle spielt und dieses Feld für Preisänderungen wichtig ist

Man könnte aber z.B. ein neues Feld products_last_sell einführen.

Gruss Web28

[Tomcraft]

Ja, ich verstehe das Feld ehrlich gesagt auch so wie Web28.

Grüße

Torsten

[Haina]

Danke für Euer Feedback, aber ich teile da Eure Meinung nicht.

Wenn sich der Bestand ändert, dann ist das eben irgend etwas !

Wenn sich ein Datensatz ändert dann ist es doch egal welches Feld sich ändert.
On das eine Zahl ist oder ein Text, vollkommen egal. Es hat sich was geändert und das
sollte im Feld last_modified dokumentiert werden.

Da gibt es nur JA oder NEIN, ist wie Binärcode, da gibts auch nur 0 oder 1 und nicht 0,5 oder "vielleicht". Nur auf der Logig kann man sauber weiterführende Logiken aufbauen.

Auch das Argument "Bestand ist ja nicht so wichtig ...etc." - aber Hallo, für manche ist der Shop Ihre WaWi.

Ein neues Feld einzuführen erscheint mir unlogisch. Das bestehende Feld last_modified bezieht sich auf den jeweiligen Datensatz und wenn dieser verändert wurde sollte das genau dort dokumentiert werden.

 

[franky_n]

Tach Zusammen,

ganz ehrlich?
Löscht das Feld einfach!

Die meisten Shopbetreiber interessiert:
- Was für ein Produkt wann gekauft wurde (inkl. Lagerbestandsänderung)
- Welches Produkt wann von wem und in welcher Form geändert wurde (vorausgesetzt man hat noch Mitarbeiter die ebenfalls Produkte pflegen)

Das Feld sagt aus: "Es ist was geändert suche selber raus was es ist! Viel Spaß dabei!"

Da lob ich mir das Logging, was vielleicht demnächst mal kommen wird!

Viele Grüße

Franky

[xMerchant]

Das Feld bitte drin lassen, es wird für die sitemap.xml gebraucht. In der sitemap.xml steht drin, wann die Seite hinter dem Link zuletzt geändert wurde, damit Google und Co. die jüngsten Aktualisierungen priorisiert crawlen.
Damit macht es auch keinen Sinn, bei Mengenänderungen den Timestamp zu ändern, weil die sich nicht auf den Seiteninhalt der Produktbeschreibung auswirken.

Ich könnte mir durchaus vorstellen, dass man bei Google sogar abgestraft wird, wenn zu viele Seiten mit Änderungen per sitemap.xml gemeldet werden und Google keinen Unterschied zur gespeicherten Seite feststellen kann.

@enricosh:
Füge doch einfach eine eigene Spalte in die TABLE_PRODUCTS ein, an der Du erkennst, dass sich der Bestand verändert hat. Das habe ich bei mir auch so gelöst, damit ist man dann auch unabhängig von sonstigen Ereignissen, die den lastmodified-Timestamp ändern.

[franky_n]

Hi xMerchant,

das war eigentlich ein Scherz mit dem Löschen, aber Du hast Recht.
Es wird noch in der Sitemap genutzt, auch wenn ich da jetzt ehrlicherweise nicht drüber nachgedacht habe...

Viele Grüße

Franky

[Haina]

Hallo xMerchant,
danke für Deinen Beitrag.
DAS ist tatsächlich ein schlüssiges Argument.

Aber bei manuellen Änderungen, und sei es nur neuer Wareneingang bei dem das Mengenfeld aktualisiert wird, ändert sich der Timestamp ja sowieso und ne Sitemap macht man ja im Schnitt einmal im Monat, also werd ich das erst mal so lassen das dieses Feld bei Verkäufen mit aktualisiert wird.

Wünsch Dir ne schöne Vorweihnachtszeit.
Bei uns in bayrisch Sibirien hats letzte Nacht schon wieder 10 cm runter von dem weissen Zeugs, tagsüber nochmal, es liegt nun so ein halber Meter hoch Schnee - und es schneit weiter.
Sieht richtig toll aus wenn man aus dem Wintergarten guckt und hinter einem der Kachelofen schön heizt.
 

  [ Für Gäste sind keine Dateianhänge sichtbar ]