afterInit() vom Plugin Bootstrap nicht immer aufgerufen?

In den meisten Plugins hält die Boostrap einige Variablen als private/protected in der Klasse, welche in der afterInit() initialisiert wurden. Hauptsächlich eben globale Komponenten, wie z.b. Shopware()->Session(), Shopware()->Utils() usw. Das hat in der 4.2.1 tadellos funktioniert, nachdem Update auf 4.3.6 sind die Variablen manchmal leer. Gibt es das, dass die afterInit() nicht immer aufgerufen wird? Was wäre die Alternative? Konstruktor?

Der Aufruf der afterInit() Methode gehört zum standard lifecycle und wird -immer- ausgeführt. Der Fehler muss an anderer Stelle liegen. Viele Grüße

Wäre es möglich das Events noch vor der afterInit() aufgerufen werden? Oder Events eine neue Bootstrap Instanz sich holen? Ich konnte es mit xdebug nur zum Teil nachvollziehen. Bei ein paar Aufrufen waren die Variablen initialisiert, bei späteren Aufrufen nicht. Aber im selben Plugin/Event…

Mittlwerweile konnte ich es etwas einschränken. Beim Shopware_Modules_Articles_sGetProductByOrdernumber_FilterResult Event wird die Bootstrap z.B. nicht initialisiert… Das ist aber das letzte Event, was in diesem Plugin aufgerufen wird. Alle anderen Events sind sauber in einer initialisierten Bootstrap ausgeführt.

Hallo Zusammen, Plugins werden von Shopware lazy initialisiert. Das heißt beim ersten Event auf das Sich ein Plugin registriert hat, wird das Plugin initialisiert und die „afterInit“ Methode aufgerufen. Zu deinem Beispielevent Shopware_Modules_Articles_sGetProductByOrdernumber_FilterResult. Hier wird erst die afterInit() aufgerufen, dann die eventCallback(). Wenn das Event Shopware_Modules_Articles_sGetProductByOrdernumber_FilterResult nicht geworfen wird, wird auch die afterInit Methode deines Plugins nicht aufgerufen. <?php class Shopware_Plugins_Frontend_SwagExample_Bootstrap extends Shopware_Components_Plugin_Bootstrap { public function install() { $this->subscribeEvent( 'Shopware\_Modules\_Articles\_sGetProductByOrdernumber\_FilterResult', 'eventCallback' ); return true; } public function afterInit() { error\_log(\_\_METHOD\_\_ . "\n"); } public function eventCallback(Enlight\_Event\_EventArgs $args) { error\_log(\_\_METHOD\_\_ . "\n"); } } Viele Grüße, Benjamin Cremer :shopware:

Das klingt interessant. Konnte es jetzt endlich einschränken. Es tritt nur bei einen bestimmten Subrequest auf (für das Mein Konto/Warenkorb Partial), dort wird das Event zwar aufgerufen, aber eben keine Initialisierung. Mal der Stacktrace/Frames aus phpstorm debug: 1. shopware.php: 170 {main}() 2. Kernel.php:145 Shopware\Kernel-\>handle() 3. Front.php:288 Enlight\_Controller\_Front-\>dispatch() 4. Default.php:528 Enlight\_Controller\_Dispatcher\_Default-\>dispatch() 5. Action.php:202 Enlight\_Controller\_Action-\>dispatch() 6. EventManager.php:211 Enlight\_Event\_EventManager-\>notifiy(), $event = "Enlight\_Controller\_Action\_PostDispatch" 7. Plugin.php:149 Enlight\_Event\_Handler\_plugin-\>execute() 8. Bootstrap.php:1193 Shopware\_Plugins\_Core\_AcmeCore\_Bootstrap-\>onPostDispatch() 9. sAdmin.php:2656 sAdmin-\>sGetUserData() 10. sAdmin.php:4643 sAdmin-\>getUserShippingData() 11. sAdmin.php:400 sAdmin-\>sGetPaymentMeanById() 12. sBasket.php:1027 sBasket-\>sGetBasket() 13. sBasket.php:1920 sBasket-\>getBasketArticles() 14. sArticles.php:3682 sArticles-\>sGetProductByOrdernumber() 15. EventManager.php:301 Enlight\_Event\_EventManager-\>filter(), $event = "Shopware\_Modules\_Articles\_sGetProductByOrdernumber\_FilterResult" 16. Plugin.php:149 Enlight\_Event\_Handler\_Plugin-\>execute() 17. Bootsptrap.php:795 Shopware\_Plugins\_Fronted\_CheckoutFirewall\_Bootstrap-\>sGetProductByOrdernumber\_FilterResult() Um auf den Punkt mit dem ersten Event zurückzukommen. In dieser Bootstrap sieht eh so aus: protected function subscribeEvents() { // Add path to frontend-controller $this-\>subscribeEvent( 'Enlight\_Controller\_Dispatcher\_ControllerPath\_Frontend\_CheckoutFirewall', 'onGetFrontendController' ); // some events $this-\>subscribeEvent( 'Shopware\_Modules\_Articles\_sGetProductByOrdernumber\_FilterSql', 'sGetProductByOrdernumber\_FilterSql' ); // some events } D.h. die afterInit wird nur aufgerufen, wenn das Enlight_Controller_Dispatcher_ControllerPath_Frontend_CheckoutFirewall Event geworfen wird. In diesem einen Subrequest ist das dann nicht der Fall, daher sind die internen Klassenvariablen natürlich leer. Gibt es das, dass dies Verhalten in 4.2.1 noch anders war?

Sollte man auch mal wissen. Das von mir vermeintlich geglaubte Sub-Request ist ein Ajax Call a la ?module=widgets&controller=checkout&action=info Ist es hier so, dass nicht alles initialisiert wird?