devnullrootdevnullroot MitgliedKommentare: 10 Danke erhalten: 0 Mitglied seit: Dezember 2014

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 https://issues.shopware.com/issues/PT-8405, ich weiß es aber ehrlich gesagt nicht. Oder ich seh den Wald vor lauter Bäumen nicht :(


Beste Grüße und Dank,
devnullroot

Antworten

  • devnullrootdevnullroot MitgliedKommentare: 10 Danke erhalten: 0 Mitglied seit: Dezember 2014

    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

  • Moritz NaczenskiMoritz Naczenski AdministratorKommentare: 5666 Danke erhalten: 1613 Mitglied seit: September 2013

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

  • devnullrootdevnullroot MitgliedKommentare: 10 Danke erhalten: 0 Mitglied seit: Dezember 2014

    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: https://issues.shopware.com/issues/SW-20183 (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

  • sonicsonic MitgliedKommentare: 1690 Danke erhalten: 448 Mitglied seit: Januar 2014

    Da ich ja erwähnt wurde... Wink
    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 !

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 bearbeitet November 2017 Mitglied seit: August 2011

    Moin zusammen!
    Moin @sonic@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 Shopware

  • arnebeckerarnebecker MitgliedKommentare: 347 Danke erhalten: 75 Mitglied seit: Juni 2017

    Danke @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.

  • EikeWarnekeEikeWarneke ModeratorKommentare: 2664 Danke erhalten: 546 bearbeitet November 2017 Mitglied seit: Juni 2013

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

  • sschreiersschreier MitgliedKommentare: 2578 Danke erhalten: 672 Mitglied seit: August 2014

    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

  • sonicsonic MitgliedKommentare: 1690 Danke erhalten: 448 bearbeitet November 2017 Mitglied seit: Januar 2014

    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. Wink Lustig wird es dann, wenn solche Hinweise aus der unwartbaren Spaghetti-Code-Ecke kommen. Sticking-out-tongue
    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.

  • arnebeckerarnebecker MitgliedKommentare: 347 Danke erhalten: 75 bearbeitet November 2017 Mitglied seit: Juni 2017

    @Aquatuning GmbH‍ und @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.

  • devnullrootdevnullroot MitgliedKommentare: 10 Danke erhalten: 0 bearbeitet November 2017 Mitglied seit: Dezember 2014

    Danke an @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

     

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 Mitglied seit: August 2011

    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 Shopware
     

    Danke von 2devnullroot puhas
  • mowlwurfmowlwurf MitgliedKommentare: 34 Danke erhalten: 10 Mitglied seit: April 2017

    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‍ 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

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 Mitglied seit: August 2011

    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 Shopware

  • devnullrootdevnullroot MitgliedKommentare: 10 Danke erhalten: 0 Mitglied seit: Dezember 2014

    Moin @Patrick Stahl‍, 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

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 Mitglied seit: August 2011

    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 Shopware

    Danke von 1mowlwurf
  • puhaspuhas MitgliedKommentare: 98 Danke erhalten: 31 Mitglied seit: November 2011
    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‍,

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

  • debianerdebianer MitgliedKommentare: 1 Danke erhalten: 0 Mitglied seit: Dezember 2017

    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

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 Mitglied seit: August 2011

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

    Gruß,
    Patrick Shopware

  • puhaspuhas MitgliedKommentare: 98 Danke erhalten: 31 Mitglied seit: November 2011

    Hallo @Patrick Stahl

    könntest du bitte noch was zu meiner Frage obendrüber sagen? Kann man im Event Theme_Inheritance_Template_Directories_Collected auch schon ein Smarty Plugin laden? Wenn ja, wie?

    Dankeschön

     

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 bearbeitet Dezember 2017 Mitglied seit: August 2011

    Moin @puhas‍,

    das kann ich dir gerade nicht ganz genau sagen, müsstest du einfach mal ausprobieren.
    Das kannst du ja erstmal Quick & Dirty direkt in engine/Shopware/Components/Theme/Inheritance.php#193 hiermit versuchen:

    Shopware()->Template()->registerPlugin(...);


    Sollte das funktionieren, kannst du ja den sauberen Weg über einen Subscriber und den DI-Container wählen.

    Gruß,
    Patrick Shopware

    Danke von 1puhas
  • ottschoottscho MitgliedKommentare: 2582 Danke erhalten: 252 Mitglied seit: Oktober 2010

    Guten Morgen @Patrick Stahl‍,

    kommst du evtl. diese Woche zum Problem von @mowlwurf‍?
    Wäre super.

    Grüße
    Ottscho

  • puhaspuhas MitgliedKommentare: 98 Danke erhalten: 31 Mitglied seit: November 2011
    Das kannst du ja erstmal Quick & Dirty direkt in engine/Shopware/Components/Theme/Inheritance.php#193 hiermit versuchen:
    Shopware()->Template()->registerPlugin(...);

     

    Danke Patrick, mit

    Shopware()->Template()->addPluginsDir(__DIR__ . '/SmartyPlugins/');

    funktioniert es schon mal.

    Habe zu kompliziert gedacht Gasp

  • mowlwurfmowlwurf MitgliedKommentare: 34 Danke erhalten: 10 Mitglied seit: April 2017

    So, dank @Patrick Stahl‍ ist mein Problem nun auch geklärt,

    hatte mit einer alten Plugin Template Struktur und der folgenden Funktion zu tun.

    $view->extendsTemplate('frontend/plugins/mein_plugin/listing.tpl');

    Diese ist deprecated und hat im Listing in Verbindung mit aktiviertem HTTP-Cache zu dem von mir beschriebenen fehlerhaften Verhalten geführt.

    Insofern man, wie ich in dem Fall nur bestehende Templates bearbeitet, sollte man die Templates in der Frontend Theme Struktur anlegen und auf das extendsTemplate verzichten, da diese dann automatisch geladen werden. Also "frontend/listing/listing.tpl" beispielsweise.

    Will man explizit ein neues/komplett eigenes Template verwenden sollte man die Funktion loadTemplate verwenden, darf in der, ich nenne sie mal custom.tpl dann nicht vergessen das entsprechende Template zu extenden, da sonst vom Rest der Seite nichts mehr geladen wird.

    Ich hoffe ich habe das verständlich wiedergegeben. Dadurch tritt jedenfalls das mysteriöse Verhalten mit dem HTTP-Cache nicht mehr auf. Und nochmals riesen Dank an @Patrick Stahl‍ für seinen Einsatz.

    Gruß

    Daniel

    Danke von 1Patrick Stahl
  • elbsurferelbsurfer MitgliedKommentare: 27 Danke erhalten: 0 bearbeitet 19. Juni Mitglied seit: März 2016

    @Patrick Stahl

    Ich verwende in meinem Plugin folgenden Code um im Backend ein Icon hinzuzufügen.

    public static function getSubscribedEvents()
        {
            return [
                'Enlight_Controller_Action_PostDispatch_Backend_Index' => 'addBackendTemplateDir',
            ];
        }
    
    
    /**
         * @param \Enlight_Event_EventArgs $args
         */
        public function addBackendTemplateDir(\Enlight_Event_EventArgs $args) {
            try {
                /** @var \Enlight_Controller_Action $controller */
                $controller = $args->getSubject();
                $view = $controller->View();
    
                if ($view->hasTemplate()) {
                    $view->extendsTemplate(
                        $this->getPath() . '/Resources/Views/backend/index/index.tpl'
                    );
                }
            } catch (\Exception $e) {
            }
        }


    Nun wurde mir folgender Fehler in 5.4.1 gemeldet: 

    MeinPlugin/Resources/Views/backend/index/index.tpl' not allowed by security setting

    Ich kann diesen Fehler aktuell nicht in einer SW 5.4.1 Installation nicht reproduzieren. Was kann hier der Fehler sein - für mich sieht die index.tpl Registrierung im Backend richtig aus. Hättest Du oder jemand anderes einen Tipp?

  • Patrick StahlPatrick Stahl ModeratorKommentare: 371 Danke erhalten: 136 Mitglied seit: August 2011

    Hallo @elbsurfer‍,

    dir fehlt schlichtweg das Hinzufügen deines Template-Ordners, also so:
    $this->addTemplateDir($this->getPath() . '/Resources/Views/');

    Ich würde dir aber auch empfehlen deinen "views" Ordner klein zu schreiben, aus Konsistenz-Gründen. :-)

    Gruß,
    Patrick Shopware

Anmelden oder Registrieren, um zu kommentieren.