Plugin: Uncaught SmartyException: directory not allowed by security setting

Moin Zusammen,

zwar existieren schon ein paar Einträge bzgl. der Smarty-Exceptions, aber ich bin nicht sicher, ob diese auf mein Problem zutreffen:

Ich habe ein Plugin, welches unter anderem das \frontend\listing\product-box\box-basic.tpl erweitert. Das Problem tritt auf Detail Seiten auf. Wird ein Produkt, das auf dieser Detailseite in einem der Cross-Selling-Slider erscheint, geändert (z.B. Preis erhöht) und die Seite anschließend neu geladen, fehlen Teile der Seite und es ergibt sich folgende Fehlermeldung im Log:

PHP Fatal error: Uncaught SmartyException: directory '/home/vagrant/www/shopware/engine/Shopware/Plugins/Local/Frontend/TestPlugin1/Views/frontend/listing/product-box/box-basic.tpl' not allowed by security setting in /home/vagrant/www/shopware/engine/Library/Smarty/sysplugins/smarty_security.php:381
Stack trace:
#0 /home/vagrant/www/shopware/engine/Library/Smarty/sysplugins/smarty_internal_resource_file.php(33): Smarty_Security->isTrustedResourceDir('/home/vagrant/w...')
#1 /home/vagrant/www/shopware/engine/Library/Smarty/sysplugins/smarty_resource.php(532): Smarty_Internal_Resource_File->populate(Object(Smarty_Template_Source), NULL)
#2 /home/vagrant/www/shopware/engine/Library/Smarty/sysplugins/smarty_internal_resource_extends.php(41): Smarty_Resource::source(NULL, Object(Enlight_Template_Manager), '/home/vagrant/w...')
#3 /home/vagrant/www/shopware/engine/Library/Enlight/Components/Snippet/Resource.php(76): Smarty_Internal_Resource_Extends->populate(Object(Smarty_Template_Source), NULL)

Der Fehler tritt nur auf, wenn der HTTP-Cache aktiviert ist. Nach Leerung des Caches tritt der Fehler nicht auf, bis oben beschriebene Änderungen durchgeführt wurden. Der Fehler trat erst nach einem Wechsel auf 5.3.2/5.3.3 auf.

Ich habe es mit einem simplen Testplugin nachgestellt (Auszug, mehr steht aber nicht wirklich drin):

public function install() {
    $this->subscribeEvent( 'Enlight_Controller_Action_PostDispatchSecure_Frontend', 'onFrontendPostDispatch' );
    return true;
}

public function onFrontendPostDispatch( Enlight_Event_EventArgs $args ) {
    $controller = $args->get('subject');
    $view = $controller->View();
    $view->addTemplateDir( __DIR__. '/Views' );
}

Einzige Template-Datei ist die oben erwähnte “box-basic.tpl”. Diese ist bis auf die Zeile

{extends file="parent:frontend/listing/product-box/box-basic.tpl"}

leer. Es liegt also keine Nutzung eines nicht mehr unterstützten Smarty/PHP-Befehls vor. Bei deaktivierter Template-Security

'template_security' => array (
    // @deprecated with 5.3, config switch will be removed with 5.4
    'enabled' => false,
),

tritt der Fehler nicht auf. Dies ist wegen @deprecated natürlich keine Option.

Daraufhin habe ich mir in der “smarty_security.php -> isTrustedResourceDir()” das “$this->_resource_dir”-Array in eine Log-Datei schreiben lassen (vor dem letzten while(true), ~363). Bei erstem Aufruf einer Seite ist das Plugin-Template-Dir darin vorhanden. Im zweiten Schritt jedoch nicht mehr. Daraufhin schmeißt die Methode natürlich eine Exception.

Ich weiß nicht mehr weiter. Möglicherweise entspricht das der Problematik in Shopware Issuetracker, ich weiß es aber ehrlich gesagt nicht. Oder ich seh den Wald vor lauter Bäumen nicht

Beste Grüße und Dank,
devnullroot

Ich antworte mir hier mal selber, vlt. hilft es ja jemandem. Die Lösung wurde mir in diesem Thread von „sonic“ gegeben:
Thread: https://forum.shopware.com/discussion/48765/5-3-2-unser-freund-der-unknown-tag-s/
"sonic"s Hinweis: https://forum.shopware.com/discussion/comment/207508/#Comment_207508

Vielen Dank an dieser Stellen noch mal an „sonic“!

Was ich in meinem Plugin gemacht habe:

Ich habe ein „dummy“ subscribe auf
$this->subscribeEvent( ‚Enlight_Controller_Action_PostDispatch‘, ‚addTemplates‘ );
gemacht. Dies ist wohl früh genug, damit die security nicht „einschreitet“

In der „addTemplates“ habe ich lediglich das/die Template Dirs „bekannt“ gemacht:

$controller = $args->get('subject');
$view = $controller->View();
$view->addTemplateDir( __DIR__. '/Views' );

Danke nochmal an „sonic“, der mich auf den Weg gebracht hat!

devnullroot

Das Hauptproblem war wohl, dass dir noch ein AddTemplateDir für den Widgets Call fehlte, da die Produkt-Boxen auch per Widget nachgeladen werden.

Mmmh, das kann aber irgendwie nicht sein (oder ich hab grade einen Knick in der Logik). Denn warum funktioniert es ohne Cache wie es soll? Also es reicht “Enlight_Controller_Action_PostDispatchSecure_Frontend” zu subscriben um z.B. in der “box-basic.tpl” TEST ausgeben zu lassen. Wird überall (Listings,Cross-Selling auf der Detailseite, Topseller) brav ausgegegen.

Nur eben bei eingeschaltetem HTTP-Cache nicht , da setzt es den Error. Erst bei zusätzlichem “Enlight_Controller_Action_PostDispatch” geht es dann. Ich dachte eigentlich es handele sich um dieses Problem: Shopware Issuetracker (Timing) und letzterer Event kommt “früh” genug? Wobei ich den Cache-On/Off Unterschied eben grundsätzlich interessant finde. Ist bei deaktiviertem Cache die Smarty-Security evtl. gar nicht aktiv?

Nebenbei bemerkt: Ist es korrket, dass die Preise im Cross-Selling-Bereich bei eingeschaltetem Cache nicht aktualisiert werden (ohne Plugin und mit frischer Installation, getestet)?

greets,
devnullroot

Da ich ja erwähnt wurde… 
Ich habe selber ein erhebliches Problem daran zu glauben, dass es daran liegt “wann” ein Template registriert wird. Es gibt ja auch Plugins, die ganz ohne Template auskommen. Wenn also zu spät oder gar nicht ein Template registriert wird, warum soll dann auf das Template zugegriffen werden? Hier hab ich beim “s”-Problem noch ein großes Verständnisproblem. Insbesondere dann, wenn es - wie im “großen” Thread - fast immer mit dem Cache zusammen hängt.
Ich tippe auch eher auf einen Bug im Zusammenspiel mit HTTP-Cache + Template-Cache. Aus meiner eigenen Erfahrung tippe ich auf einen falschen Zugriff auf den Smarty-Cache. Smarty will das Plugin rendern, bekommt aber keinen Pfad, weil Event nicht gefeuert wird, und “sucht” selber.

Kram in der Mottenkiste:
https://forum.shopware.com/discussion/47521/evtl-problem-mit-freitext-seit-ca-5-2-26
Noch vor “security” und auf PostDispatch_Detail (nicht secure)
Es werden weitere TABS in den Details erzeugt.

1. Template wird NUR registriert, wenn ein Freitext eine Bedingung erfüllt
2. HTTP-Cache ist an
   Irgendwann “verschwinden” die TABS … Cache leeren … TABS wieder da
   Untersuchung: Der Event wird nicht gefeuert.
   Lösung 1: HTTP Cache aus … TABS immer da
   Lösung 2: Template immer registrieren, auch wenn es gar nicht benötigt wird … TABS auch mit HTTP-Cache immer da
   Dringender Tatverdacht:
   Ein Artikel “Ohne” TABS verbiegt so den Cache, dass beim Aufruf eines Artikels “mit TAB” der Event nicht gefeuert wird.
   Anders ist das gar nicht zu erklären

Wie eingangs geschrieben: Wenn “Plugin” ‘zu spät’ das Template registriert, was bewegt dann Smarty bei HTTP-Cache dazu, dort “zu suchen”? Für mich ein fehlerhaftes Caching, somal es bei mir ja erst grob nach 5.2.26 angefangen hat.

Auch wegen viel zu kurzer Timeouts vom HTTP-Proxy-Client (shared-server) und daraus resultierender UPS habe ich gar keinen Cache mehr an … UPS ? gibts nicht mehr !

Moin zusammen!
Moin @devnullroot‍

Ich versuche hier mal ein bisschen Licht ins Dunkel zu bringen.
Vorsicht: Textwand.

Das Verhalten tritt nur dann auf, wenn der Cache aktiviert ist und das Plugin-eigene Template Directory erst nach bestimmten Bedingungen  ausgeführt wird.
Dazu mal zwei Beispiele:

Beispiel 1 - falsche If-Condition:

public static function getSubscribedEvents()
{
    return [
        'Enlight_Controller_Action_PostDispatchSecure' => 'onPostDispatch'
    ];
}

public function onPostDispatch(\Enlight_Controller_ActionEventArgs $eventArgs)
{
    $userData = $this->container->get('modules')->Admin()->sGetUserData();
    if ($userData['name'] === 'Max Mustermann') {
        return;
    }

    $eventArgs->getSubject()->View()->addTemplateDir('Views/');
}

Warum ist dies nun ein Problem, und was hat das mit dem Cache zu tun?

Dies ist ein PostDispatch-Event, d.h. der Code wird für jeden Kunden in jedem Controller ausgeführt.
Nun gehen wir das Beispiel einmal durch.
Der Cache ist aktiv, wurde jedoch frisch geleert.
Der Kunde John Doe surft die Home-Seite an, das Event wird getriggered und er läuft in den Code rein.
John Doe heißt offensichtlich nicht “Max Mustermann”, sodass er auch nicht in den Early-Exit reinläuft und die Zeile “addTemplateDir” wird ausgeführt.
In dem Views-Ordner des Plugins wird die Home-Seite minimal angepasst, diese angepasste Version der Home-Seite landet nun im Cache.
Irgendwo im Cache findet man jetzt einen Verweis auf diese Anpassung der Home-Seite, das kann so aussehen:
 

'123456789090353523wvgsdfbvdg43g3' => 
    array (
      0 => '/meinSystem/meineShopInstallation/custom/plugins/SwagTestPlugin/Resources/views/frontend/home/index.tpl',
      1 => 1511339915,
      2 => 'snippet',
    ),

Jetzt betritt Max Mustermann den Shop und surft direkt die Home-Seite an.
Was passiert nun?
Der zuvor genannte PHP-Code verhindert im Falle von Max Mustermann, dass zuvor das Plugin-eigene Template Directory offiziell hinzugefügt wird.
Da der Cache aktiviert ist, wird die o.g. Zeile aus dem Cache ausgeführt - er versucht die Datei /meinSystem/meineShopInstallation/custom/plugins/SwagTestPlugin/Resources/views/frontend/home/index.tpl zu laden.
Und hier kommt die Smarty-Security ins Spiel.
Das Verzeichnis /meinSystem/meineShopInstallation/custom/plugins/SwagTestPlugin/Resources/views/ wurde Smarty nie bekannt gemacht und gilt somit als “nicht vertrauenswürdig” => Es knallt.

Die Meldung “Unknown service tag ‘s’” ist durchaus ein Bug, der immer dann auftritt, wenn eine Fehlermeldung ausgegeben werden soll, so wie in diesem Fall.

War dieses Beispiel soweit verständlich?
Dies ist immer dann ein Problem, wenn das addTemplateDir nach einer Bedingung genutzt wird, die bspw. für einen Kunden zutrifft, für den anderen Kunden jedoch nicht.
Wenn man das o.g. Beispiel von der Reihenfolge ändert, also erst kommt Max Mustermann, dann John Doe, würde es übrigens nicht knallen - da direkt die Template-Version gecached werden würde, die die Plugin-eigene Anpassung nicht beinhaltet.
Dadurch tritt auch ein gewissen “Randomness”-Gefühl auf.

Dieses Beispiel erklärt aber noch nicht, warum das Verhalten dann auch beim Threadersteller auftritt.
Aber auch dazu habe ich soeben ein kleines Beispiel vorbereitet.

Beispiel 2 - addTemplateDir nur bei bestimmten Events:

public static function getSubscribedEvents()
{
    return [
        'Enlight_Controller_Action_PostDispatchSecure_Frontend' => 'onPostDispatchFrontend'
    ];
}

public function onPostDispatchFrontend(\Enlight_Controller_ActionEventArgs $eventArgs)
{
    $eventArgs->getSubject()->View()->addTemplateDir('Views/');
}

In diesem Beispiel gibt es eigentliche keine Bedingung, warum knallt es jetzt beim Threadersteller?

Dazu folgendes Szenario, das dem Szenario des Threaderstellers zu 99% gleicht:
Das Plugin passt in seinem eigenen Views-Ordner eine Produkt-Box an.

Erneut ist der Cache aktiviert und frisch geleert.
Der Kunde Max Mustermann surft durch den Shop und landet in einem Kategorie-Listing.
Beim Surfen durch das Produktlisting knallt es plötzlich, die Meldung “Unknown tag ‘s’” taucht wieder auf.

Warum knallt es jetzt, es war doch kein zweiter Kunde beteiligt, der eine Cache-Datei generiert hat.
Der Kunde ruft das Listing auf, welches Produktboxen beinhaltet.
Der Verweis auf die Template-Anpassung durch das Plugin landet im Cache.
Beim Surfen durch das Kategorie-Listing scrollt Max Mustermann etwas herunter und löst Infinite Scrolling aus - und hier kommt der Kniff.
Die Template-Anpassung an den Produktboxen ist durch das initiale Aufrufen des Listings bereits gecached, zusammen mit dem Verweis auf die Anpassung.
Infinite Scrolling benötigt jene Produkt-Boxen natürlich ebenfalls, jedoch funktioniert Infinite Scrolling über einen Widget -Controller.
Das Event, das das Plugin nutzt, ist jedoch lediglich für  Frontend -Controller, entsprechend wird beim Infinite Scrolling nie das Template Directory des Plugins hinzugefügt.

Auch hier wird also eine Anpassung aus einem Ordner zu laden versucht, der Smarty im aktuellen Request nie bekannt gemacht wurde.

Nun hat unser Threadersteller sein Event geändert, auf “Enlight_Controller_Action_PostDispatch”.
Dieses Event wird für alle Arten von Controllers aufgerufen, unabhängig davon ob es ein Frontend - oder ein Widget -Controller ist.
Ergo: Es funktioniert mit diesem Event auch mit aktiviertem Cache.

War auch dieses Beispiel verständlich?

Diese Probleme konnten natürlich erst mit Einschalten der Smarty Security auftreten und waren daher in vorherigen Shopware-Versionen nie ein Problem.
Daher der allgemeine Tipp:
Registriert eure Plugin eigene Views Ordner so früh wie möglich, also nicht erst nach bestimmten Bedingungen, und nutzt keine Events, die ja auch irgendwo direkt eine Bedingung beinhaltet, wie eben bspw. die Unterscheidung des Moduls.

Solltet ihr zwingend eine Bedingung benötigen, bevor eine Template-Anpassung greift, so registriert den Views Ordner trotzdem vor einer Bedingung und packt die Bedingung selbst dann in das jeweilige Template.
Dadurch wird die Template-Datei  immer  geladen, die eigentliche Anpassung wird jedoch durch die Bedingung  innerhalb der Template-Datei  verhindert.

War das alles soweit verständlich?
Bei Fragen gerne zurückschreiben, dann verlinkt mich bitte kurz, sodass ich eine Benachrichtigung bekomme.

Gruß,
Patrick 

Danke [@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl „Patrick Stahl“)‍, das fand ich sehr erleuchtend! In den Fehler wäre ich bestimmt früher oder später auch mal gerannt. Wieso wird der Views Ordner im neuen Plugin System eigtl nicht automatisch registiert? Das wird schon soviel automatisch registiert. Views und Models wären auch noch nice. Was würde dagegen sprechen? Bei Bedarf würde ich dafür auch nen Pull Request ausarbeiten.

>> Wieso wird der Views Ordner im neuen Plugin System eigtl nicht automatisch registiert?

Ich habe zb Plugins, die ich nur in manchen Subshops (per Plugin Konfiguration) aktiveren möchte. Da spare ich mir ganz gerne den overhead und lade die Template Ordner dort nicht. Zudem gibt es weiterhin definitiv Konstellationen, bei denen du separiert das Template Verzeichnis laden möchtest oder eben nicht. Ich finde, dass es weiterhin in der Hand des Entwicklers liegen sollte, wann und ob ein Template erweitert wird - man muss dabei halt nur ein wenig aufpassen und sich an die Richtlinien halten.

Viele Grüße

Hallo,

es gibt glaub genug Anwendungsfälle, wo man entweder einen View-Ordner oder einen anderen laden muss, ein automatisches registrieren wäre also fatal und würde gar keinen Sinn machen und wird Shopware hoffentlich auch nie implementieren, da es eher ein Rückschritt wäre. Solange man sich an die Regeln hält, klappt doch auch alles.

Beste Grüße

Sebastian

Jo, wie “leicht” es mit an den “Regeln halten” ist, haben wir ja im S-Thread gesehen. Wenn ich mich nicht täusche, waren da einige Plugins mit dem Kürzel “SWAG” ganz vorne mit dabei.   Lustig wird es dann, wenn solche Hinweise aus der unwartbaren Spaghetti-Code-Ecke kommen. 
Dank Patrick hat sich der Nebel schon erheblich gelichtet. Warum jetzt aber der Smarty-Cache erst zum Problem wird (bei mir) wenn der HTTP-Cache aktiviert ist, werde ich bestimmt nach mehrmaligem Lesen obiger Abhandlung verstehen. Oder einfach sagen: egal

Danke Patrick für die ausführliche Erklärung.

@sschreier‍: Okay. Macht bei den Views wohl Sinn. Wobei das gleiche ja für LESS und JS Erweiterungen auch gelten könnte. Die will man dann ja evtl. auch nicht haben, wenn man das Plugin für einen Subshop deaktiviert. Die werden auch, wenn sie in einem gewissen Verzeichnis liegen, automatisch registiert. Vielleicht wäre aber ein optionaler Schalter im InstallContext eine Möglichkeit. Somit könnte man sich ne Menge Boilerplate Code ersparen. Eine Autoregistierung für Models würde ich jedoch sehr sinnvoll finden. Könnte man ja optional im InstallContext deaktivieren oder hier auch wieder optional aktivieren. Wäre ja vermutlich ein Breaking Change.

Danke an [@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl „Patrick Stahl“)‍ für die ausführliche Erläuterug, das hat viel Licht ins Dunkle gebracht!

Ich frage mich jetzt allerdings was

Registriert eure Plugin eigene Views Ordner so früh wie möglich, also nicht erst nach bestimmten Bedingungen, und nutzt keine Events, die ja auch irgendwo direkt eine Bedingung beinhaltet, wie eben bspw. die Unterscheidung des Moduls.

nun genau bedeutet. Für mich ist der fett gedruckte Teil leider nicht ganz eindeutig:

1. Templates nicht in einem Event für ein Modul hinzufügen
2. oder gar nicht in einem Event hinzufügen.

Ersterer Fall wäre ja eben z.B. „Enlight_Controller_Action_PostDispatch“. Letzteren Fall wüßte ich momentan nicht umzusetzen, wie macht man denn die Views außerhalb von Events bekannt? Hier fehlt mir wohl das Wissen

Anders ausgedrückt: Was ist denn grundsätzlich die früheste und damit sicherste Möglichkeit den Views-Ordner zu registrieren? Falls nicht „Enlight_Controller_Action_PostDispatch“ wäre ein Code-Schnipsel natürlich toll…

LG und Besten Dank,
devnullroot

P.S.: Ich frage auch deshalb nochmal explizit nach, weil ich die Frage gerne als beantwortet markieren möchte

Moin @devnullroot‍.

damit meinte ich in lediglich, dass keine Events zur Template Registrierung benutzt werden sollten, die eine Bedingung enthalten.
Enlight_Controller_Action_PostDispatchSecure_Frontend

Hier ist bspw. das _Frontend ja schon eine Bedingung, wie oben in meinem Beispiel erläutert.

Du könntest bspw. das folgende Event nutzen:
Theme_Inheritance_Template_Directories_Collected
sowie der dazugehörige Beispiel-Code:
 

public function onCollectTemplateDir(\Enlight_Event_EventArgs $args)
{
    $dirs = $args->getReturn();
    $dirs[] = $this->pluginDir . '/Views';

    $args->setReturn($dirs);
}

Gruß,
Patrick 
 

Moin Patrick,

ich habe ein ähnliches Problem wie devnullroot, mein Plugin passt die Artikelbox im Listing an, ist der Cache geleert, funktioniert alles super, bei aktualisieren der Seite wird das Template aber scheinbar nicht mehr geladen. Ist der HTTP-Cache deaktiviert funktioniert alles einwandfrei. Das Problem tritt bei mehreren Kunden mit Shopware 5.3.4 auf.

Ich habe nun wie von Dir [@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl „Patrick Stahl“)‍ vorgeschlagen zuerst versucht das Template Verzeichnis direkt im  Enlight_Controller_Action_PostDispatch  Event (ohne jegliche Bedingungen) zu registrieren und es anschließend auch mit dem Event  Theme_Inheritance_Template_Directories_Collected  versucht. Aber das Problem bleibt das gleiche.

Ich habe natürlich nach dem Hinzufügen der genannten Events jeweils das Plugin neuinstalliert und den Cache komplett geleert. Aber immer das gleiche Verhalten der erste Seitenaufruf nach Cache leeren passt, der zweite und alle folgenden nicht mehr.

Wo könnte das Problem noch liegen?

Gruß

Daniel

Moin Daniel / @mowlwurf‍,

da kann ich mir spontan auch keinen Reim draus bilden.
Das müsste ich mir dann schon im Detail anschauen.

Ist dies zu 100% mit deinem Plugin nachstellbar?
Dann lass mir doch einfach ein .zip per PM zukommen, dann schaue ich mal, ob ich da etwas finde.
Bitte natürlich auch alle benötigten Informationen hinzufügen, also bspw. sowas wie “benötigte Plugin Konfigurationen” oder sowas, um das Verhalten nachzustellen.

Gruß,
Patrick 

Moin @mowlwurf‍,

hat sich bei dem Problem was ergeben? Ist es die gleiche/ähnliche Problematik, eine „erweiterete“ Version, oder etwas völlig anderes?

Cheers,
devnullroot

Moin @devnullroot‍,

komme momentan zeitlich leider nicht dazu mir das Verhalten von @mowlwurf‍ anzuschauen.
Habe mir dafür jedoch einen Reminder angelegt, sodass ich mir dies definitiv nochmal anschauen werde.

Gruß,
Patrick 

Du könntest bspw. das folgende Event nutzen:

Theme_Inheritance_Template_Directories_Collected
sowie der dazugehörige Beispiel-Code:
 

public function onCollectTemplateDir(\Enlight_Event_EventArgs $args)
{
$dirs = $args->getReturn();
$dirs = $this->pluginDir . ‚/Views‘;

$args->setReturn($dirs);
}

Hallo [@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl „Patrick Stahl“)‍,

kann man zu diesem Zeitpunkt auch schon ein Smarty-Plugin einbinden? Falls ja, wie müsste das aussehen?

Moin,

ich hatte das Problem bei Infinite Scrolling im Listing bei erweiterung der \frontend\listing\product-box\box-basic.tpl. Alle Lösungen die hier vorgeschlagen wurden haben in meinen Fall nicht funktioniert. Der Hinweis das es sich um Widget -Controller handelt brachte mich aber zur Lösung. Es funktioniert aber nur als PreDispatch! ‚Enlight_Controller_Action_PreDispatch_Widgets_Listing‘.

public static function getSubscribedEvents()
{
    return [
        'Enlight_Controller_Dispatcher_ControllerPath_Widgets_XXXXXXX' => 'registerController',
        'Enlight_Controller_Action_PostDispatchSecure_Frontend_Listing' => 'onPostDispatchFrontendListing',
        'Enlight_Controller_Action_PreDispatch_Widgets_Listing' => 'onDispatchWidgetListing',
    ];
}

public function registerController(\Enlight_Event_EventArgs $args)
{
    $this->container->get('template')->addTemplateDir($this->getPath() . '/Resources/Views/');
    return $this->getPath() . '/Controllers/Widgets/XXXXXXX.php';
}

public function onPreDispatchWidgetListing($args)
{
    $subject = $args->get('subject');
    $view = $subject->View();
    $view->addTemplateDir($this->getPath() . '/Resources/Views/');
}

public function onPostDispatchFrontendListing($args)
{
    $subject = $args->get('subject');
    $view = $subject->View();
    $view->addTemplateDir($this->getPath() . '/Resources/Views/');
}

Gruß,
Debianer

Moin @debianer‍,

das liegt daran, dass in der Action in dem Widgets-Controller das Template direkt geladen wird.

Entsprechend hast du im PostDispatch, also  nach  Ausführung der originalen Action, keine Möglichkeit mehr in das Template einzugreifen.
Hat aber nichts mit dem eigentlichen Fehler dieses Threads zu tun.

Gruß,
Patrick