Neu Ersetzen ganzer .tpl Dateien klappt nicht mehr - Shop 5.3.2

[Groundhog]

Hallo zusammen,

Entweder bin ich jetzt ganz blöd oder ich übersehe was.

Ich hab gerade das Update auf Shop 5.3.2 vorgenommen. Jetzt erstelle ich eben ein neues Child Template und dabei ist mir aufgefallen, dass scheinbar keine ganzen .tpl Dateien mehr ersetzt werden.

Solange noch block-Anweisungen in der Datei sind, die man auch nicht genändert hat, wird der Code innerhalb des Blocks auch interpretiert. Lösche ich aber alle Blöcke und erstelle eigenen Code, dann wird wieder die Nova Datei verwendet.

Gibts hier etwas zu beachten, dass ich übersehen habe - oder ist das ein Bug? Wer kann hier licht ins Dunkel bringen?

LG Micha

 

[css-umsetzung]

Du brauchst mindestens den alles umschließenden Block

 

[Groundhog]

Du brauchst mindestens den alles umschließenden Block

Alles klar...wie realisieren ich dann eigene tpl Dateien? Folgen die Blöcke einem bestimmten Muster oder ist es egal wie sie heißen?

Und warum ist das jetzt eigentlich so?

 

[css-umsetzung]

Innerhalb von diesem alles umschließenden Block kannst du dann ja machen was du möchtest.

 

[Groundhog]

Innerhalb von diesem alles umschließenden Block kannst du dann ja machen was du möchtest.

Versteh ich soweit - aber wo kommt die Abfrage dazu her? Muss ja irgendwo hinterlegt sein, welche Blocknamen vorhanden sein müssen, damit dann ersetz wird. Was wenn ich eine neue Datei anlege, welchen Block muss ich dann schaffen, damit die Datei interpretiert wird?

Weißt du, welchen Grund es hat, das jetzt so zu lösen? War ja beim 4er nicht nötig Blöcke zu erhalten. Ich befürchte ja, dass JTL daran arbeite, den Endkunden nicht mehr zu ermöglichen Templates zu ändern oder gar selbst eines zu schreiben. In der Entwicklerdoku steht ja auch nichts davon, dass nun Blöcke stehen bleiben müssen (oder ist die einfach schlecht gepflegt).

 

[css-umsetzung]

An deiner Arbeitsweise ändert sich ja nicht so viel

Ich versuche es mal so einfach wie möglich zu erklären:

Du hattest früher die Möglichkeit, das du über extendend arbeitest, das bedeutete das du von den Blöcken abhängig warst die vorhanden waren, nur innerhalb der Blöcke hast du Änderungen durchgeführt, alles was außerhalb der Blöcke war wurde nicht berücksichtig.
Dann konntest du auch ohne das extendend arbeiten, dann hattest du die Möglichkeit auf der Seite zu machen was immer du wolltest, alles wurde angezeigt.

Die extendend Funktion ist nun praktisch der default, du musst die Blöcke definieren die du ändern möchtest, diese findest du ja in der original tpl und es ist immer die Block Definition der ersten Zeile.

Wenn du also alles machen möchtest was du willst, machst du nichts anderes als den umschließenden Block bei dir in deiner neuen tpl zu integrieren, innerhalb dieses Blocks kannst du nun machen was auch immer du möchtest.

Beispiel zeige ich mal die layout/header_logo.tpl:

{block name='layout-header-logo'}

    ich mach jetzt hier mein eigenes Ding

{/block}

Das ist also eigentlich alles recht einfach und hat nichts damit zu tun das man dem Shop Besitzer Steine in den Weg legen möchte, es ist halt nur eine andere Vorgehensweise die ich vernünftig finde.
Früher konnte man an diese tpl Dateien nichts davor und nichts dahinter einfügen ohne die ganze Seite ins Child zu legen, daher war der Wartungsaufwand bei Updates viel höher.

Wir SP haben auch darauf gedrängt das es so ist weil es eben Sinn macht.

 

[Groundhog]

An deiner Arbeitsweise ändert sich ja nicht so viel

Ich versuche es mal so einfach wie möglich zu erklären:

Du hattest früher die Möglichkeit, das du über extendend arbeitest, das bedeutete das du von den Blöcken abhängig warst die vorhanden waren, nur innerhalb der Blöcke hast du Änderungen durchgeführt, alles was außerhalb der Blöcke war wurde nicht berücksichtig.
Dann konntest du auch ohne das extendend arbeiten, dann hattest du die Möglichkeit auf der Seite zu machen was immer du wolltest, alles wurde angezeigt.

Die extendend Funktion ist nun praktisch der default, du musst die Blöcke definieren die du ändern möchtest, diese findest du ja in der original tpl und es ist immer die Block Definition der ersten Zeile.

Wenn du also alles machen möchtest was du willst, machst du nichts anderes als den umschließenden Block bei dir in deiner neuen tpl zu integrieren, innerhalb dieses Blocks kannst du nun machen was auch immer du möchtest.

Beispiel zeige ich mal die layout/header_logo.tpl:

{block name='layout-header-logo'}

    ich mach jetzt hier mein eigenes Ding

{/block}

Das ist also eigentlich alles recht einfach und hat nichts damit zu tun das man dem Shop Besitzer Steine in den Weg legen möchte, es ist halt nur eine andere Vorgehensweise die ich vernünftig finde.
Früher konnte man an diese tpl Dateien nichts davor und nichts dahinter einfügen ohne die ganze Seite ins Child zu legen, daher war der Wartungsaufwand bei Updates viel höher.

Wir SP haben auch darauf gedrängt das es so ist weil es eben Sinn macht.

Verstehe. Jetzt wo ich das weiß, erschließt sich mir auch der Sinn. Ich ändere meist soviel, dass eigentlich nur die wesentliche Logik vom ursprünglichen Template übrigbleibt (was ja nur an meinem Unvermögen liegt). Darum hab ich generell nie mit Blöcken gearbeitet - somit hatte ich auch die Problemstellung nie.

Super wäre allerdings, wenn das irgendwo in der Entwickler Doku stehen würde - dann müsste ich hier nicht deine Zeit verschwenden...aber mit den Dokus ist das ja so ne Sache