Neu Viel zu wenig Smarty-Blöcke im Template?

[Xantiva]

Im EVO-Template wird an einigen Stellen mit den {block}-Elementen von Smarty gearbeitet. Auf der JTL-Connect wurden diese auch angepriesen, wenn es um die Erstellung eines Child-Templates ging ...

... aber es sind viel zu wenig Blöcke im EVO-Template selber definiert.

Beispiel:
Im alten Shopsystem habe ich lange Kategoriebeschreibungen aufgesplittet. Ein Teaser wurde oben angezeigt, der Rest unter den Unterkategorien bzw. Produkten.

Wenn ich das nachstellen möchte, dann muss ich aus der Datei productlist/header.tpl den Block "productlist-header" modifizieren. Ok, das wird zwar nicht wirklich updatesicher, aber funktioniert. Aber wie kann ich unter den Artikeln meinen Rest anzeigen lassen? Die productlist/footer.tpl wäre die richtige Stelle, dort möchte ich was ans Ende anfügen. Das geht aber nicht, weil footer.tpl keinen Block beinhaltet. Ich muss die komplette Datei ins Child kopieren und kann dann erst unten etwas anfügen. Wäre der Inhalt der footer.tpl in einem Block organisiert, dann könnte ich im Child mit extends und block append updatesicher arbeiten.



Ist das etwas, an dem JTL arbeitet? Wird das Template künftig weiter "blockifiziert"?

 

[csaeum]

Frag ich mich auch https://forum.jtl-software.de/threads/wo-bleiben-die-smartybloecke.97798/

 

[FMoche]

Mach ein Ticket im Gitlab auf und wir schauen es uns an.
Wir können keine Gedanken lesen, wer wo welche Blöcke braucht.

 

[csaeum]

Ok FMoche

ich dachte halt ihr habt da schon selbst was in vorbereitung. Da es irgendwo mal hieß ihr baut das immer weiter aus.

Aber kein Ding ich mach da mal im Gitlab was auf.

 

[fibergirl]

Ich weiß gar nicht, ist das hier die aktuelle komplette Liste?
http://docs.jtl-shop.de/de/latest/shop_templates/blocks_list.html

Ich bin ja leider noch nicht soweit, mir den JTL- Shop "zurechtzustricken", habe aber eine Vielzahl von Änderungen vor (und brenne darauf, endlich konkret damit anzufangen).
Deshalb kann ich noch nicht beurteilen, was mir selbst fehlen wird.

Ich schlage aber vor, die gewünschten Blöcke hier im Forum (in diesen Thread?) zu sammeln. Hier können sie jedenfalls von den Interessierten gefunden und kommentiert werden und verteilen sich nicht gleichmäßig auf Forum, Feedback, gitlab ... usw.

 

[david]

Die Doku hinkt hinterher, bin mir auch nicht ganz sicher, inwiefern die Block-Doku oder eine vollständige aktuelle Liste mit Blocks überhaupt bei so vielen individuellen Anforderungen Unterstützung leisten.

Wenn ich eine Anpassung in einem Child-Template erstelle, dann gehe ich wie folgt vor:
Ich prüfe zunächst mit den Entwicklertools des Browsers, welche Ankerpunkte im Template für meine konkrete Anpassung in Frage kommen.
Wenn ich nicht weiß, welche Original-Tpl-Datei dahintersteckt, dann copy-paste ich z.B. eine eindeutige ID des Ankerpunkts in die Gitlab-Suche oder lokale IDE-Suche und finde so schnell das für die Ausgabe zuständige Template.
Dann prüfe ich, ob an der jeweiligen Stelle ein Block definiert ist, den ich im Child erweitern oder überschreiben kann.

 

[csaeum]

Ich stricke uns gerade ein neues Template aber leider muss ich tw komplette tpl Dateien ins Child kopieren und dann anpassen.

Wie sollte ich euch Vorschläge für Blöcke zukommen lassen?

Wollen wir diese hier sammeln? Mein Wissen bezüglich Gitlab und wie ich Codebeispiele einbringen kann sind nicht großartig gut.

 

[david]

@web-seo-consulting OK, schreib die Vorschläge dann einfach hier rein, ich kann sie dann übernehmen in unseren Issuetracker.

 

[csaeum]

Habe zb hier gerade ein Beispiel:

                {if $Einstellungen.artikeldetails.artikeldetails_kurzbeschreibung_anzeigen === 'Y' && $Artikel->cKurzBeschreibung}
                    {block name="productdetails-info-description"}
                    <div class="shortdesc" itemprop="description">
                        {$Artikel->cKurzBeschreibung}
                    </div>
                    {/block}
                    <div class="clearfix top10"></div>
                {/if}

Warum nicht den Bock um die komplette Schleife mit machen? Dann könnte man die Schleife und den Inhalt des Blockes im Child bearbeiten.

           {block name="productdetails-info-description"}
     {if $Einstellungen.artikeldetails.artikeldetails_kurzbeschreibung_anzeigen === 'Y' && $Artikel->cKurzBeschreibung}
                   
                    <div class="shortdesc" itemprop="description">
                        {$Artikel->cKurzBeschreibung}
                    </div>
                    <div class="clearfix top10"></div>

                {/if}                   {/block}

 

[fibergirl]

Oha, Vorsicht ... besser nicht bestehende Blöcke umdefinieren.
Da verlassen sich im Zweifel schon andere Templateersteller drauf.

Dann lieber einen zusätzlichen Block drumrum.

 

[csaeum]

Ich definiere keine um. Wollte nur wissen wieso so?

Weil andersrum hätte man gleich die Schleife mit drin. Wenn man zb die Schleife ändern möchte muss man dennoch mehr Aufwand hinnehmen.

 

[fibergirl]

Ja sicher, möglicherweise ist es andersherum praktischer, wenn man die Artikelanzeige etwas grundsätzlicher ändern möchte.

Aber nun ist es so, dass der Templateersteller sich bisher immer darauf verlassen konnte, dass die Bedingung

{if $Einstellungen.artikeldetails.artikeldetails_kurzbeschreibung_anzeigen === 'Y' && $Artikel->cKurzBeschreibung}

bereits erfüllt ist, wenn der Block aufgerufen wird.

Das wäre nach Deiner vorgeschlagenen Änderung nicht mehr der Fall.
Die Abfrage muss nun nachgeholt, d.h. der modifizierte Block müsste erneut geändert werden, um wieder dasselbe Ergebnis zu erzielen.

Sowas geht IMHO nicht, einmal definierte Blöcke müssen in der Funktion verlässlich bleiben, damit man damit arbeiten kann.

 

[csaeum]

Naja dann müsste man halt doch nur folgendes neu einbringen:

                   {block name="productdetails-info-description-loop"}
                 {if $Einstellungen.artikeldetails.artikeldetails_kurzbeschreibung_anzeigen === 'Y' && $Artikel->cKurzBeschreibung}
                    {block name="productdetails-info-description"}
                    <div class="shortdesc" itemprop="description">
                        {$Artikel->cKurzBeschreibung}
                    </div>
                    {/block}
                    <div class="clearfix top10"></div>
                {/if}
                   {/block}

Einfach um viele Schleifen das bauen.

 

[david]

OK, verstehe. Also die Abhängigkeit des Blocks zu der Bedingung ( bitte nicht weiter Schleife schreiben ) war in dem Fall offenbar beabsichtigt.
Ich kann aber nachvollziehen, dass du vielleicht genau an dieser Stelle, unabhängig von einer Einstellung oder dem Vorhandensein einer Kurzbeschreibung etwas einfügen möchtest.

Hab es aufgenommen und mir 2 mögliche Praxisbeispiele zur Verdeutlichung für die Anpassung ausgedacht: https://gitlab.jtl-software.de/jtlshop/shop4/issues/1052

 

[csaeum]

Ja schon gesehen im Gitlab.

Da ich gerade an einem Template von uns arbeite. Kann ich gerne noch ein paar Beispiele bringen.

Soll ich dazu einfach im Gitlab Issus machen oder lieber per Ticket an dich?

 

[fibergirl]

Ja, in diese Richtung müsste es gehen.

Obwohl - loop ... eigentlich ist es ja keine Schleife. Und der Name sollte möglichst sprechend sein.

In diesem Block gehts ja allgemein um den Umgang mit der Kurzbeschreibung (Anzeigen ja/nein, und wenn ,dann wie ...).
Also

{block name="productdetails-info-shortdescription"}

würde gut passen und ist anscheinend noch nicht vergeben.

 

[Xantiva]

An dem Beispiel wird deutlich, wie wichtig "richtige" Bezeichner sind. Der Blockname ist ... description, aber ausgegeben wird die Kurzbezeichnung (shortdescription). Die Beschreibungs selber wird in der tabs.tpl ausgegeben.

{block name="productdetails-info-description"}
  <div class="shortdesc" itemprop="description">
    {$Artikel->cKurzBeschreibung}

Die bestehenden der 4.04 sollte man keinesfalls ändern, aber bei den neuen Bezeichnern wirklich 100% treffende und sprechende Namen zu verwenden.

Mein Eingangsbeispiel habt Ihr bereits aufgegriffen und die Blöcke in der index.tpl gesetzt. Danke!

Das ist vielleicht eine Konzeptfrage, aber würde es nicht eher Sinn machen, grundsätzlich den Inhalt einer .tpl-Dateien in einen Block zu packen. Und zwar innerhalb der Datei und nicht in der übergeordneten Datei?

Beispiel footer.tpl:

{block name="productlist-footer"}
  {if $Suchergebnisse->Artikel->elemente|@count > 0}
    {if $Einstellungen.navigationsfilter.allgemein_tagfilter_benutzen === 'Y'}
      {if $Suchergebnisse->Tags|@count > 0 && $Suchergebnisse->TagsJSON}
       ...
{/block}

Das jetzige Prinzip verschlechtert die Lesbarkeit in der übergeordneten Datei:

    {block name="productlist-header"}
    {include file='productlist/header.tpl'}
    {/block}
...
    {block name="productlist-footer"}
    {include file='productlist/footer.tpl'}
    {/block}

statt

    {include file='productlist/header.tpl'}
...
    {include file='productlist/footer.tpl'}

 

[csaeum]

Da gebe ich @Xantiva generell recht.

Die Beschreibung der Blöcke sollte wirklich besser werden. Auch das mit den Blöcken wie sie obenschreibt finde ich super weil so könnte man einfach auch mal was einfach verändern und wenn es nur eine andere Datei includiert werden sollte.

Ich musste vor kurzen an einen Shopware was arbeiten. Die Blöcke dort sind wirklich super gewählt.
Beim menu gibt es zb zwei "leere" Block "before" und "after" hier kann man das Menu sehr einfach erweitern.

Warum machen wir hier nicht eine Liste wie und wo man Blöcke nutzen sollte, wie die heißen usw? Dann könnte @david dies als Issue starten wenn es schlüssig wäre.

 

[Xantiva]

Leere Blöcke für ein before und after? Das ist eigentlich nicht erforderlich. Dafür kannst Du doch bei dem Block-Element append bzw. prepend nutzen, oder?
http://docs.jtl-shop.de/de/latest/shop_templates/eigenes_template.html#anpassungen-uber-blocks

2. Neuen Inhalt an das Ende des im EVO-Templates definierten Textes hängen:

{extends file="{$parent_template_path}/layout/header.tpl"}

{block name="head-title" append} Mein Shop!{/block}

• Ursprüngliche Ausgabe: {$meta_title}
• Neue Ausgabe: {$meta_title} Mein Shop!

 

[david]

Leere Blöcke würde ich eigentlich gern vermeiden, das lässt sich eleganter mit append/prepend lösen.
Aber ja, es ist natürlich eine Konzeptfrage, wo an welchen Stellen die Blöcke definiert werden und wie diese benannt werden.

Die Vorschläge von @Xantiva finde ich gut, danke.