ich teste gerade ein Plugin in der 5.7 RC1 und kann das Theme nicht mehr kompilieren nachdem ich ein Plugin installiert habe (bereits bei der Installation des Plugins will das theme kompiliert werden). Es erscheint folgende Fehlermeldung:
Während der Bearbeitung von Shop "Deutsch" ist ein Fehler aufgetreten: The "prefix_plugin_name.subscriber.subscriber" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.
Ich habe auch andere Plugins aus dem Store getestet. Mit der Version 5.7 RC1 kann ich kein Plugin nutzen. Muss hier jetzt jeder Hersteller nachbessern?
Mir ist nicht klar, was hier bemängelt wird. Meine service.xml sieht folgendermaßen aus:
// Edit: Wenn ich an den service in der services.xml publig=“true” anhänge verschwindet die Fehlermeldung. In der Doku (Plugin services) steht davon aber nichts! Im UPGRADE-5.7.md findest sich ebenfalls nichts dazu.
Ihr müsst eure Plugins fixen. Siehe am besten den Blog Post von Symfony selbst
Mit den Ticket werden Shopware relevante Tags die einen Service public brauchen automatisch auf public gesetzt. Wir werden aber nicht eure eigenen Services ändern.
hmm… $container->get verwende ich in meinen Plugins gar nicht. Ich habe in jedem Subscriber einen Konstruktor für die Services aus der service.xml. Dennoch musste ich alle Services auf public stellen…
Ich greife nur in einem Subscriber auf $service = Shopware()->Container()->get('shopware_attribute.crud_service'); zu. Aber was hat das letztlich mit den Services in meiner service.xml zu tun?
ich habe ebenfalls selbes Problem.
es kann doch nicht sein, dass jetzt jedes Plugin geupdated werden muss, und alle Services als public definiert werden muss.
Das ist eigentlich nicht der Symfony-Weg. Symfony erkennt normalerweise automatisch, dass es sich um einen privaten Service handelt, und behandelt das instanzieren dieses Service dann auch anders.
Hier muss also dringend eine Lösung her.
Viele Plugins werden nicht mehr groß maintained, sind aber noch in vielen Shops noch installiert. Das wäre ein ziemlicher Killer, wenn der Shopbetreiber seinen Shop updaten möchte, aber nicht kann, weil die Services alle nicht mehr instanziert werden können.
Was sagt Shopware allgemein zu diesem Thema @Shyim?
Wird dieses Thema noch für das offiziellen Release angegangen ?
Selbes Problem übrigens auch mit dem von SW registrierten Plugin Logger. Dieser ist ebenfalls als private registriert.
Keine Chance, den PluginLogger zu nutzen, überall krachts.
Wie gesagt Services die von dem Core erstellt werden wie der Plugin Logger, Subscriber etc werden später automatisch auf public gesetzt. Aber komplett eigene Komponenten müsst ihr selber entscheiden ob diese public sein sollen oder nicht.
Jedes Saubere Plugin welches die Dependency Injection richtig benutzt sollte hier gar keine Probleme haben
ich habe auch Kollegen aus dem Symfony Stack in dieses Thema integriert und prüfen lassen.
Auch diese sind der Meinung, dass hier gewaltig etwas schief läuft.
Auch bei korrekter Nutzung der DI funktioniert es nicht korrekt, da der Container immer nach public-Services sucht.
Einen Blick in den generierten Container unter /var/cache/ bestätigt dies.
ich habe die Services wie von dir beschrieben als public markiert. Hier meine services.xml:
<?xml version="1.0" ?>
%name.plugin_dir%
Fatal error : Uncaught Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service „Template“. Did you mean one of these: „template“, „Enlight_Template_Manager“, „Shopware\Bundle\BenchmarkBundle\Service\TemplateCachingHandler“, „Shopware\Bundle\StoreFrontBundle\Gateway\DBAL\Hydrator\TemplateHydrator“, „Shopware\Components\DependencyInjection\Bridge\Template“, „Shopware\Components\DependencyInjection\Bridge\TemplateMail“, „Shopware\Components\Template\HtmlMinCompressor“, „Shopware_Components_TemplateMail“? in */shopwaredemo.*.de/vendor/symfony/dependency-injection/Container.php:289 Stack trace: #0 */shopwaredemo.*.de/vendor/symfony/dependency-injection/Container.php(231): Symfony\Component\DependencyInjection\Container->make(‚Template‘, 1) #1 */shopwaredemo.*.de/engine/Shopware/Components/DependencyInjection/Container.php(210): Symfony\Component\DependencyInjection\Container in /*/shopwaredemo.*.de/vendor/symfony/dependency-injection/Container.php on line 289
hast du eine Idee woran das liegen könnte?
lg
//Fehler gefunden:
Sollte noch jemand in seinen Plugins dieses Konstrukt verwendet haben:
Ebenfalls: Das Legacy Plugin System wird vom Store nicht mehr unterstützt (beim Upload), lauffähig ist das Plugin unter 5.7 trotzdem.
Wie ist da der Stand? Müssen jetzt alle Legacy Plugins für eine Version nachgebaut werden, obwohl sie lauffähig sind? Das wäre natürlich … crazy.
Interessante Frage das zum legacy. Das alte PayPal ist legacy, und es wurde von SW durch Moritz verbindlich im Forum bestätigt, dass das bis zur letzten SW5 Version supported wird.
Hallo zusammen, nach dem Update von Shopware 5.6 auf 5.7 gab es eines unserer Plugins welches nicht mehr aktualisiert wird und genau diese Fehlermeldung ausgibt:
The "hp_order_export_service" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.
Nachdem ich in der services.xml des Plugins beim betreffenden Service ‚public=„true“‘ hinzugefügt habe funktioniert das Plugin wieder. Allerdings bin ich mir nicht ganz sicher welche Auswirkungen das haben könnte. Etwas das eigentlich Privat ist, auf Public zu schalten scheint mir rein intuitiv erstmal keine Gute Idee.
Kann mir vielleicht jemand erklären was das in diesem Kontext zu bedeuten hat?
Oder war der Service eventuell vorher schon by default public und seit Shopware 5.7 ist die default Einstellung einfach private und man muss nun explizit den Service auf public schalten?