WERKSTATTBERICHT · ONPAGE COMPOSER

Fünfzehn Bausteine für den OnPage Composer.

Beim Relaunch eines JTL-Shops steckte die Startseite fest in Vorlagen des Templates. Daraus wurde ein Plugin mit fünfzehn Bausteinen, die die Redaktion selbst auf die Seite zieht und einstellt. Hier steht, was sie können — und was ich beim Bauen über den OnPage Composer gelernt habe, das in keiner Anleitung steht.

JTL-Shop ab 5.7 Version 0.34 · 15 Bausteine
AUSGANGSLAGE

Eine Startseite, die nur der Entwickler ändern konnte.

Das neue Design des Shops hatte seine Startseite in eigenen Vorlagen des Templates verdrahtet: Bühne, Themenwelten, Belege, alles fest im Code. Im OnPage Composer ließ sich davon nichts bearbeiten. Und die Vorlagen überschrieben Blöcke des Basis-Templates NOVA — genau die Stellen, die bei einem Update von NOVA brechen können, ohne dass es jemand merkt.

Bausteine für den OnPage Composer lösen beides auf einmal. Die Redaktion zieht sie auf die Seite und stellt Texte, Bilder, Farben und Abstände selbst ein. Das Template braucht keine eigenen Vorlagen mehr, und NOVA bleibt unangetastet. Alle Bausteine liegen in einer eigenen Gruppe der Palette, und jeder kann ein Hintergrundbild mit Ausschnitt und Abdunkelung tragen — einmal gebaut, fünfzehnmal genutzt.

DIE BAUSTEINE

Was die fünfzehn Bausteine können

Bühne

Bild oder Video im Endlosloop, mit Überschrift und Knopf. Drei Höhenmodi sorgen dafür, dass das Motiv auf keinem Bildschirm abgeschnitten wird: Bild bestimmt die Höhe, feste Höhe mit Fokuspunkt oder festes Seitenverhältnis.

Themenwelten

Ein Kachelraster mit vier, sechs oder acht Welten. Die ersten beiden sind doppelt so breit und stehen trotzdem exakt so hoch wie die schmalen daneben.

Kategoriekacheln

Liest den Kategoriebaum des Shops selbst: alle Kategorien unter einer Wurzel oder bis zu zwölf frei gewählte in eigener Reihenfolge. Kategorien ohne Artikel bleiben weg.

Angebote

Eine Produktreihe mit Warenkorb-Knopf. Name, Preis und Bild kommen aus dem Artikel — ein Variationsartikel zeigt „ab 49,90 €“ statt eines Preises, den es so nicht gibt.

Laufband

Ein durchlaufendes Band aus Schlagworten.

Produktfinder-Einstieg

Ein schmales Band, das in die Produktauswahl führt: Überschrift, Text und Knopf nebeneinander, auf dem Handy untereinander.

Text mit Bildcollage

Drei Aufteilungen derselben Fläche, von einem Bild bis zu einem großen und zwei kleinen. Die Bilder müssen kein bestimmtes Format haben; Schlagworte darunter werden auf Wunsch zu Verweisen.

Belege

Bis zu sechs nummerierte Kompetenz-Belege in zwei bis vier Spalten.

Teilen

Per WhatsApp, Facebook, X, Pinterest, E-Mail oder Link kopieren — ohne ein einziges Skript eines Anbieters und damit ohne Einwilligung. Wahlweise mit eigenen Links und Symbolen.

Kanäle

Die eigenen Profile auf zehn Plattformen. Symbol, Name und Markenfarbe bringt der Baustein mit; einzutragen ist nur die Adresse.

Hinweiskasten

Überschrift, Zeichen und formatierter Text — auf Wunsch nur bei Artikeln, die in der Wawi ein bestimmtes Funktionsattribut tragen.

Externe Skripte

Bewertungs- und Siegel-Widgets von Drittanbietern laden erst, wenn der Besucher im Consent-Manager des Shops zugestimmt hat. Abgesichert mit 16 automatischen Prüfungen.

Video

Videodatei oder YouTube in festem Seitenverhältnis. YouTube lädt über youtube-nocookie.com und — bei aktivem Consent-Manager — erst nach Zustimmung.

Produkt verstehen

Eine Produktart mit bis zu acht Baureihen als Reiter: Kennzahlen, Eigenschaften, Preis aus dem Artikel und ein Sonderelement je Produktart — eine Temperaturleiste, ein maßstäblicher Grundriss oder eine Farbwahl. Eine neue Produktart ist ein neuer Ordner, keine Codeänderung.

Produktgruppe

Eine Reiterebene darüber, in deren Bereiche die Redaktion beliebige Bausteine legt. Der Inhalt übersteht das Umbenennen eines Reiters.

Kopfbereich und Navigation

Farben, Logo, Suche und eine Schublade für Sortimente mit vielen Oberkategorien — als Einstellungen, ohne das Markup des Templates umzubauen. Unter 992 Pixeln bleibt das mobile Menü des Templates unangetastet.

IM LAUFENDEN SHOP

Gebaut im laufenden Shop — ohne dass ein Kunde es sieht.

Das neue Design entstand direkt im Shop: als Vorschau-Template, in dem die Redaktion im OnPage Composer arbeitet, während Besucher weiter das bisherige Design sehen. Das verlangt Sorgfalt an einer Stelle, die man leicht übersieht — dem Kopfbereich, dessen Einstellungen auf jeder Seite gelten.

Deshalb gibt es zwei voneinander unabhängige Sperren. Erstens liefert der Shop die Stylesheets des Plugins unter dem aktiven Template gar nicht aus — gemessen, als die Vorschau einmal auf das Live-Template zurückfiel: keine einzige Datei des Plugins im Quelltext. Zweitens hängt jede Regel des neuen Kopfbereichs an einer Kennung, die nur das Vorschau-Template trägt. Fällt eine Sperre weg, hält die andere. Und wird das Vorschau-Template einmal umbenannt, greift schlicht keine Regel mehr — der Ausfall geht in die harmlose Richtung.

Jeder Baustein wurde vor der Auslieferung geprüft, mit dem Stylesheet des alten Templates vor dem eigenen geladen — also genau der Kollision, die im Shop herrscht. Die Proben stehen mit ihrem Ergebnis in der Dokumentation, zusammen mit dem, was sich nicht prüfen ließ.

GEMESSEN, NICHT BEHAUPTET

Der Umfang in Zahlen

15

Bausteine in einer eigenen Gruppe der OnPage-Composer-Palette, dazu Einstellungen für Kopfbereich und Navigation.

14.000

Zeilen Code: 23 PHP-Klassen, 18 Vorlagen, 36 Stylesheets und 4 Skripte.

79

geprüfte Zwischenstände zwischen dem 3. und 14. September 2026.

16

automatische Prüfungen dafür, dass ein Drittanbieter-Skript erst nach der Zustimmung lädt — und nur ein einziges Mal.

0

Aufrufe an Google für Schriften. Sie liegen im Plugin, unter einer Lizenz, die genau das erlaubt.

0

geänderte Dateien im Template des Shops.

Gezählt am Plugin-Paket 0.34.0 vom 14. September 2026.

AUS DEM QUELLCODE

Neun Dinge über den OnPage Composer, die in keiner Anleitung stehen

Beim Bau sind mir Regeln begegnet, die JTL nirgends beschreibt — sie stehen nur im Code. Wo es um eine feste Stelle im Kern geht, habe ich sie zuletzt am Quellcode von JTL-Shop 5.7.2 nachgelesen; die übrigen sind beim Bauen gemessen.

1 · Neun Feldnamen sind schon vergeben

Jeder Baustein bekommt von JTL einen Reiter für Abstände, eigene Klassen und das Ausblenden auf bestimmten Bildschirmgrößen. Dieser Reiter belegt neun Namen: background-color, color, font-size, box-styles, custom-class und hidden-xs bis hidden-lg. Heißt ein eigenes Feld genauso, schreiben zwei Stellen auf denselben Schlüssel: Das Feld lässt sich im Editor einstellen, gespeichert wird es nicht. Aufgefallen ist es an einer Symbolfarbe, die nach jedem Speichern wieder weg war.

2 · Die Beschriftung eines Feldes wird roh ausgegeben

Beschriftung und Hilfetext eines Feldes gibt der Editor ungefiltert aus, nur die Beschreibung wird maskiert. Eine Beschriftung, die „<script>“ als Wort enthielt, öffnete deshalb ein echtes Skript-Element — und verschluckte den Rest der Einstellungen. Die Reiter ließen sich noch anklicken, zeigten aber ins Leere.

3 · Im Editor gilt eine andere Stylesheet-Datei

Im Shop lädt ein Baustein die Datei mit seinem Klassennamen, im Editor eine Datei namens preview.css. Fehlt sie, sieht die Redaktion im Composer einen ungestalteten Baustein, obwohl im Shop alles stimmt. Der Ausweg ohne doppelte Pflege: preview.css holt die eigentliche Datei per @import herein.

4 · Ein Stylesheet aus dem Manifest hängt am Template

Über das Manifest des Plugins registrierte Stylesheets kamen unter einem Template an und unter einem anderen nicht. Drei Zwischenstände zeigten deshalb keinerlei Wirkung, obwohl die Datei auf dem Server nachweislich die neue war. Verlässlich ist der Weg, den der Composer selbst vorsieht: Jeder Baustein bringt sein Stylesheet über die eigene Klasse mit — unabhängig vom Template.

5 · Ein einziger Fehler legt den ganzen Editor lahm

Für seine Palette lädt der Composer jede registrierte Baustein-Klasse. Ein Syntaxfehler oder eine abweichende Methodensignatur in einer einzigen davon, und der ganze Editor bleibt weiß — nicht nur der betroffene Baustein. Einmal war es eine Zeile, die PHP 7 noch angenommen hätte und PHP 8 ablehnt. Seitdem wird vor jedem Paket jede geänderte Datei geprüft.

6 · Genau ein Wurzelelement

Die Vorlage eines Bausteins muss genau ein äußeres Element erzeugen. Steht etwas davor — und sei es nur ein Verweis auf ein Stylesheet —, meldet der Kern „Portlet Template hat kein Markup erzeugt!“ und zeigt gar nichts an.

7 · Jede Artikelseite ist eine eigene Seite — auch jede Variante

Der Composer vergibt für jeden Artikel eine eigene Seite, für Variantenkinder ebenfalls (PageService::createCurrentPageId()). Ein Baustein, den die Redaktion auf einer Artikelseite ablegt, gilt deshalb nur für genau diesen Artikel. Was auf allen Artikelseiten stehen muss, gehört an einen Hook, nicht in den Composer — so ist das Gewährleistungslabel gelöst.

8 · Der Checkout hat keinen einzigen Andockpunkt

In den 22 Vorlagen des Checkouts von NOVA steht kein einziger Andockpunkt für den Composer; der Warenkorb hat fünf. Was vor dem Abschluss der Bestellung stehen soll, gehört deshalb in den Warenkorb oder auf die Artikelseite.

9 · Derselbe Aufruf, zwei verschiedene Ergebnisse

Der Smarty-Helfer, mit dem NOVA den Kategoriebaum liefert, gibt für die oberste Ebene andere Objekte zurück als für eine gewählte Unterkategorie — ohne die Methoden, die ein Baustein braucht. Das Ergebnis war ein leeres Raster, ohne jede Fehlermeldung. NOVA selbst geht über die Kinder des Kategorie-Objekts. Dorthin gehört die Verzweigung: in PHP, wo eine fehlende Methode auffällt, statt still eine leere Liste zu erzeugen.

HÄUFIGE FRAGEN
Kann die Redaktion die Bausteine ohne Entwickler pflegen?+
Ja. Texte, Bilder, Farben und Abstände stehen als Felder im OnPage Composer, jedes mit einer Beschreibung. Wo ein Baustein im Shop nichts anzeigen würde — etwa die Teilen-Leiste auf einer Seite ohne Artikel —, zeigt der Editor einen Hinweis statt einer leeren Fläche.
Was passiert mit platzierten Bausteinen bei einem Update des Plugins?+
Eine abgelegte Instanz speichert ihren Klassennamen und ihre Werte. Neue Felder bekommen Vorgabewerte, bestehende Einstellungen bleiben. Wo eine Änderung das Aussehen eines vorhandenen Bausteins verändert, steht das in der Dokumentation — samt dem Weg zurück zum alten Verhalten.
Lassen sich weitere Produktarten ergänzen?+
Ja, ohne Codeänderung am Baustein: Eine neue Produktart ist ein Ordner mit drei Dateien, den der Baustein selbst findet. Nachgewiesen mit einem Probe-Ordner, der nach dem Hochladen in der Auswahl stand.
Funktionieren die Bausteine mit meinem Template?+
Sie setzen auf den OnPage Composer, den NOVA und davon abgeleitete Templates mitbringen. Jede Regel hängt an einer eigenen Markierung, damit das Stylesheet des Templates sie nicht überstimmt — geprüft mit dem Stylesheet des alten Templates vor dem eigenen. Weicht Ihr Template stark ab, prüfe ich das vorher an Ihrem Shop.
Gibt es die Bausteine auch für meinen Shop?+
Entstanden sind sie für den Relaunch eines Shops. Ob und in welcher Form sie zu Ihrem passen, klären wir am besten im Gespräch.
PASST DAZU

Mehr aus der Entwicklung

KONTAKT

Steckt Ihre Startseite im Template fest?

Dann sehen wir uns an, welche Abschnitte sich in Bausteine überführen lassen, die Ihre Redaktion selbst pflegt.

4VEX.

Individuelle Software und Werkzeuge für Betriebe, die mit Standardlösungen an Grenzen stoßen.

© 2026 4VEX<EX/>