ich habe ein Plugin geschrieben, welches das order_line_item.repository als service an den Constructor eines Storefront Controllers übergibt. Bei der Installation in unserem Liveshop ist mir aufgefallen, dass das Plugin nicht mehr funktionierte. In den Logs konnte ich lesen, dass das Argument vom Typ EntityRepository erwartet wurde, allerdings wurde Ratepay\RpayPayments\Components\Checkout\Model\Repository\OrderLineItemRepositoryDecorator übergeben.
Offensichtlich wurde das normale order_line_item.repository durch den Decorator ersetzt, nur leider kann ich in der services.xml nicht definieren, ob er das decorated repo oder das normale laden soll. Meine kurzfristige Lösung war es, den Typen den Argumentes im Controller auszutauschen. Das Plugin funktionierte danach wieder, allerdings vermutlich nur, solange auch das Plugin von Ratepay installiert ist.
Gibt es eine Möglichkeit, die undecorated version des order_line_repositories zu verwenden? Wie würde man das normalerweise anstellen? Es kann ja nicht sein, dass die Installation des Ratepayplugins dazu führt, dass einige andere Plugins nichts mehr funktionieren.
Du könntest Mal überprüfen ob der Decorator das EntityRepositoryInterface implementiert. Wenn ja, in deinem Constructor das EntityRepositoryInterface verwenden.
Deprecated, wahrscheinlich wird es erst ab Shopware 6.5. entfernt. Bis dahin sollte das Interface verwendet werden.
Wenn das Drittplugin das Interface verwendet, wirst du keine andere Möglichkeit haben. Und ab Shopware 6.5 müsste das Drittplugin auch angepasst werden.
Shopware nutzt selbst auch noch dekorierte Klassen. Dort geht es auch nicht. Die Dekorierte Klasse müsste dann die Hauptklasse extenden. Aber aktuell ist es noch richtig den Interface zu nutzen.
Das hab ich schon mal gesehen mit einem anderen Plugin und Repo; passiert eben wenn Plugins nicht sauber arbeiten. Man kann sich den ganzen Service Container ausgeben lassen, dort sieht man dann auch, dass einfach die ID überschrieben ist. How to Debug the Service Container & List Services (Symfony Docs)
Theoretisch könnte man statt per Service-ID auch den Pfad zur Klasse angeben, aber die SW-Repositories haben –soweit ich mich erinnere– gar nicht eine eigene Klasse pro Repository. Ist aber schon wieder ne Weile her, dass ich das Problem hatte.
Eine andere Möglichkeit wäre noch falls OrderLineItemRepositoryDecorator eine public-Methode zur Verfügung stellt, um auf den decoratedService also den Original-Service zuzugreifen, aber da müsstest du im Plugin-Code schauen, und wenn das mit ID überschrieben schon nicht sauber ist, dann kann auch gut sein, dass es so eine Methode ebenfalls nicht gibt.
Ich habe das mal als Lösung gekennzeichnet. Tatsächlich verwendet das Drittanbieter Plugin das interface. Ich habe meine Plugin dahingehend umgebaut auch das Interface zu verwenden und habe erstmal kein Problem mehr. Es ist zwar deprecated, aber für den Moment ausreichend