Hi! Ist es in irgendeiner Form möglich, selbst eine Instanz von sOrder zu erstellen und diese halbwegs elegant mit Daten zu füttern? Oder noch besser: Gibt es irgendwo im Core eine Methode, welche ein sOrder-Object anhand z.B. einer order_id oÄ. erstellt? Danke und viele Grüße, Fabian
Hi, was genau hast du denn vor? Grundsätzlich wird die sOrder als Singleton über Shopware()->Modules()->Order gehandelt. Theoretisch kannst du dir zwar eigene Instanzen erzeugen, aber das ist eher unüblich. Eigentlich wird die Klasse auch nur für die Bestellanlage genutzt, für die Bearbeitung bestehender Bestellungen gibt es da wenig - mit Ausnahme der Methoden \sOrder::setPaymentStatus oder \sOrder::setOrderStatus, die vll. einen Blick wert wären, wenn du sowas brauchst. Daniel
Hi! Danke für die Antwort. Zu deiner Frage: Arbeite derzeit in meinem Plugin mit verschiedenen Events, die alle sOrder als Argument übergeben, welches dann von meinen Funktionen weiterverarbeitet wird. War auf der Suche nach dem Event, dass ausgelöst wird, wenn sich der Bestell- bzw. Zahlungsstatus einer Bestellung ändert. Leider konnte ich nur das Doctrine-PostUpdate Event finden. Daraus kann ich aber nur eine Bestellnummer ziehen. Der Einheitlichkeit zugunsten würde ich daraus gern ein sOrder erzeugen. Oder gibt es ein anderes Event, dass dieses gleich mitbringt? Bedingungen: Event wird getriggert, sobald sich die Bestellung (insbes. der Zahlungsstatus) ändert. Sowohl von Payment-Plugins (Paypal IPN,…) aber auch z.B. über das Backend Viele Grüße, Fabian
Hi, da musst du verschiedene Ansätze kombinieren. Für die Änderungen über das Frontend durch Plugins etc. würde ich einen Hook auf die beiden Methoden sOrder::setPaymentStatus und \sOrder::setOrderStatus setzen. Gleichzeitig wäre noch ein Hook auf die Methode saveOrder im Payment-Frontend-Controller denkbar, der wird auch von vielen Zahlarten genutzt, läuft intern aber eigentlich auch in die sOrder::setPaymentStatus bzw. \sOrder::setOrderStatus. Für Änderungen über das Backend brauchst du einen Lifecycle-Subscriber auf das Order-Model, sowas benutzen wir ja auch für unsere Order-History. Damit sind dann auch direkt Änderungen erfasst, die über die API kommen. In allen genannten Fällen hast du ja dann die orderId zur Verfügung und kannst dir alle weiteren nötigen Daten aus der DB holen, das kann man sicher relativ schön generalisieren. besten Gruß, Daniel