JTL Nova Child Template: Aufbau, Einrichtung & Best Practices

JTL Nova Child Template ist ein Mechanismus, mit dem du das Standard-Template NOVA update-sicher erweitern oder überschreiben kannst. Dabei lädt der JTL-Shop alle Dateien des Parent-Templates, außer denen, die du in dein Child-Template kopiert hast – diese überschreiben die Original-Dateien. So bleiben deine Anpassungen bei Updates erhalten, ohne dass du sie manuell neu eintragen musst.

In der Praxis nutzt du ein Child-Template, um Farben, Schriften, Layout-Elemente, JavaScript oder PHP-Funktionen gezielt anzupassen, ohne die Update-Fähigkeit des Shops zu gefährden. Du arbeitest dabei mit Smarty Blocks, SCSS-Variablen, eigenen Template-Dateien und kannst über die template.xml definieren, welche Dateien geladen oder überschrieben werden. Die Herausforderung liegt darin, nur die nötigen Dateien zu ändern und nach jedem Shop-Update zu prüfen, ob die Overrides noch kompatibel sind.

Warum du ein JTL Nova Child Template brauchst

Wenn du das NOVA-Template direkt im Parent-Ordner anpasst, gehen deine Änderungen bei jedem Update verloren. Das ist eines der häufigsten Probleme, die wir in E-Commerce-Projekten sehen: Nach einem Update sind individuelle Anpassungen verschwunden, der Header ist kaputt, Custom-CSS fehlt oder JavaScript-Funktionen greifen nicht mehr. Ein JTL Template als Child-Variante verhindert genau das.

Die Lade-Logik ist einfach: Der Shop lädt alle Dateien aus dem Parent-Template NOVA, außer jenen, die du im Child-Template abgelegt hast. Diese überschreiben die Parent-Dateien. So bleibt das Parent-Template updatefähig, während du im Child-Template gezielt nur die Dateien änderst, die du wirklich anpassen musst.

Wichtig aus der Praxis: Auch wenn dein Child-Template bei Updates nicht überschrieben wird, musst du nach jedem JTL-Shop-Update prüfen, ob deine Overrides noch korrekt funktionieren. Breaking Changes in Smarty Blocks, neue Includes oder geänderte Bootstrap-Variablen können dazu führen, dass deine Anpassungen nicht mehr greifen oder Layout-Fehler verursachen.

Grundstruktur eines NOVA Child Templates

Ein typisches JTL Nova Child Template besteht aus wenigen, aber wichtigen Dateien und Ordnern. Die Struktur orientiert sich am Parent, enthält aber nur die Dateien, die du tatsächlich angepasst hast. Das hält das Child-Template schlank und wartbar.

Die Basisstruktur sieht so aus:

• templates/NOVAChild/js/custom.js – eigene JavaScript-Dateien
• templates/NOVAChild/themes/my-nova/sass/ – SCSS-Dateien für Farben, Schriften, Abstände
• templates/NOVAChild/themes/my-nova/my-nova.css – generiertes CSS
• templates/NOVAChild/themes/my-nova/my-nova_crit.css – kritisches CSS für schnelleres First Render
• templates/NOVAChild/Bootstrap.php – Autoload, Smarty-Registrierungen
• templates/NOVAChild/template.xml – Metadaten, Parent-Verknüpfung, File-Einbindungen
• templates/NOVAChild/preview.png – Vorschaubild im Backend
• templates/NOVAChild/README.md – Dokumentation

Im Child-Template liegen idealerweise nur die Dateien, die du wirklich angepasst hast. Du musst nicht die gesamte Template-Struktur kopieren. Das reduziert den Wartungsaufwand erheblich und macht das Template übersichtlicher.

Namensgebung und Konventionen ab JTL-Shop 5

Ab JTL-Shop 5 gelten strikte Namenskonventionen. Der Ordnername des Child-Templates muss mit dem Namen in der template.xml übereinstimmen. Wenn du das Template umbenennst, musst du auch den Namespace in der Bootstrap.php anpassen.

Der Name darf keine Sonderzeichen enthalten, da alle Klassennamen der PSR-4-Spezifikation folgen müssen. Wenn du das Template beispielsweise MeinShopTemplate nennst, muss der Namespace in allen PHP-Dateien im Hauptverzeichnis dem Schema Template\MeinShopTemplate entsprechen.

In der Praxis bedeutet das: Wenn du das mitgelieferte NOVAChild umbenennst, passe sofort die Bootstrap.php an, sonst lädt der Shop die PHP-Klassen nicht korrekt und du siehst weder Smarty-Funktionen noch andere Registrierungen. Diese Konsistenz ist entscheidend für die Funktionsfähigkeit des Templates.

Die template.xml: Herzstück der Konfiguration

Die template.xml ist die zentrale Konfigurationsdatei deines Child-Templates. Hier definierst du den Parent, Metadaten, Responsiveness, Theme-Optionen und welche JavaScript- oder CSS-Dateien geladen oder überschrieben werden. Diese Datei steuert das gesamte Verhalten deines Child-Templates.

Ein Beispiel für eine saubere template.xml sieht so aus:

<Template>
<Name>NOVAChild</Name>
<Author>Max Mustermann</Author>
<URL>https://www.mein-shop.de</URL>
<Version>1.0.0</Version>
<ShopVersion>5.0.0</ShopVersion>
<Parent>NOVA</Parent>
<Preview>preview.png</Preview>
<Description>Dieses Template dient als Vorlage für ein eigenes Child-Template des NOVA.</Description>
</Template>

Das Attribut isFullResponsive="true" im Tag kennzeichnet, dass sich dein Template vollständig responsive verhält. Wenn du dein Child-Template vom NOVA-Template ableitest, solltest du dies immer auf true setzen. Das bewirkt, dass im Backend die Option "Standard-Template für mobile Endgeräte?" nicht mehr ausgewählt werden kann und eine Warnung ausgegeben wird, falls dies noch aktiviert ist.

NOVAChild-Vorlage als Startpunkt nutzen

Aus der Praxis empfehlen wir: Starte nicht bei null, sondern nutze die NOVAChild-Vorlage vom JTL Build-Server. Diese Vorlage bringt bereits alle nötigen Dateien mit und legt ein eigenes Theme "my-nova" an, das initial noch nicht das Aussehen des Shops ändert. Diese Vorlage spart dir erheblich Zeit und stellt sicher, dass die Grundstruktur korrekt ist.

Der Ablauf ist einfach:

1. Lade die komprimierte Datei vom JTL Build-Server herunter
2. Entpacke sie in deinen templates-Ordner
3. Beginne direkt mit der Modifikation

Achte darauf, dass der Ordner NOVAChild heißt. Wenn du einen anderen Namen verwenden willst, musst du nach dem Umbenennen auch den Namespace in der Bootstrap.php anpassen. Diese Konsistenz ist zwingend erforderlich.

Child-Template im Backend aktivieren

Sobald du das Child-Template im templates-Ordner abgelegt hast, musst du es im Backend aktivieren. Gehe dazu im Backend zu Einstellungen → Templates und klicke auf Aktivieren neben deinem Child-Template.

In der folgenden Eingabemaske kannst du im Abschnitt Theme dein Theme aus der Select-Box auswählen. Auch andere Template-Einstellungen nimmst du hier vor. Klicke anschließend am Ende der Seite auf Speichern, um das Template in Betrieb zu nehmen.

Nach dem Ändern von Template-Einstellungen oder dem Wechsel von Themes solltest du die entsprechenden Zwischenspeicher des Shops leeren. Navigiere dazu im Backend-Menü auf System → Cache, wähle Template in der Checkbox aus und klicke auf Absenden, um den Cache zu leeren. Dieser Schritt ist essentiell, damit deine Änderungen sichtbar werden.

Caching: Warum du nach Änderungen oft nichts siehst

Ein häufiges Problem in der Praxis: Du änderst eine Datei im Child-Template, lädst die Shop-Seite neu – und siehst nichts. Der Grund ist meist der Template-Cache. Der Shop speichert kompilierte Smarty-Templates zwischen, um Ladezeiten zu reduzieren. Nach Änderungen an .tpl-Dateien, CSS oder JavaScript musst du den Cache leeren.

Die Lösung: Gehe im Backend zu System → Cache, wähle Template aus und klicke auf Absenden. Danach siehst du deine Änderungen sofort. Ohne diesen Schritt bleiben Änderungen unsichtbar, was oft zu Verwirrung führt.

In größeren Projekten siehst du manchmal trotz Cache-Leerung keine Änderungen. Dann prüfe, ob Browser-Cache, CDN-Cache oder serverseitiges Caching aktiv ist. Insbesondere nach Theme-Wechsel und Template-Einstellungen ist Cache-Leerung Pflicht. Diese mehrschichtigen Caching-Mechanismen können die Fehlersuche erschweren.

Smarty Template Inheritance: Blöcke gezielt überschreiben

Smarty Blöcke sind der zentrale Mechanismus, um im JTL Nova Child Template gezielt einzelne Bereiche zu ändern, ohne komplette Dateien zu ersetzen. Smarty unterstützt Template Inheritance, das bedeutet: Du kannst im Child-Template nur die Blöcke überschreiben, die du wirklich anpassen willst.

Ein Smarty Block sieht so aus:

{block name='layout-header-head-title'}
    Mein Shop
{/block}

Wenn du diesen Block im Child-Template überschreibst, wird nur dieser Bereich geändert, der Rest der Datei bleibt unverändert. Das reduziert das Risiko, dass Updates deine Anpassungen brechen, erheblich.

Woran erkennst du Blocks im Code? Sie sind in den .tpl-Dateien mit {block name='...'} und {/block} markiert. Das NOVA-Template besitzt bereits viele vordefinierte Smarty Blöcke, die du beliebig verändern kannst.

Ein Praxisbeispiel: Du möchtest den Seitentitel anpassen. Finde in der header.tpl des Parent-Templates den Block layout-header-head-title, kopiere die Datei in gleicher Struktur ins Child-Template und überschreibe nur diesen Block. Der Rest der Datei bleibt unverändert. Diese chirurgische Präzision macht Child-Templates so wartbar.

Wie du eine .tpl-Datei gezielt anpasst

Wenn du eine Template-Datei verändern möchtest, kopiere sie aus dem Parent-Template und füge sie an der gleichen Stelle in dein Child-Template-Verzeichnis ein. Möchtest du beispielsweise den Seitenkopf anpassen, erstelle in deinem Child-Template-Verzeichnis den Ordner layout/ und darin die Datei header.tpl.

Wichtig: Ändere nur den relevanten Block, nicht die gesamte Datei. Änderungen ganzer Template-Dateien können weitreichende Folgen haben. Nach einem Update deines Shops musst du sicherstellen, dass die modifizierte Datei noch korrekt funktioniert. Gegebenenfalls musst du deine Änderungen erneut anpassen.

In der Praxis bewährt sich folgende Schrittfolge:

1. Finde die benötigte Datei im Parent-Template
2. Kopiere die Datei in gleicher Struktur ins Child-Template
3. Ändere im Child nur den relevanten Block
4. Teste die Änderung im Frontend gründlich
5. Leere den Template-Cache

So hältst du das Risiko gering, dass Updates deine Anpassungen brechen, und du behältst die Wartbarkeit. Diese disziplinierte Vorgehensweise zahlt sich langfristig aus.

JavaScript im NOVA Child Template: Einbinden und Überschreiben

Eigene JavaScript-Dateien legst du unter js/ ab. Wenn du Parent-JS überschreiben willst, fügst du in der template.xml dem File-Eintrag das Attribut override="true" hinzu und erstellst deine eigene Version der JavaScript-Datei im Unterverzeichnis js/.

Ein Beispiel:

<File override="true">js/global.js</File>

Ohne das override-Attribut würde die genannte Datei zusätzlich zur global.js des Parent-Templates eingebunden werden. Das führt in der Praxis oft zu doppelter Logik, mehr Gewicht und schlechteren Core Web Vitals. Diese Doppelladung kann Performance und Nutzererleben massiv beeinträchtigen.

Der Name des minifizierten und zum Browser übermittelten Javascripts (jtl3.js) ist eine feste Konstante und darf nicht angepasst werden.

Um den Ladevorgang der Shop-Seiten nicht zu stark zu verzögern, solltest du zusätzliche Skripte in der Templatedatei footer.tpl laden. Hierfür ist der Block {block name='layout-footer-js'} vorgesehen. Wichtig ist, dass du Skripte asynchron lädst. Füge dazu das Attribut async zu deinen Script-Tags hinzu, z. B. <script src="..." async></script>.

In größeren Projekten sehen wir oft, dass JavaScript im Head geladen wird, ohne async oder defer. Das blockiert das Rendering und verschlechtert die Core Web Vitals massiv. Lade JavaScript im Footer und asynchron, um Performance und UX zu verbessern. Dieser einfache Schritt kann die Ladezeit merklich reduzieren und die Nutzerzufriedenheit steigern.

JavaScript und Smarty: Konflikt mit geschweiften Klammern lösen

Smarty nutzt geschweifte Klammern {} für Variablen und Code-Ersetzungen. JavaScript nutzt ebenfalls {} für Code-Blöcke. Damit sich diese beiden Auszeichnungsarten nicht überschneiden, gibt es zwei bewährte Lösungen.

Für kleinere JavaScript-Codefragmente ersetzt du alle öffnenden und schließenden geschweiften Klammern durch zwei Smarty-Funktionen: {ldelim} für { und {rdelim} für }. Diese Methode ist einfach, aber bei viel Code unübersichtlich.

Für umfangreicheren Code empfehlen wir die übersichtlichere Variante mit den zwei Smarty-Tags {literal} und {/literal}. Mit diesen beiden Tags lässt sich ein größerer JavaScript-Block ganz einfach umschließen und von der Verarbeitung durch Smarty ausschließen.

Möchtest du in deinem JavaScript weiterhin Variablen durch Smarty ersetzen lassen, kannst du den literal-Block vor der Smarty-Variable beenden und nach ihr wieder beginnen. In diesem Fall hättest du zwei getrennte Literal-Blöcke, die Smarty nicht interpretiert. Die Variable in der Mitte wird dann wie gewohnt von Smarty ersetzt. Diese Technik erlaubt dir flexible Kombinationen.

CSS und SCSS im NOVA-Template: Sass-basierte Theme-Verwaltung

NOVA nutzt Sass (SCSS), eine Erweiterung der herkömmlichen CSS-Syntax. SCSS ermöglicht es, CSS ähnlich komfortabel zu schreiben wie Programm-Code. Du kannst Variablen für Farben, Schriften, Abstände und Rahmen definieren, die dann in allen Templates benutzt werden können.

SCSS braucht einen Präprozessor, um in CSS übersetzt zu werden. Je nach Shop-Version und Setup gibt es unterschiedliche Werkzeuge. In der Praxis bedeutet das: Du änderst die SCSS-Dateien, der Prozessor baut daraus CSS, und dieses CSS wird im Shop geladen.

Vorteil von SCSS: Du definierst Variablen zentral und nutzt sie überall. Wenn du die Primärfarbe ändern willst, änderst du eine Variable – und die Änderung wirkt sich auf alle Stellen aus, die diese Variable nutzen. Das ist schneller, konsistenter und wartbarer als "wildes" CSS drüberlegen.

Die relevanten Variablen findest du im Parent-Template unter templates/NOVA/themes/<theme>/sass/_variables.scss. Hier siehst du alle themerelevanten Variablen, die du überschreiben kannst. Teils werden auch aus dem zugrunde liegenden Bootstrap Regeln übernommen, das ist die Brücke zu jtl bootstrap css.

Best Practice: Überschreibe zuerst Variablen, bevor du Custom-CSS schreibst. Das hält dein Theme sauber und macht Updates einfacher. Diese Vorgehensweise spart dir später viel Aufwand bei der Wartung.

Eigenes Theme im Child-Template

Das NOVAChild bringt ein Theme "my-nova" mit, das initial noch nicht das Aussehen ändert. Die Theme-Struktur sieht so aus:

• sass/ – Quellen (SCSS-Dateien)
• my-nova.css – generiertes CSS
• my-nova_crit.css – kritisches CSS für schnelleres First Render

Kritisches CSS (my-nova_crit.css) wird inline im Head geladen, um das First Render zu beschleunigen. Das normale CSS wird nachgeladen. Diese Trennung ist Teil der Performance-Optimierung im NOVA-Template und verbessert die Core Web Vitals. Sie sorgt dafür, dass Nutzer schneller Inhalte sehen.

In der Praxis änderst du die SCSS-Dateien im sass/-Ordner, baust sie (mit dem entsprechenden Tool), und das generierte CSS wird im Shop geladen. Wenn du eigene CSS-Regeln hinzufügen willst, ohne SCSS zu nutzen, kannst du eine custom.css im Theme führen und über template.xml einbinden. Diese Flexibilität deckt verschiedene Arbeitsweisen ab.

CSS sauber einbinden: CSS Management im Child-Template

Du kannst eigene CSS-Dateien über die template.xml einbinden. Füge dazu einen File-Eintrag hinzu, z. B.:

<File>themes/my-nova/custom.css</File>

Das lädt die Datei zusätzlich. Wenn du eine Parent-CSS-Datei ersetzen willst, nutze das Attribut override="true".

Praxis-Hinweis: Kleine Overrides in einer eigenen Datei zu halten ist besser, als Kern-Dateien anzufassen. Aber Vorsicht: Zu viel Custom-CSS kann Performance, Specificity und Debugging verschlechtern. Halte dein CSS strukturiert und dokumentiere, warum du welche Regel hinzugefügt hast. Diese Dokumentation erleichtert die Wartung enorm.

Funktionsattribute: Template-Steuerung über JTL-Wawi

In JTL-Wawi kannst du in den Artikeldetails im Reiter "Attribute/Merkmale" sogenannte Funktionsattribute hinterlegen. Anders als Artikelattribute (Merkmale) werden Funktionsattribute nicht mehrsprachig definiert, da sie Funktionalitäten und Aktionen im Shop auslösen bzw. das Template steuern können.

Funktionsattribute stehen templateseitig in den Artikeldetails als Variable zur Verfügung und können artikelbezogen im Frontend abgefragt werden. Du greifst darauf zu mit:

{$Artikel->FunktionsAttribute['funktionsattributname']}

Wichtig: Schreibe Funktionsattributnamen auch dann in Kleinbuchstaben, wenn deren Namen in JTL-Wawi Großbuchstaben enthalten. Diese Kleinschreibung ist zwingend, um Zugriffsfehler zu vermeiden.

Ein Praxisbeispiel: Du möchtest ein Funktionsattribut highlightclass neu erstellen und abhängig davon den Hintergrund der Kurzbeschreibung auf der Artikeldetailseite in Gelb erscheinen lassen. Definiere die CSS-Klasse in einer eigenen custom.css, lade sie via template.xml, und füge in der details.tpl den Klassenstring abhängig vom Attribut ein:

{if $Artikel->FunktionsAttribute['highlightclass']}{$Artikel->FunktionsAttribute['highlightclass']} {/if}

Wenn das Attribut Sonderzeichen enthält, kannst du so darauf zugreifen:

{$Artikel->FunktionsAttribute['attribut-mit-sonderzeichen']}

Kategorieattribute und Kategorie-Funktionsattribute

Ähnlich den Funktionsattributen eines Artikels lassen sich in der JTL-Wawi in den Kategoriedetails auch Kategorieattribute definieren. Diese werden beim Synchronisieren zum Onlineshop übertragen und können dort Steuerungsaufgaben übernehmen.

Es werden Kategorie-Funktionsattribute und Kategorieattribute unterschieden. Kategorie-Funktionsattribute sind Key/Value-Paare für Steuerung im Template, während Kategorieattribute lokalisierte Werte (spracheabhängig) enthalten können.

Praxisnutzen: Kategorie-spezifische Banner, Layouts, Boxen oder SEO-Elemente steuern, ohne Hardcoding. Nutze die Smarty Debug-Konsole, um Attribute auf Kategorie-Seiten zu finden und zu prüfen. Diese Flexibilität erlaubt individuelle Kategorie-Gestaltungen ohne Template-Änderungen.

Sprachvariablen sauber lösen

Eigene Sprachvariablen legst du im Backend an: Einstellungen → Sprachverwaltung → Variable hinzufügen. Verwendung im Template:

{lang key=... section=...}

Praxisnutzen: Texte nicht hardcoden, für Multi-Language Shops wartbar halten. Wenn du Texte im Template direkt einträgst, musst du sie bei jeder Spracherweiterung manuell anpassen. Mit Sprachvariablen zentralisierst du die Verwaltung und hältst das Template clean. Diese Methode spart Zeit und verhindert Inkonsistenzen.

Eigene Smarty-Funktionen registrieren

Im NOVA-Child kannst du in der Bootstrap.php im Root eigene Smarty-Plugins registrieren. Die Datei wird automatisch geladen.

Warum das relevant ist: Du kannst komplexere Logik aus Templates herausziehen und wiederverwendbare Helfer für Template/Frontend erstellen. Ein Beispiel aus der Praxis: Eine Funktion zur Berechnung der Kreiszahl PI registrieren und im Template nutzen.

Ein Beispiel:

getSmarty()->registerPlugin(Smarty::PLUGIN_FUNCTION, 'getPI', [$this, 'getPI']);

Die Funktion getPI() kann dann im Template z. B. mit {getPI precision=12} verwendet werden. Diese Erweiterbarkeit macht das Template mächtig und flexibel.

Bestehende Smarty-Funktionen erweitern oder überschreiben

Wenn du bestehende Smarty-Funktionen aus dem NOVA-Template erweitern oder ersetzen willst, erstellst du im Child-Template eine eigene Plugins.php, die die Basisklasse templates/NOVA/Plugins.php erweitert.

Um deine Variante zu nutzen, musst du erst die alte Variante aus dem System entfernen ("unregister") und die neue definieren. Das geschieht in templates/NOVAChild/Bootstrap.php:

$smarty->unregisterPlugin(Smarty::PLUGIN_FUNCTION,'getTranslation');
$smarty->registerPlugin(Smarty::PLUGIN_FUNCTION, 'getTranslation', [$plugins, 'getTranslation']);

Praxis-Use-Case: Fallback-Verhalten bei fehlender Übersetzung robuster machen, damit keine leeren Strings oder Fehler im Frontend erscheinen. Diese Absicherung verbessert die Nutzererfahrung deutlich.

Produktlisten dynamisch erzeugen

Ab JTL-Shop Version 3.10 bis einschließlich 5.0 kannst du eigene Artikel-Arrays über eine Smarty-Funktion {get_product_list} erzeugen. Das ist nützlich, um auf bestimmte Artikel(-gruppen) abseits von Cross-Selling gesondert aufmerksam zu machen.

Parameter, die du nutzen kannst:

• kKategorie – Kategorie-ID
• nLimit – Anzahl der Artikel
• nSortierung – Sortierungsschlüssel
• kHersteller – Hersteller-ID
• cPreisspanne – z. B. "20_40.99"
• cAssign – Name der Smarty-Variable

Praxisnutzen: Manuelle Teaser ("Top-Produkte", "Bestseller", "Zubehör") ohne Cross-Selling-Abhängigkeit, Landingpages, Category-Enhancements für Conversion. Diese Funktion gibt dir volle Kontrolle über die Produktdarstellung.

OnPage Composer und Mount Points

Der OnPage Composer (OPC) ermöglicht es, Inhalte in vordefinierte Template-Bereiche zu platzieren. Diese Bereiche werden im Template über Mount Points ausgezeichnet.

Eigene Mount Points definierst du mit der Smarty-Anweisung:

{opc_mount_point id='mein-mount-point' title='Mein Bereich'}

Mit dem Parameter id gibst du dem Mount Point einen Identifikator, der für die Seite eindeutig sein muss. Optional kannst du den Parameter title mitgeben, der einen im OPC-Editor sichtbaren Anzeigenamen definiert.

Praxisnutzen: Marketing-/Content-Teams können Bereiche pflegen, ohne Entwickler für jede Textänderung zu brauchen. Entwickler behalten Struktur und Performance unter Kontrolle. Diese Trennung von Verantwortlichkeiten beschleunigt Workflows erheblich.

Boxenverwaltung als Alternative oder Ergänzung

Nicht jede Layout-Änderung muss über Template-Code erfolgen. Die Boxenverwaltung im Backend ermöglicht es, wiederkehrende Elemente zentral zu pflegen und an definierten Stellen zu platzieren.

Wann ist Boxenverwaltung sinnvoll? Für wiederkehrende Elemente, standardisierte Platzierung, Content-Blöcke, die häufig geändert werden. Wann ist Template-Anpassung nötig? Für strukturelle Änderungen im Header, Produktdetail-Layout, Footer, checkout-spezifische Anpassungen. Diese klare Abgrenzung hilft dir, die richtige Methode zu wählen.

Typische Praxisfehler vermeiden

Aus E-Commerce-Projekten kennen wir diese häufigen Fehler:

• Änderungen direkt im NOVA-Parent machen – Update bricht alles
• Ganze Dateien kopieren/ersetzen statt nur Blöcke zu überschreiben – hoher Wartungsaufwand
• JS/CSS im Head ohne async/defer – schlechtere Core Web Vitals
• Doppelt geladenes JS, weil override in template.xml vergessen wurde
• Cache nicht geleert – "funktioniert nicht"
• Zu viele schnelle CSS-Fixes – Specificity-Hölle, schwer zu debuggen
• Funktionsattribute falsch geschrieben (Groß/Klein) – Logik greift nicht
• Fehlende Dokumentation – nach Monaten weiß niemand mehr, warum etwas geändert wurde

Vermeide diese Fehler, indem du sauber arbeitest, dokumentierst und nach Updates prüfst. Diese Disziplin zahlt sich langfristig aus.

Entscheidungshilfe: Was gehört wohin?

In der Praxis stellt sich oft die Frage: Wo mache ich welche Anpassung? Hier eine klare Einordnung:

• Theme/SCSS – Farben, Typografie, Spacing, visuelle Anpassungen
• Child-Template .tpl – Layout-Struktur, Smarty Blocks, zusätzliche Includes/Mount Points
• Child-Template JS – Frontend-Interaktionen, Tracking-Integrationen (sauber, performant)
• PHP im Template (Bootstrap/Plugins) – Helper/Smarty-Funktionen, zentrale Logik
• Plugins – wenn Funktionalität systematisch wiederverwendbar/upgradefähig sein soll (z. B. komplexe Features, Integrationen)

Diese Aufteilung hält dein Child-Template wartbar, update-sicher und performant. Sie schafft klare Verantwortlichkeiten und erleichtert die Zusammenarbeit im Team.

Update-Checkliste nach JTL-Updates

Nach jedem JTL-Shop-Update solltest du folgende Punkte prüfen:

• Überschriebene Dateien/Blocks gegen neue NOVA-Version vergleichen
• JS Overrides (global.js etc.) auf Kompatibilität prüfen
• SCSS-Variablen/Bootstrap-Updates (Design-Drift)
• Smoke-Tests: Header, Checkout, Produktdetailseite, Kategorie, Suche
• Performance-Kurztest: Ladezeit/JS-Fehler in Konsole (weil Custom JS oft Updates "spürt")
• Cache-Leerung nach jedem Test

Diese Checkliste hilft dir, nach Updates schnell zu prüfen, ob dein Child-Template noch funktioniert, und Probleme frühzeitig zu erkennen. Regelmäßiges Testen verhindert böse Überraschungen im Live-Betrieb.

Sicherheit und Wartbarkeit aus E-Commerce-Projekten

Warum "kleine, isolierte Overrides" langfristig günstiger sind: Sie reduzieren das Risiko, dass Updates deine Anpassungen brechen. Warum dokumentierte Struktur (Ordner/Dateien) Teamarbeit erleichtert: Andere Entwickler verstehen schneller, was geändert wurde. Warum Performance (JS/CSS) direkt Umsatz/Conversion beeinflusst: UX, Speed, Stabilität – alles hängt zusammen.

In größeren Projekten sehen wir oft, dass Custom-Code ohne Dokumentation hinzugefügt wird. Nach Monaten weiß niemand mehr, warum eine Datei überschrieben wurde. Halte ein README.md im Child-Template, in dem du dokumentierst:

• Welche Dateien überschrieben wurden
• Warum sie überschrieben wurden
• Welche Smarty Blocks geändert wurden
• Welche SCSS-Variablen angepasst wurden
• Datum und Autor der Änderung

Das spart Zeit, Nerven und Geld. Diese Investition in Dokumentation amortisiert sich bereits beim ersten Update.

Fazit und nächste Schritte

Wenn du NOVA anpassen willst, arbeite immer über ein JTL Nova Child Template. Nutze die NOVAChild-Vorlage als Basis, konfiguriere das Theme sauber über SCSS-Variablen, erweitere Smarty Blocks gezielt, integriere JavaScript performant (Footer, async, Overrides korrekt) und etabliere Cache-Routinen sowie einen Update-Prüfprozess.

Die bewährte Reihenfolge aus der Praxis:

1. Child-Template installieren und aktivieren
2. Theme sauber konfigurieren (SCSS-Variablen zuerst)
3. Smarty Blocks gezielt erweitern
4. JavaScript performant integrieren (Footer, async, Overrides korrekt)
5. Cache-Routinen und Update-Prüfprozess etablieren
6. Dokumentation pflegen (README.md)

So hältst du deinen Shop update-sicher, performant und wartbar – und behältst die volle Kontrolle über Anpassungen, ohne bei jedem Update von vorne anfangen zu müssen. Für den Feinschliff an Ladezeiten und Stabilität lohnt sich zusätzlich eine gezielte JTL Shop Performance Optimierung. Ein sauber aufgesetztes Child-Template ist die Grundlage für langfristigen Erfolg im E-Commerce.

Wenn du parallel an Sichtbarkeit arbeitest, kann ein JTL SEO Plugin helfen, technische und inhaltliche SEO-Maßnahmen strukturiert umzusetzen.

Für Shopbetreiber, die zusätzlich andere Systeme bewerten, ist ein Blick auf ein WP E-Commerce Template als Vergleich sinnvoll.

Und wenn du im Rahmen von Kategorie- oder Kampagnen-Seiten wiederkehrende Grafiken planst, kann ein E-Commerce Banner Template bei der konsistenten Gestaltung unterstützen.