Liebes Forum schon wieder eine Frage. So langsam gewöhne ich mich an das Templating in Shopware. Eine Sache ist mir aufgefallen. Zum Beispiel beim Template _default/frontend/index/index.tpl existiert der Block {block name=‚frontend_index_navigation‘} Sehr merkwürdig an diesem Block ist, dass er
Tags enthält, die erst nach dem Blockende-Tag geschlossen werden. Zum Beispiel das
wird innerhalb des Blockes geöffnet und erst nach dem Blockende wieder geschlossen. Da bekommt man Schwierigkeiten, wenn man den Block im Template überschreiben will. Löschen kann man den Block nicht, weil ja danach noch schließende div-Tags kommen. [code] _default/frontend/index/index.tpl: … {block name=‚frontend_index_navigation‘} …
Hi, das ist hier schon mehrfach aufgefallen. Im allgemeinen Konsens (sag ich jetzt einfach mal so) haben wir es als unsaubere Arbeit klassifiziert. Wenn du das Default Template nicht ändern willst (wovon ja primär in 99,999% der Fälle eigentlich immer abzuraten ist), kannst du diese „Phantom“-Divs in dem von dir überschrieben Block erneut hinzufügen, oder die komplette Datei überschreiben (mein Nachfolger war schneller)
Das ist leider häufiger so im Standard-Template. Anderswo werden auch wichtige Sachen gar nicht in Blöcken definiert, sondern ausserhalb, so dass man gar nicht drumherum kommt die ganze Datei zu kopieren - was ja eigentlich durch das Block-System verhindert werden sollte. In deinem Beispiel (wieso eigentlich _default, _emotion ist die deutlich moderne Grundlage für ein eigenes Template) könntest du nur die Datei komplett übernehmen und dann das Div entfernen. Oder du lässt in deinem überschriebenen Block halt das div drin, entfernst aber die Klasse und den Inhalt - so hast du keine Probleme mit zusätzlichen schließenden Divs - nur halt ein überflüssiges leeres Div ohne Zweck. :happy: Edit: Einen Tick zu langsam.
Vielen Dank für die Antworten! hmmm… Unsauber? Ovi, du bist ein freundlicher Mensch. Ok, das kann man vielleicht irgendwie beheben. Aber was ist bei einem Update? Kann man sich denn zumindest darauf verlassen, dass diese “Unsauberkeiten” erhalten bleiben? Oder können die dann plötzlich weg sein und mein Workaround führt dann zu ungewollten Ergebnissen. Dann sucht und sucht man nach dem Fehler. Und überhaupt zur Updatefähigkeit: Dass man keine Änderungen im _emotion machen sollte wegen der Update-Fähigkeit setzt eigentlich voraus, dass dieses Template beim Update nicht verändert wird, weil man sich ja auf dieses Template mit den Änderungen bezieht. Wenn es aber konstant ist, dann könnte man es aber auch ändern. Man müsste dann nur das geänderte _emotion speichern und nach dem Update wieder aufspielen. Also bleibt das _emotion Template immer gleich? Liebe Grüße Kerstin:)
Bei einem Update wird zwar möglicherweise schon etwas am _emotion-Template geändert, aber normalerweise musst du eben dein Template welches auf _emotion basiert nicht komplett neu schreiben (das meint updatesicher) wie es der Fall wäre wenn du direkt _emotion modifizierst. Anpassungen im Zuge von Veränderungen im Template lassen sich nie vermeiden, wenn man ein selbstentwickeltes Template verwendet.
[quote=„Kerstin83“]Liebes Forum Zum Beispiel beim Template _default/frontend/index/index.tpl existiert der Block {block name=‚frontend_index_navigation‘} Sehr merkwürdig an diesem Block ist, dass er
Tags enthält, die erst nach dem Blockende-Tag geschlossen werden. Zum Beispiel das
wird innerhalb des Blockes geöffnet und erst nach dem Blockende wieder geschlossen. Da bekommt man Schwierigkeiten, wenn man den Block im Template überschreiben will. Löschen kann man den Block nicht, weil ja danach noch schließende div-Tags kommen. [code] _default/frontend/index/index.tpl: … {block name=‚frontend_index_navigation‘} …
… [/code] Ist das wirklich so gewollt? Kommt mir sehr merkwürdig vor. Liebe Grüße Kerstin :)[/quote] Hallo Kerstin, das von dir angesprochene Beispiel ist eigentlich weder komisch noch unsinn oder unsaubere Arbeit. Der einzige Punkt, den man diskutieren kann ist, ob der {block name=‚frontend_index_navigation_categories_top‘} wirklich innerhalb des Blocks mit den Wrappern stehen muss. Soll das horizontale Menü an dieser Position bleiben, ist es kein Problem, muss diese an eine andere Stelle, ist die Eleganz des Blocksystems nicht mehr wirklich vorhanden. Ein großes Drama ist es jedoch auch nicht. Das die Wrapper-Div in diesem Block nicht geschlossen werden, ist durchaus von Vorteil. Sie sind Wrapper für die gesamte „Shopseite“ unter dem Header. So hat man einen Block an dem der Wrapper-Beginn definiert wird und kann diesen einzeln bearbeiten ohne sich um die Vererbung von später erscheinenden Blöcken der Shopseite zu kümmern. Der Nachteil ist in der Tat, dass man sich um die
an anderer Position kümmern muss, wenn man dort einen eigenen Wrapper einfügen möchte. Wenn man so viele unterschiedliche Blöcke in ein Template packt, wie bei Shopware der Fall ist, dann kann man an viele Stellen leicht Änderungen einfügen, läuft aber mit an Sicherheit grenzender Wahrscheinlichkeit in die hier vorgefundene Situation. Sie ist der Preis für leicht durchführbare Anpassungen an vielen anderen Stellen. Viele Grüße H. Thomas
Also, inzwischen habe ich verstanden, warum das mit den Blöcken so merkwürdig gemacht wurde. Es liegt an der grundsätzlichen Umstellung der
-container von _default zum _emotion. In _default gibt es einen fast die ganze Seite umschließendes div:
. In _emotion wollte man wohl die Eigenschaften von diesem container nicht mehr überall haben, sondern nur noch in den Einkaufswelten. Das Logische wäre es gewesen, den
rauszuschmeissen. Das ging aber wohl aus Kompatibilitätsgründen nicht. Deswegen wurde die alles umspannende Klammer container_20 nach innen gezogen. Dadurch sind dann natürlich die Blöcke in Unordnung gekommen. Die Kompatibilität ist ja ganz schön, aber dieses Konstrukt ist doch ziemlich unübersichtlich. Waren das noch Zeiten, als es nur das _default Template als Grundlage gab. Das ist noch richtig schön übersichtlich. Und ich bin wirklich geneigt, dieses als Grundlage zu nehmen. Grundsätzlich wäre es doch vielleicht mal eine Idee, mehrere Templates zu haben. Eines, das aus Kompatibilitätsgründen aus den vorherigen “gebastelt” wird, das dann natürlich ein bisschen unübersichtlich ist, und ein neues, das sich auf keine vorherigen bezieht. Wäre für shopware natürlich etwas mehr Arbeit, aber wenn man einen neuen Shop aufbaut wesentlich leichter und wesentlich weniger Fehleranfällig. Liebe Grüße Kerstin Edit: ich muss mich korrigieren. Was Shopware gamacht hat ist überhaupt nicht unsauber. Da bin ich echt beruhigt. :thumbup: Wegen des realisierten grid-Systems war die Umsetzung gar nicht anders möglich. Der container_20 musste so heißen.
[quote=“Kerstin83”] Edit: ich muss mich korrigieren. Was Shopware gamacht hat ist überhaupt nicht unsauber. Da bin ich echt beruhigt. :thumbup: Wegen des realisierten grid-Systems war die Umsetzung gar nicht anders möglich. Der container_20 musste so heißen.[/quote] Ein neues Template auf _default aufzubauen ist eine ganz schlechte Idee. Dann sind alle neuen Funktionen von Shopware 4 nicht mehr vorhanden. Wenn einem das “alte” Layout besser gefällt, z. B. auf der Artikeldetailseite oder die Icons, dann kann man sich diese aus dem _default-Ordnern für das eigene Template ausleihen und die Blöcke teilweise wieder in den _default-Stand versetzen. Man muss allerdings aufpassen, dass die von den jQuery-Skripten benötigten HTML-Elemente, respektive Klassen/IDs, noch vorhanden sind. Viele Grüße H. Thomas
[quote=“Kerstin83”]Edit: ich muss mich korrigieren. Was Shopware gamacht hat ist überhaupt nicht unsauber. Da bin ich echt beruhigt. :thumbup: Wegen des realisierten grid-Systems war die Umsetzung gar nicht anders möglich. Der container_20 musste so heißen.[/quote] In diesem Fall mag es sicher einen Grund gehabt haben. Warum jedoch anderswo wichtige Bereiche ausserhalb von Blöcken oder Dateien komplett ohne Blöcke eingebaut wurden, entzieht sich meinem Verständnis leider völlig. Alles in allem ist _emotion teilweise unnötig verschachtelt bzw. unsauber aufgebaut. Das ist einfach ein Fakt. Da hilft dann nur, selbst Blöcke anzulegen, Inhalte umzuschichten und Depdendanzen aufzulösen.
Also ich will nicht wirklich auf das _default zurück. War nur so ein Gedanke, weil es sehr viel einfacher wäre. [quote=“Strongground”] …Da hilft dann nur, selbst Blöcke anzulegen, Inhalte umzuschichten und Depdendanzen aufzulösen.[/quote] Man müsste doch dann an die _emotion ran. Oder kann mann das irgendwie machen ohne die Updatefähigkeit zu gefährden?
[quote=“Kerstin83”]Oder kann mann das irgendwie machen ohne die Updatefähigkeit zu gefährden?[/quote] Ich meinte dass du das in deinem eigenen Template - basierend auf _emotion - machst. Bei allen bisherigen Templates, die nicht komplett auf Emotion basieren (und damit interessant, da anders sind), habe ich nach ein bisschen Schnüffeln gesehen, dass eigentlich der Großteil des Templates aus Überschreibungen von _emotion bestand. Siehe blaupunkt (http://www.blaupunkt-store.de/). Am liebsten würde ich mich mal einen Monat hinsetzen, und ein komplett neues Template auf die Beine stellen, welches im Grunde nichts mehr von _default oder _emotion mitnimmt ausser eben die grundsätzlichen Aufrufe von Textblöcken, Variablen etc. Aber wer bezahlt die Zeit …
[quote=“Kerstin83”]Also ich will nicht wirklich auf das _default zurück. War nur so ein Gedanke, weil es sehr viel einfacher wäre. [quote=“Strongground”] …Da hilft dann nur, selbst Blöcke anzulegen, Inhalte umzuschichten und Depdendanzen aufzulösen.[/quote] Man müsste doch dann an die _emotion ran. Oder kann mann das irgendwie machen ohne die Updatefähigkeit zu gefährden?[/quote] Sobald man Blöcke im eigenen Template mit neuem Inhalt füllt und nicht nur append oder prepend verwendet, sind die auch nicht mehr “updatefähig”. Also in dem Sinne, dass Ergänzungen/Korrekturen in den beiden Standardtemplates nicht mehr übernommen werden. Außerdem immer darauf achten, ob die Ajax-Funktionalitäten an den Inhalt der Blöcke gebunden sind (HTML-ELemente/Klassen).
Unsauber? Ovi, du bist ein freundlicher Mensch. Ok, das kann man vielleicht irgendwie beheben. Aber was ist bei einem Update? Kann man sich denn zumindest darauf verlassen, dass diese “Unsauberkeiten” erhalten bleiben? Oder können die dann plötzlich weg sein und mein Workaround führt dann zu ungewollten Ergebnissen. Dann sucht und sucht man nach dem Fehler. Und überhaupt zur Updatefähigkeit: Dass man keine Änderungen im _emotion machen sollte wegen der Update-Fähigkeit setzt eigentlich voraus, dass dieses Template beim Update nicht verändert wird, weil man sich ja auf dieses Template mit den Änderungen bezieht. Wenn es aber konstant ist, dann könnte man es aber auch ändern. Man müsste dann nur das geänderte _emotion speichern und nach dem Update wieder aufspielen. Also bleibt das _emotion Template immer gleich? Liebe Grüße Kerstin:)