Hy, leider musste ich heute wieder feststellen, das die Ladereihenfolge in SW5 einfach falsch ist. Laut Support, wurde die Ladereihenfolge geändert, die aktuelle Reihenfolge in SW5 ist folgende: Bare > Responsive > Plugins > MeinTheme Das heißt also, wenn ich in meinem Template eine Header.tpl habe und im Plugin, sagen wir mal eTracker ebenfalls die header.tpl geändert, bzw. Informationen hinzugefügt werden sollen, greifen diese nicht. Werden ja durch mein Template wieder überschrieben. Die Plugins greifen mit anderen Worten immer nur beim Standard Template?? Jetzt muss ich also hingehen und bei jedem Plugin das ich einbinden möchte, manuell im eigenen Template die selben Sachen einbauen, und bei jedem Plugin Update das Risiko haben das die Seite an der Stelle nicht mehr funktioniert!? Wer bitte soll das supporten!? Die richtige Ladereihenfolge ist: Bare > Responsive > MeinTheme > Plugins Warum? Ganz einfach! Wenn ich ein Plugin schreibe, dann schreibe ich das um etwas zu ändern, hinzuzufügen oder zu überschreiben. Oder macht ihr alle nur Plugins für ein Standard Theme? Würde mich wundern. Oder habe ich das ganze System einfach nicht verstanden… Beispiel: ich habe in meinem Theme die Datei /index/header.tpl Wenn ich hier {block name=“frontend_index_header_css_screen”} nutze. kann ich per Modul nicht mehr {block name=“frontend_index_header_css_screen” prepend} nutzen. Die Änderung kommen einfach nicht an.
Hallo, Im Standard und so sollte es auch dokumentiert sein, haben die Plugins keinen Code in den Standard Templatedateien. Da sollte lediglich ein Include gemacht werden und der Code des Plugins sollte in einer eigenständigen unabhängigen Templatedateie abgelegt sein. Dann brauchst du nur das Include in dein Template übernehmen und bist weiterhin auch bei Updates kompatibel. Siehe auch: administration-f102/paypal-plus-und-shopware-5-das-funktioniert-nicht-t31057-10.html?hilit=Include#p135573 Natürlich sollte man ohnehin nur im Notfall eine ganze Datei im Template überschreiben. Streng genommen hat sich die Reihenfolge auch nicht geändert, sondern nur die extends template Methode. Aber natürlich ist das als Reihenfolge erläutert eher nachvollziehbar. Ich bin selbst auch kein Entwickler und kann daher wenig dazu im Detail sagen. Moritz
Hy, ich habe gerade noch das Beispiel eingefügt. Ausgangstemplate ist das Bare Template. Das ist auch gut so. Nun habe ich meine header.tpl erstellt: {extends file="parent:frontend/index/header.tpl"} {block name="frontend\_index\_header\_css\_screen"} ... {/block} Soweit so gut. Die Änderungen sind drin. Wenn ich nun aber ein Plugin habe, das per prepend ebenfalls an den Block will, überschreibt mein block das einfach wieder. header.tpl des Plugins: {extends file="parent:frontend/index/header.tpl"} {block name="frontend\_index\_header\_css\_screen" prepend} ... {/block} Jetzt habe ich hier aber mehrere Probleme. 1. ich möchte den Block komplett mit meinem Template überschreiben, da die Bare Informationen nicht benötigt werden. 2. Brauche ich aber die Informationen aus dem Plugin. 3. append und prepend kann ich nicht nutzen, da dann wieder die Bare Informationen enthalten sind, die ich ja nicht will…
Hy, leider habe ich nun, wegen der Ladereihenfolge wieder ein Problem. Um eine Klassen Informationen in der frontend/index/index.tpl hinzuzufügen, muss ich diese in mein eigenes Theme kopieren. (Oder das BARE Template ändern, was beim nächsten Update überschrieben wird.) Da die Stelle, die ich ändern möchte sich nicht in einem Block befindet. <section class="content-main container block-group">
in
<section class="content-main container block-group {if $sTarget == " detail>Jetzt bekomme ich ja mit allen Plugins, die auch nur 1 Block davon abändern Probleme.
Das geht so nicht…
Hallo, da macht es ja definitiv Sinn, dass du mal ein Ticket anlegst: jira.shopware.de Dann können wir bei einem der nächsten Updates da weitere Blöcke hinzufügen, dass würde ja bei diesem Problem schon deutlich helfen. Moritz
Hy, mit einem einfachen Block ist es hier nicht getan. Es befinden sich ja dann noch unterblöcke darin. Diese würde alle nicht mehr funktionieren wenn ich den übergeordneten Block in meinem Theme verwende. Im Grunde hat man hier nun eine Situation geschaffen, in der man ein Template nur ordentlich ändern kann, wenn ich davon ein Plugin mache oder eine Mischform erstelle. http://jira.shopware.de/?ticket=SW-13007
Hi, im Grunde ist die Reihenfolge ja gewollt und bleibt auch so bestehehen. Der Hintergund ist ja, dass die Plugins das Bare-Theme anpassen sollen und nicht dein Theme. So kannst du im Notfall noch Plugin-Sachen aus deinem Theme wieder entfernen. Aber bei einem Punkt hast du defenitiv recht. Es fehlen Blöcke in der index/index.tpl: jira.shopware.de/?ticket=SW-11918 Gruß Heiner
Hy, ich bring einfach nochmal ein Beispiel… Bare Template: {block name="Standard"}{/block} Plugin: {block name="Standard" append}Ich bin geändert worden und wurde nach dem Template per Store gedownloadet und will Informationen ändern{/block} Mein Theme: {block name="Standard"}Nichts da, ich bin das Theme ich habe mehr zu sagen als Bare oder ein Plugin.{/block} Was zeigt die Ausgabe: Nichts da, ich bin das Theme ich habe mehr zu sagen als Bare oder ein Plugin. Wer bekommt nun anfragen per Support, dass die Änderungen durch das Plugin, das nachträglich installiert wurde nicht greifen? Heißt mit anderen Worten, Plugins ändern nur das Standard Theme. Man muss jede Änderung die ein Plugin macht, manuell im Template einfügen und bei jedem Update muss der Template Ersteller sein Theme ändern. Das kann doch so nicht gewünscht sein und bedeutet unendlichen Aufwand für den Theme Ersteller.
Ja, bedeutet es. Der Theme-Ersteller muss nun sauber arbeiten/extenden. Ansonsten wäre es Arbeit, die der Plugin-Entwickler ja nicht mal umsetzten kann. Er kann es ja nur für das Bare-Theme umsetzen. Zusätzlich hat man dadurch übrigens den Vorteil, dass die Updates leichter sind und das Template-Anpassung über Plugins sich nicht mehr gegenseitig stören. Gruß Heiner
Ich habe mal ein append hinzugefügt zum Plugin. Ich finde, das hat an der Stelle nichts mit „sauber arbeiten/extenden“ selbst wenn ich extends nutze… bringt mir das als Theme, Plugin Entwickler garnichts. Das eine schließt jetzt das andere aus. Noch ein Beispiel: Bare Theme: [code] {block name=‚frontend_detail_description_our_comment‘} {if $sArticle.attr3} {* Comment title *} {block name=‚frontend_detail_description_our_comment_title‘}
{s name=‚DetailDescriptionComment‘}{/s} „{$sArticle.articleName}“
{/block} {block name=‚frontend_detail_description_our_comment_title_content‘}
{$sArticle.attr3}
{/block} {/if} {/block} [/code] Mein Theme, da ich das „Unser Kommentar zu“ nicht brauche {extends file='parent:frontend/detail/tabs/description.tpl'} {block name='frontend\_detail\_description\_our\_comment'}{/block} Wenn nun ein Plugin per append oder prepend an den block will: {extends file='parent:frontend/detail/tabs/description.tpl'} {block name='frontend\_detail\_description\_our\_comment' append}Ich will an den block dran, nach dem Standard inhalt{/block} Bekomme ich als Ausgabe: Da ich den Block ja in meinem Theme leer gemacht habe… Meine Meinung als Plugin Entwickler: Wie zum Teufel soll ich etwas an den Block hängen, wenn der Theme Entwickler den Block benutzt hat für seine Änderungen?!? Bedeutet, Stress mit dem Käufer. Meine Meinung als Theme Entwickler: Jetzt kommt ein heiden Aufwand auf mich zu, da ich jedes mal wenn ein Plugin installiert wird, das auf einen von mir geänderten Block zugreift. Heißt, Plugin Code kopieren und in mein Theme einbauen, bei jedem Update erneut prüfen ob sich was am Plugin geändert hat und die Änderung einfügen. Bedeutet, Unwartbarkeit, nicht Update kompatibel. Und jetzt möchte ich gerne eine Erklärung haben, wie ich den Content per Plugin ändern kann, oder wie ich als Theme Entwickler den vom Plugin bereitgestellten Content nicht überschreibe aber den Content vom Bare nicht bekomme.
Hi, es gibt 2 Wege das zu lösen. 1. Du löschst in deinem Theme nur diese Blöcke: {extends file='parent:frontend/detail/tabs/description.tpl'} {block name='frontend\_detail\_description\_our\_comment\_title'}{/block} {block name='frontend\_detail\_description\_our\_comment\_title\_content'}{/block} 2. oder du implementierst die entfernte Anpassung wieder in deinem Theme: {extends file='parent:frontend/detail/tabs/description.tpl'} {block name='frontend\_detail\_description\_our\_comment'} {include file='my\_plugin\_include.tpl'} {/block} my_plugin_include.tpl: {block name="ich\_brauche\_auch\_blöcke"} Ich will an den block dran, nach dem Standard inhalt {/block} So ist es zumindest aktuell vorgesehen. Das Problem ist übrigens auch nicht die Reihenfolge, sondern dass die „extendsTemplate“-Methode nicht mehr in Plugins verwendet wird. Gruß Heiner
Hy, ich folge jetzt mal der Erklärung. 1. Ich lösche in meinem Template den Block. Was zu folge hat, dass der Content vom Bare und Plugin wieder dargestellt wird. Der Content vom Bare soll aber nicht dargestellt werden, also ist dies keine Lösung des Problems. 2. Ich füge in meinem Template den leeren Block ein. Bare Template ist überschrieben, Plugin aber auch. Jetzt kommt ein Fremdanbieter Modul und möchte per append, prepend an den Block. Hier kracht es jetzt, da ich per include z.b. das PayPal Plus Modul nicht beachte. Warum auch, ist ja nicht von mir. Wenn es von mir wäre und ich würde es immer im Theme verwenden, würde ich es per Include einbauen. Alle anderen Plugins werden doch vom Theme Entwickler ignoriert. Sonst müsste ich doch für jedes Plugin ein include schreiben. Wo ist da der Sinn? Das bedeutet doch genau das was ich bereits geschrieben habe, ich muss den Content des Plugins in mein Theme manuell einbauen… Mir kommt es vor, als ob die Sichtweise hier komplett verdreht ist… Die Frage als Theme Entwickler ist doch: Wie bekomme ich Content vom Bare überschrieben, ohne Content von Plugins zu überschreiben, die erst später installiert werden ohne mein Theme anpassen zu müssen? Die Frage als Plugin Entwickler ist doch: Wie bekomme ich es hin, Content an einen Block zu hängen, ohne das mich das individuelle Theme des Seitenbetreibers daran hindert?
Hy, wollte gerade den block ‘frontend_forms_index_content’ abändern. Geht leider nicht. Wenn ich eine MeinTheme/frontend/forms/index.tpl mache und dort dies eintrage: [code]{extends file=‘frontend/index/index.tpl’} {* Forms Content *} {block name=‘frontend_forms_index_content’} {if $sSupport.sElements}
{$sSupport.name}
{block name=‘frontend_forms_index_elements’} {include file=“frontend/forms/elements.tpl”} {/block}
{/if} {/block}[/code] sind alle Formulare zerstört. Werden nicht mehr komplett geladen. Wenn ich : [code]{extends file=‘parent:frontend/forms/index.tpl’} {* Forms Content *} {block name=‘frontend_forms_index_content’} {if $sSupport.sElements}
{$sSupport.name}
{block name=‘frontend_forms_index_elements’} {include file=“frontend/forms/elements.tpl”} {/block}
{/if} {/block}[/code] Nutze, bekomme ich eine Fehlerseite. Template zerstört. Also habe ich den kompletten Content der Bare/frontend/forms/index.tpl genommen und meinen teil, ein simples h1 in h2 geändert. Problem: Eenn sich nun ein Plugin, aus welchen Gründen auch immer, an einen Block der jetzt betroffen ist hängen will, geht das nicht mehr. Ich hoffe es wird so langsam klar, das das Vorgehen, wie die Ladereihenfolge ist, nicht funktionieren kann. Bei den CSS oder LESS Dateien mag das ja sinnig sein, aber nicht bei den Blöcken.
Hy, möglicher Lösungsansatz um beide Welten, SW4 Logik als auch SW5 Logik bei zu behalten. Eine weitere Funktion bei den Blocken. Neben append und prepend auch “replace” zu nutzen. Denke bei den blocken ist: (Ist-Stand in SW5): Bare->Responsive->Plugin->MeinTheme {block name="MeinBlock"}Inhalt{/block} Hier überschreibt der block den kompletten Content von Bare als auch Plugins. Replace Logik: Bare->Responsive->MeinTheme->Plugin {block name="MeinBlock" replace}Inhalt{/block} Hier wird nur der Content vom Bare überschrieben, nicht aber der vom Plugin, der per append, prepend an den block gehängt wird. Mit der Logik wäre es um ein vieles einfacher Templates zu gestalten die Update und Plugin sicher sind.
[quote=“kadis”]Mit der Logik wäre es um ein vieles einfacher Templates zu gestalten die Update und Plugin sicher sind.[/quote] Genau den selben Gedanken hatte ich auch als ich diesen Thread durchgelesen habe, da mich dieses Problem im Moment genauso betrifft. Die Entscheidung ob der Inhalt der Plugins mit überschrieben wird dem Themeentwickler zu überlassen sehe ich auch als die beste Lösung für dieses Problem.
*push
*push Das Problem besteht immer noch… Nun wieder ein aktueller Fall. Kunde möchte im Frontend, im Warenkorbbereich als Titel stehen haben : Warenkorb und nicht wie vorgegeben: Warenkorb | www.Seitenname.de Also ändert man in der header.tpl unter seinem eigenem Template den Block {block name='frontend\_index\_header\_title'}{strip}{if $sBreadcrumb}{foreach from=$sBreadcrumb|array\_reverse item=breadcrumb}{$breadcrumb.name} {/foreach}{/if}{/strip}{/block} Jetzt habe ich ein Problem. Jetzt wird nicht mehr Warenkorb oder auch Registrierung im Titel dargestellt. Dies wird stumpf überschrieben… Das geht so nicht… Jetzt müsste ich für jede Seite ein if Abfrage einbauen oder jede tpl Seite editieren damit es wieder korrekt ist… Das bezahlt kein Shopbetreiber…
Ich gehe mittlerweile den Umweg wenn es nötig ist über ein „zusätzliches“ Theme-Plugin was dann als „Zwischenglied“ fungiert. Hilft nicht bei allen Konstellationen aber zumindest manchmal. Gruß
Es wäre wirklich schön, wenn Shopware hier eine vernünftige bietet - ich bin eben erst nach 2h Debugging auf diesen Thread gestoßen, weil ich mich gewundert habe, warum mein Plugin nicht in meinem Theme funktioniert, im Responsive-Theme aber schon. Die Ladereihenfolge ist doch völlig falsch, dass das Theme mehr Gewicht als das Plugin hat. Das muss meiner Meinung nach geändert werden. Die bessere Reihenfolge wäre: Bare -> Responsive -> Mein Theme -> Plugin
Hallo, die jetzige Reihenfolge hatten wir ja bei Shopware 5 nioht ganz ohne Grund eingebaut. Es gab zum Teil auch ein sehr großes Feedback an Usern, die diese Reihenfolge gewünscht haben. Um hier aber dem jeweiligen Templater/Entwickler zukünftig die Wahl zu lassen, dieses selbst zu bestimmen, ist geplant, hier eine Einstellung zu schaffen, so dass man entscheiden kann, welche Reihenfolge man nutzen möchte Sebastian