Guten Morgen, ich habe mehrere Plugins, die ich von SW 3.xx nach 5.1.1 portiere. Dabei kümmern sich nahezu alle Plugins um die Detailseite der Produkte. (Manche gleichzeitig, manche jedoch nur bei bestimmten Produkten) Wenn ich nun Teile des Frontend-Detail-Templates mit {extends … parent:} überschreibe, gewinnt das extends aus dem Plugin, welches zuerst im Smarty-Cache landete. (bzw, das Plugin, welches $view->addTemplateDir( __DIR__ . ‘/Views’ ); zum Zeitpunkt der Frontend-Detail Cache Store aktiv hatte) Ist das so richtig zusammengefasst ? Ich habe damit den Effekt, dass manche Plugins gar nicht mehr zum Zuge kommen (was Smarty angeht - der Code im Plugin lueft), und manche auf Produkten, für die sie gar nicht vorgesehen sind… (Natuerlich klappt es immer, wenn ich den Cache vorher loesche) Also entweder habe ich hier irgendetwas simples übersehen, oder das ist einfach noch nicht rund… Mein Workaround ist jetzt: Jedes Plugin macht bedingungslos sein addTemplateDir und ich fackle im Template mittels if-Bedingung ab, ob die Umschreibungen überhaupt erfolgen sollen - echt unschoen… Ich hoffe ich mache hier einfach nur einen kleinen Fehler oder habe etwas übersehen… Kann mir bitte jemand einen Tipp geben ?
Hi, benutzen deine Plugins noch “extendsTemplate”? Das ist im Frontend in SW5 eigentlich nicht mehr vorgesehen und kann meines Wissen zu den beschriebenen Problemen führen. Daniel
nein, benutzen sie nicht …
Das Verhalten kann ich übrigens bestätigen. Wenn deine Seite beim ersten Aufruf ohne das template Verzeichnis deines Plugins angezeigt wird, dann landet diese auch so im cache. Somit musst du zwingend dein Verzeichnis mit addTemplateDir() bekannt machen und innerhalb des templates prüfen, ob Änderungen angezeigt werden sollen. Viele Grüße
Danke @Aquatuning, ich hatte erstmal den Verdacht, dass ich an meiner Installation etwas verbaselt habe… Es wundert mich aber schon, dass bei einer so grossen Menge an verfuegbaren Plugins damit noch keine Probleme aufgetreten sind. Zumal ja m.W.n. die Beispiele fuer Plugins in SW5 das addTemplateDir() als Bedingung fuer die Ausführung der Templates darstellen… Wenn es immer so wie in meinem Fall ist, reicht es, wenn ein Plugin A z.B. frontend-detail als parent extended, und ein weiteres Plugin B für das aufgerufene Produkt entscheidet - „hier nicht…“ Die Entscheidung ist dann für immer … und noch schlimmer - wenn das Produkt aufgerufen wird, bei dem nun B aktiv wird und addTemplateDir macht, dann kommt auf einmal - bei gleichen extendeten Bloecken - die View von A zum Einsatz … So oder so, kann mir nicht vorstellen, dass das Standard-Verhalten ist…
Hi, ah, jetzt verstehe ich. Es gibt um bedingte Template-Includes. Das war in der 4er aber auch schon so: Eigentlich willst du das Template immer includieren / erweitern und dann im Template selbst deinen Switch drin haben. Ansonsten hast du genau solche Effekte, dass Smarty das Template mit bestimmten Blöcken cacht und andere Erweiterungen dann Ergebnislos bleiben. Bedingte Includes kannst du also nur da machen, wo die Bedingung Teil der compileId ist, mit der Smarty cacht. Meines Wissens für Shops, Template (e.g. Emotion vs. Responsive) und Sprache. Das zumindest legt die \Shopware\Models\Shop\Shop::registerResources nahe. Besten Gruß, Daniel
Hallo Daniel, vielen Dank für die Antwort. Da es jetzt in meinen Templates sehr “haesslich” aussieht: (Gerade bei ueberschriebenen Blocks) {block name="foo"} {if $mypluginactive} {else} {$smarty.block.parent} {endif} {/block} wäre es doch ggfls. denkbar, z.B. in diesem Fall (frontend/detail) die compile_id um die articleID zu erweitern. Kostet zwar ggfls. einiges an Plattenplatz, sollte jedoch diese Fälle deutlich einfacher (und nebenbei performanter) machen… Könnte gut eine zusätzliche Methode der View sein, so etwas wie public function myPostDispatchCallback(Enlight\_Event\_EventArgs $args) { $subject = $args-\>getSubject(); $request = $subject-\>Request(); $view = $subject-\>View(); $sArticle = $view-\>sArticle; $view-\>addCompileID( $sArticle['ordernumber'] ); ... Was meinst du ? Gruss Paul
Hi, genau, das erste Beispiel wäre die Empfehlung. Bei dem zweiten kann ich mögliche Nebeneffekte nicht abschätzen, davon würde ich eher abraten. Daniel