Shopware 5.7 RC1 - Plugins können nicht mehr genutzt werden - viele getestet (Store)

Hallo, 

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:

            %prefix_plugin_name.plugin_dir%
            %prefix_plugin_name.plugin_name%
            
            
        

        
            %prefix_plugin_name.plugin_dir%

Der Subscriber ist auch eher standard boilerplate:

pluginPath = $pluginPath;
		$this->pluginName = $pluginName;
		$this->configReader = $configReader;

	}

	/**
	 * @inheritdoc
	 */
	public static function getSubscribedEvents()
	{
		return [
			'Enlight_Controller_Action_PostDispatchSecure_Frontend_Detail' => 'onFrontendPostDispatch',
			'Theme_Compiler_Collect_Plugin_Less' => 'onCollectLessFiles',
			'Theme_Compiler_Collect_Plugin_Javascript' => 'onCollectJsFiles'
		];
	}


[...]

 

 

// 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. 

 

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍, [@Tobias Berge](http://forum.shopware.com/profile/20591/Tobias Berge “Tobias Berge”)‍
 

Könnt ihr vll. hierzu was sagen? Ist das jetzt neu in 5.7 oder ist bei meiner Test-Installation was schief gelaufen?

Ich dachte, das wäre schon Dein Ticket  Smile
Shopware Issuetracker

Wegen der Änderungen gibt es auch eine recht lange RC-Phase von 8 bis 10 Wochen!
Der Shopware 5.7 Release Candidate ist da | Shopware

Munter Tickets anlegen und VOTEN.

1 „Gefällt mir“

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.

Siehe auch Shopware 5 upgrade guide

2 „Gefällt mir“

Danke für die Rückmeldung! Verstehe ich das richtig, dass es damit getan ist, in der services.xml public=„true“ an die eigenen Services zu hängen?

Du kannst einfach alle als Public markieren wie wir das im Core machen wegen Kompatibilitätsgründen shopware/services.xml at 5.7 · shopware/shopware · GitHub

Aber eigentlich solltest du nur im Notfall $container->get machen und alles injecten, wie im Symfony Blog Beitrag beschrieben

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?

Hallo Zusammen, 

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 ?

 

Grüße aus Berlin!

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

Hallo Shyim,

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.

Grüße

Ich versteh nicht genau was du meinst. Kannst du den Link zu dem Thread im Symfony Slack senden?

Subscriber / der Logger / Filesystem sollten jetzt so klappen wie vorher

Hey Shyim, 

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: 

$this->container->get(‚Template‘)->addTemplateDir( $this->getPath() . ‚/Resources/views/responsive/‘ );

Das funktioniert nicht mehr. Ersetzt durch: 

$this->container->get(‚template‘)->addTemplateDir( $this->getPath() . ‚/Resources/views/responsive/‘ );

 

Hallo Shyim, 

ich habe interne Kollegen im Symfony Bereich mit denen ich gesprochen habe. Da gibt es kein schriftliches Protokoll zu :smiley:

Ist nicht kompatibel mit Shopware Version 5.4. und verursacht einen 500er. 

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.

Schöne Grüße,
Niklas

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.

Ich schaue mir das gleich nochmal genauer an, dann scheint es ja irgendwie gehen zu müsen.
Edit : Habe mich geirrt, Analyse lief nun durch - läuft  Thumb-Up

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?

Hallo @Srcaft

deine letzte Vermutung ist genau richtig.

Hier kannst du mehr darüber erfahren:

Viele Grüße aus Schöppingen
Michael Telgmann