NOVA-Template (JTL-Shop)

Was ist das NOVA-Template?

NOVA ist das Standard-Template, das jede JTL-Shop-5-Installation von Haus aus mitbringt. Es liefert ein vollständig responsives, funktionierendes Shop-Frontend — Kategorienavigation, Produktseiten, Warenkorb, Checkout — direkt nach der Installation, ohne dass eigenes Design nötig wäre. Technisch baut NOVA auf dem verbreiteten CSS-Framework Bootstrap auf, was ein modernes, mobil-first gedachtes Grid und aktuelle Komponenten mitbringt. Für Testinstallationen oder sehr einfache Shops reicht NOVA im Ausgangszustand oft schon aus.

In der Praxis ist NOVA aber vor allem eines: die Basis, auf der individuelle Shop-Designs aufgebaut werden. JTL pflegt NOVA kontinuierlich weiter — neue Shop-Funktionen, Sicherheitsupdates und Standardkonformität (etwa für GPSR-Pflichtangaben) fließen zuerst dort ein. Weil NOVA der gemeinsame Nenner nahezu aller JTL-Shop-5-Installationen ist, sind seine Komponenten — Navigation, Filter, Warenkorb, Checkout — breit erprobt und werden von den meisten Plugins und Erweiterungen ohne Zusatzaufwand unterstützt.

Vollbild

NOVA vs. EVO: Was ist der Unterschied?

NOVA ist nicht das erste Standard-Template von JTL-Shop. Sein Vorgänger heißt EVO und war das mitgelieferte Template der JTL-Shop-4-Ära. Mit dem Sprung auf JTL-Shop 5 wurde EVO durch NOVA abgelöst — technisch ein deutlicher Schnitt:

• NOVA (JTL-Shop 5) basiert auf einer moderneren Bootstrap-Generation. Das bringt ein modernes Grid-System, aktuelle Komponenten und eine sauberere Trennung von Struktur und Gestaltung.
• EVO (JTL-Shop 4) gehört einer älteren Generation an und nutzte eine frühere Bootstrap-Version. EVO-Anpassungen lassen sich nicht einfach nach NOVA übertragen.

Praktisch heißt das: Wer von JTL-Shop 4 auf 5 migriert, kann sein EVO-Template nicht mitnehmen. Das Design muss auf Basis von NOVA neu aufgebaut werden — in der Regel als Child-Template. Diese Migration ist einer der häufigsten Anlässe, bei dem Händler sich zum ersten Mal ernsthaft mit der Template-Struktur von JTL-Shop 5 beschäftigen.

Warum der Framework-Sprung zwischen den Generationen mehr ist als Kosmetik: Das neue Grid ist konsequent mobil-first gedacht, die Komponenten sind schlanker und aktuelle Design- sowie Barrierefreiheits-Standards lassen sich leichter umsetzen. Für einen Neustart auf JTL-Shop 5 ist das ein klarer Vorteil — für eine Migration von EVO bedeutet es aber, dass altes Markup und alte CSS-Klassen nicht eins zu eins passen und Anpassungen neu gedacht werden müssen.

Warum NOVA nie direkt anpassen?

Der zentrale Grund ist einfach: Updates. Bei jedem JTL-Shop-Update werden die NOVA-Dateien durch die neue Version ersetzt. Wer Farben, Layout oder Textbausteine direkt in den NOVA-Dateien verändert hat, verliert diese Änderungen beim nächsten Update ersatzlos — und muss sie mühsam rekonstruieren.

Das Child-Template-System von JTL-Shop 5 löst dieses Problem strukturell:

Ein Child-Template überschreibt gezielt einzelne Dateien (z. B. header.tpl, CSS-Dateien) und lässt alles andere unverändert von NOVA übernehmen. Kommt ein Update, werden nur die nicht überschriebenen NOVA-Dateien aktualisiert — die eigenen Anpassungen im Child-Template bleiben unberührt.

Child-Template richtig aufsetzen

Ein Child-Template ist technisch überraschend schlank. Alle Templates liegen im Verzeichnis templates/ der Shop-Installation; NOVA selbst findet sich dort im Ordner NOVA/. Ein Child bekommt daneben seinen eigenen Ordner, zum Beispiel templates/mein-shop/. Damit JTL-Shop dieses Verzeichnis als Kind von NOVA erkennt, enthält es eine Konfigurationsdatei (template.xml), in der NOVA als übergeordnetes Parent-Template eingetragen ist.

Ab da gilt ein einfaches Prinzip: Man kopiert nur die Dateien ins Child, die man tatsächlich ändern will. Soll etwa der Header angepasst werden, legt man die entsprechende .tpl-Datei unter demselben relativen Pfad im Child-Ordner ab und bearbeitet dort die Smarty-Auszeichnung. Eigene Styles kommen über eigenes CSS bzw. SCSS dazu, statt die NOVA-Stylesheets direkt zu verändern. Alles, was man nicht überschreibt — und das ist der weitaus größte Teil — zieht der Shop weiterhin unverändert aus NOVA.

Der Grund für diese Disziplin ist immer derselbe: Änderungen am Parent-Template NOVA überleben kein Update. Jede Aktualisierung von JTL-Shop ersetzt den NOVA-Ordner durch die neue Auslieferungsversion. Nur was im eigenen Child-Ordner liegt, ist davor sicher. Deshalb gehört selbst die kleinste Anpassung ins Child — nie direkt in NOVA.

Aktiviert wird das fertige Child-Template im Shop-Backend unter der Template-Verwaltung — dort erscheint es neben NOVA und wird per Klick zum aktiven Template. Das ist auch ein praktisches Diagnose-Werkzeug: Man kann jederzeit gefahrlos zwischen Child und NOVA-Standard umschalten, etwa um zu prüfen, ob ein Problem am eigenen Template oder am Shop-Kern liegt. Solange das Child nicht aktiv ist, sieht der Kunde weiterhin das unveränderte NOVA-Frontend.

Wie funktioniert die Update-Sicherheit im Detail?

JTL-Shop lädt beim Rendern zuerst nach Dateien im aktiven Child-Template und fällt nur dann auf NOVA zurück, wenn dort nichts Passendes existiert. Dadurch reicht es, wirklich nur die veränderten Templates, Stylesheets oder Sprachdateien im Child-Template abzulegen — der Rest wird transparent aus NOVA nachgezogen. Das ist vom Prinzip her vergleichbar mit dem, was in Shopify über eigenständige Themes statt Basis-Themes gelöst wird, auch wenn die zugrundeliegende Template-Sprache mit Shopify Liquid eine andere ist.

Technisch basiert NOVA auf der Smarty-Template-Engine in Kombination mit PHP. Wer aus dem Shopify-Umfeld kommt, muss sich also auf eine andere Denkweise einstellen: Statt Objects, Tags und Filtern wie in Liquid arbeitet man mit Smarty-Variablen, PHP-Klassen im Hintergrund und einer eigenen Plugin-Architektur, über die sich Funktionalität ergänzen lässt, ohne das Template selbst anzufassen.

Update-sicher anpassen: die Regeln

Damit ein Shop dauerhaft update-sicher bleibt, haben sich einige Regeln bewährt:

1. Nie direkt in NOVA arbeiten — jede Änderung gehört ins Child-Template, ausnahmslos.
2. Nur abweichende Dateien überschreiben — je weniger Dateien im Child liegen, desto mehr NOVA-Verbesserungen (Sicherheit, Performance) kommen automatisch an.
3. Eigenes CSS/SCSS statt NOVA-Styles ändern — Gestaltung über eigene Stylesheets ergänzen, nicht die mitgelieferten überschreiben.
4. Funktionalität über Plugins statt Template-Hacks — zusätzliche Features gehören idealerweise in ein Plugin, nicht in umgebaute Template-Dateien.
5. Versionskontrolle nutzen — Template-Änderungen mit Git nachvollziehbar halten, um im Fehlerfall zurückzukönnen.
6. Immer erst in einer Testumgebung prüfen — fehlerhafte Smarty-Syntax kann ganze Seiten lahmlegen; das darf nie zuerst im Live-Shop passieren.
7. Nach jedem Update das Child gegenprüfen — überschriebene Dateien können durch NOVA-Änderungen veralten und sollten nach größeren Updates kontrolliert werden.

Diese Regeln klingen nach Overhead, sparen aber genau den Aufwand, der sonst bei jedem Update erneut anfällt. Ein Shop, der von Anfang an sauber als Child-Template aufgesetzt ist, lässt sich über Jahre aktuell halten, ohne dass das Design bei jeder neuen JTL-Shop-Version neu gebaut werden muss.

Der OnPage Composer (OPC): Was er kann — und wo die Grenzen sind

Nicht jede Anpassung braucht Template-Code. Der OnPage Composer (OPC) ist der visuelle Baukasten von JTL-Shop 5: Per Drag-and-drop lassen sich Inhaltsbereiche zusammensetzen — Texte, Bilder, Banner, Produktslider oder eigene HTML-Blöcke — ganz ohne .tpl-Dateien anzufassen. Typische Einsatzfälle sind die Startseite, Landingpages und einzelne Content-Seiten.

Vollbild

Die Grenzen sind ebenso wichtig zu kennen: Der OPC bearbeitet Inhalte in dafür vorgesehenen Bereichen, nicht die grundlegende Template-Struktur. Das Layout von Kopf- und Fußbereich, der Aufbau der Produktdetailseite, der Checkout oder das grundsätzliche Grid lassen sich damit nicht umbauen — dafür führt kein Weg am Child-Template vorbei. Der OPC ist also ein mächtiges Werkzeug für Redaktion und Marketing, aber kein Ersatz für die Template-Entwicklung.

Ein angenehmer Nebeneffekt: OPC-Inhalte werden in der Datenbank gespeichert, nicht in Template-Dateien. Sie sind damit von Haus aus update-sicher und gehen bei einem Shop-Update nicht verloren — anders als direkte Eingriffe in NOVA. Für Redaktion und Marketing bedeutet das: Startseite und Landingpages lassen sich pflegen, ohne dass jemand aus der Entwicklung dazwischengeschaltet werden muss.

Wann ein eigenes Template statt eines NOVA-Childs?

Für die allermeisten Shops ist ein Child-Template auf NOVA-Basis die richtige Wahl. Ein komplett eigenständiges Template ohne NOVA-Bezug lohnt sich nur in Ausnahmefällen:

Der Preis eines eigenständigen Templates ist hoch: Man erbt keine NOVA-Weiterentwicklungen mehr und muss Sicherheits- und Funktions-Updates selbst nachbauen. Was als Freiheit beginnt, wird schnell zur dauerhaften Wartungslast. Deshalb bleibt selbst bei anspruchsvollen Designs das Child-Template in den meisten Fällen die wirtschaftlichere Lösung.

In der Praxis lässt sich fast jedes Designziel als NOVA-Child umsetzen — die Frage ist selten, ob es geht, sondern wie viel Entwicklungsaufwand dahintersteckt. Ein eigenständiges Template ist deshalb eher eine strategische Entscheidung großer Shops mit eigenem Team als ein gestalterischer Zwang.

Wie viel Aufwand steckt in einem Child-Template?

Der Aufwand hängt stark davon ab, wie weit sich das gewünschte Design vom NOVA-Standard entfernt. Reine Farb- und Logo-Anpassungen sind über CSS-Overrides im Child-Template in wenigen Stunden erledigt. Individuelle Layoutänderungen an Kategorie- oder Produktseiten, neue Filterlogiken oder zusätzliche Ausgabefelder — etwa für GPSR-Pflichtangaben aus eigenen Wawi-Attributen — bedeuten dagegen echte Entwicklungsarbeit an mehreren Template-Dateien gleichzeitig. Wichtig ist in beiden Fällen: Jede Änderung sollte in einer Testumgebung geprüft werden, bevor sie im Live-Shop landet, da fehlerhafte Smarty-Syntax ganze Seitenbereiche zum Absturz bringen kann.

Typische Fehler bei der NOVA-Anpassung

1. Direkte NOVA-Bearbeitung „nur zum Testen" — der häufigste Fehler. Selbst kurzfristige Änderungen sollten sofort ins Child-Template wandern.
2. Kein Child-Template von Anfang an angelegt — wird oft erst nach dem ersten verlorenen Update-Schmerz nachgeholt, dann mit deutlich mehr Aufwand als bei der Ersteinrichtung.
3. Zu viele Dateien komplett überschrieben statt punktuell angepasst — macht das Child-Template selbst schwer wartbar und lässt spätere NOVA-Verbesserungen (etwa Performance- oder Sicherheitsfixes) nicht mehr automatisch durchschlagen.
4. Fehlende Versionskontrolle — Template-Änderungen ohne Git oder vergleichbare Versionierung lassen sich im Fehlerfall kaum nachvollziehen.
5. Template-Anpassungen ohne Blick auf die Wawi-Anbindung — Änderungen an Produktseiten-Templates sollten immer im Zusammenspiel mit den über die JTL-Wawi gepflegten Feldern und dem JTL-Worker getestet werden, bevor sie live gehen.

Individuelles Shop-Design richtig aufsetzen

Ob Child-Template oder komplett eigenständiges Design — die Entscheidung hängt vom gewünschten Individualisierungsgrad und Budget ab. Wir setzen bei JTL-Shop-Projekten grundsätzlich auf Child-Templates, um Update-Sicherheit und Design-Freiheit zu verbinden, und übernehmen das als JTL Agentur komplett — von der Template-Struktur bis zur Umsetzung im JTL-Shop.