Kompatibles Frontend-Event für alle Versionen

Hallo! Vielleicht hat einer da ja eine Idee parat, und zwar benutze ich folgendes Event, um auf allen Frontend-Seiten gefeuert zu werden: Enlight\_Controller\_Action\_PostDispatch\_Frontend Ich bemerke, dass das unter 4.0.8 nicht funktioniert - es wird nichts getriggert. Ändere ich das auf z.B. _Listing, wird es ausgeführt. Jetzt die Frage, welches Event ich sicher nutzen kann, um in allen Shop-Versionen im Frontend ausgeführt zu werden? Ich freue mich über Feedback! EDIT: Bekomme über folgendes das gewünschte Ergebnis: $this-\>subscribeEvent( 'Enlight\_Controller\_Action\_PostDispatch', 'onFrontendPostDispatch' ); Würde nur theoretisch auch im Backend gefeuert werden, korrekt? … Schöne Grüße, Niklas

Hi, Enlight_Controller_Action_PreDispatch Enlight_Controller_Action_PreDispatch_MODULNAME_CONTROLLERNAME Enlight_Controller_Action_PostDispatch Enlight_Controller_Action_PostDispatch_MODULNAME_CONTROLLERNAME stehen dir durchgängig in allen Versionen zur Verfügung. Zusätzlich gibt es seit 4.1.0 die sogenannten PostDispatchSecure-Events, die wir empfehlen, sowie die Module-Events. Enlight_Controller_Action_PostDispatch wird auch im Backend gefeuert, das solltest du auf keinen Fall für deine Frontend-Erweiterungen nutzen - zumindest nicht ohne weitere Checks, ob es sich wirklich ums Frontend handelt. lG Daniel //edit: Beitrag wurde korrigiert, die Module-Events stehen erst aber der 4.1.0 zur Verfügung, das hatte ich erst falsch dargestellt.

1 Like

Hallo Daniel! Danke für die schnelle Antwort! [quote=“Daniel Nögel”] Enlight_Controller_Action_PreDispatch Enlight_Controller_Action_PreDispatch_MODULNAME … stehen dir durchgängig in allen Versionen zur Verfügung. Zusätzlich gibt es seit 4.1.0 (wenn ich mich nicht irre) die sogenannten PostDispatchSecure-Events, die wir empfehlen.[/quote] Mh, ich habe in der besagten 4.0.8 Enlight_Controller_Action_PreDispatch_Frontend ausprobiert, das funktioniert nicht und erst durch die Erweiterung einer bestimmten Action oder ohne den Modulnamen. [quote=“Daniel Nögel”] das solltest du auf keinen Fall für deine Frontend-Erweiterungen nutzen - zumindest nicht ohne weitere Checks, ob es sich wirklich ums Frontend handelt. [/quote] Ok, dann lasse ich das erst einmal so mit der Frontend-Überprüfung. Ist trotzdem komisch, habe das gerade mit einer frischen 4.0.8 so nachgespielt. Nur die Änderung des Events (wie oben beschrieben) lässt meine Erweiterung erscheinen - oder nicht … Dann muss ich das mal bei Zeiten genauer beleuchten. Vielen Dank! Schöne Grüße, Niklas

Hi, habe gerade nochmal in den Quellen nachgesehen: Das Modul-Event wurde tatsächlich ebenfalls erst mit der 4.1.0 eingeführt - zusammen mit den Secure-Events. Ich korrigiere das oben gleich mal :slight_smile: lG Daniel

1 Like

Hi Daniel! Danke für den Samstags-Support! :sunglasses: :thumbup: [quote=“Daniel Nögel”]Das Modul-Event wurde tatsächlich ebenfalls erst mit der 4.1.0 eingeführt - zusammen mit den Secure-Events. Ich korrigiere das oben gleich mal :)[/quote] Ahhh, OK! Dachte schon, ich hätte doch etwas verbaselt … :slight_smile: Was ist denn dann “best-practice” um alle Shop-Versionen zu unterstützen mit den Events? Die Events passend zur Shopversion < 4.1.0 (ohne Modul) und >= 4.1.0 (mit Modul) registrieren? Oder wie oben beschrieben grundsätzlich ohne Modul und dafür mit Modul-Abfrage innerhalb des eigenes Listeners? DANKE für Deine Hilfe :slight_smile: Niklas

Hi, ich würde dann tatsächlich eher das EINE Event für alle Versionen registrieren. Dann solltest du aber diesen Boilerplate-Code nutzen: if ($request-\>getModuleName() != 'frontend' || !$request-\>isDispatched() || $response-\>isException() || !$view-\>hasTemplate()) { return; } Besten Gruß, Daniel //edit: Codeblock korrigiert (s.u.)

@Daniel Hi, ich hänge mich hier mal kurz mit rein. Du schreibst [quote]die sogenannten PostDispatchSecure-Events, die wir empfehlen[/quote] Empfehlt ihr diese zur grundsätzlichen Nutzung oder nur bei Erweiterungen im Checkout oder ähnlichem? Gruß

[quote=„Daniel Nögel“]ich würde dann tatsächlich eher das EINE Event für alle Versionen registrieren. Dann solltest du aber diesen Boilerplate-Code nutzen…[/quote] Perfekt, wird gemacht, Dein Code hat nur eine vertauschte Bedingung und ein Rechtschreibfehler. Hier korrigiert :slight_smile: if ($request-\>getModuleName() != 'frontend' || !$request-\>isDispatched() || $response-\>isException() || !$view-\>hasTemplate()) { return; } Habe ich so nun drin - vielen vielen Dank! :slight_smile: Jetzt aber ein schönes Wochenende :smiley: :sunglasses: Niklas

1 Like

Hi, die empfehlen wir überall da, wo ihr normalerweise PostDispatch-Events (ohne Secure) einsetzen würdet. Der einzige Unterschied ist, dass die nur geworfen werden, wenn diese Bedingungen zutreffen: $this-\>Request()-\>isDispatched() && !$this-\>Response()-\>isException() && $this-\>View()-\>hasTemplate() Damit spart ihr euch also nicht nur den Boilerplate-Code, der notwendig ist, wenn man Versionen < 4.1.0 hat - und oft vergessen wurde. Ihr stellt damit sicher, dass eure Erweiterungen ihre Template-Assignments nicht an irgendwelche Binärdownloads hängen und so bspw. die Belegerstellung zerschießen. Das “Secure” bedeutet also nicht “sicher” im Sinne von “Security”, sondern eher im Sinne von “verlässlich” - wenn ihr das Event nutzt, könnt ihr euch darauf verlassen, dass es sich um einen “richtigen” Request handelt und nicht irgendeine Fehlermeldung, Download etc. Die regeln sind also eigentlich: PostDispatchSecure wo möglich und möglichst spezifisch - also am besten sowas wie PostDispatchSecure_Frontend_Checkout und dann vll. sogar noch auf die Actions einschränken, wenn möglich. Wenn ihr aber sowas machen wollt wie “Footer auf jeder Seite austauschen”, ist natürlich PostDispatchSecure_Frontend das richtige Event. Besten Gruß, Daniel

1 Like

Klasse! Danke für die Erklärung! :thumbup: Schönes WE noch.