Ich entwickle Plugins und OnPage-Composer-Bausteine für JTL-Shop 5 und Werkzeuge für JTL-Wawi. Jede Regel, auf die sich eine Erweiterung verlässt, lese ich im Quellcode von JTL nach, bevor ich darauf baue. Und nichts erreicht Ihre Kunden, bevor es geprüft ist — an einer Kopie des Shops oder in einer abgeschirmten Vorschau.
Ein Farbfeld, das sich einstellen lässt, aber nicht speichert. Eine Vorbestellung, die unmittelbar vor dem Bestellabschluss aus dem Warenkorb entfernt wird. Ein Stylesheet, das unter einem Template ausgeliefert wird und unter dem nächsten nicht. Keiner dieser Fehler hinterlässt eine Zeile im Fehlerprotokoll. Alle drei sind mir beim Bauen begegnet — und alle drei stehen genau so im Quellcode von JTL.
Deshalb arbeite ich andersherum als üblich: erst nachlesen, wie der Shop an der Stelle wirklich entscheidet, dann bauen. Was ich dabei finde, halte ich fest — in der Dokumentation des Plugins und, wo es anderen hilft, in den Werkstattberichten weiter unten.
Eingriffe in Warenkorb, Bestand und Bestellung — dort, wo der Shop nur an oder aus kennt. Beispiel: Vorbestellungen, begrenzt auf die Menge, die beim Lieferanten bestellt ist.
Eigene Bausteine, die Ihre Redaktion im OnPage Composer auf die Seite zieht — statt Abschnitten, die fest im Template stecken. Das Template bleibt unangetastet und damit update-fähig.
Rechtliche Anforderungen wie die EU-Gewährleistungsmitteilung, eingebaut über Bausteine und die Schnittstellen des Shops — ohne eine Datei des Templates zu ändern.
Sichern und Wiederherstellen bis hinunter auf ein einzelnes Plugin. Und ein Prüfstand, der ein Shop-Update vorher an einer Kopie durchspielt.
Bestands- und Dispositionsberatung und die PPWR-Verpackungsmeldung — gerechnet aus den Daten, die in Ihrer Wawi ohnehin stehen.
Jede Einstellung ist im Backend erklärt, jedes Plugin dokumentiert. Und in der Dokumentation steht auch, was ausdrücklich nicht geprüft werden konnte.
Beim Relaunch eines JTL-Shops steckte die Startseite in Vorlagen des Templates: Wer ein Motiv tauschen wollte, brauchte einen Entwickler, und ein Update des Basis-Templates konnte die angepassten Blöcke brechen. Daraus ist ein Plugin mit fünfzehn Bausteinen geworden — von der Bühne mit Bild oder Video über Themenwelten, Kategoriekacheln und Angebote bis zu einem Baustein, der eine Produktart mit ihren Baureihen erklärt. Dazu Einstellungen für Kopfbereich und Navigation.
Die Redaktion zieht die Bausteine im OnPage Composer auf die Seite und stellt Texte, Bilder und Farben selbst ein. Gebaut wurde im laufenden Shop, als Vorschau-Design — mit zwei voneinander unabhängigen Sperren, damit kein Besucher etwas davon sieht, bevor es fertig ist.
Alle fünfzehn Bausteine und was der Quellcode über sie verrät →
Plugins für JTL-Shop. Zwei davon laufen produktiv auf zwei Shops, zwei sind für einen Relaunch und für die EU-Pflichtangaben entstanden.
Bausteine für den OnPage Composer in einem Plugin, dazu zwei weitere für die Gewährleistungsmitteilung und das Garantielabel.
Zeilen Code allein im Bausteine-Plugin — PHP, Vorlagen, Stylesheets und Skripte.
geprüfte Zwischenstände der Bausteine zwischen dem 3. und 14. September 2026.
Seiten Praxisleitlinien der EU-Kommission ausgewertet, bevor das Gewährleistungslabel seine endgültige Form bekam.
geänderte Dateien im Template des Shops — in allen vier Plugins.
Gezählt an den Plugin-Paketen; Aussagen über JTL-Shop geprüft am Quellcode der Version 5.7.2 aus JTLs öffentlichem Repository, September 2026.
Wer an Verbraucher verkauft, muss ab diesem Tag mit einer amtlichen Mitteilung der EU auf die gesetzliche Gewährleistung hinweisen. Gibt der Hersteller eine Garantie über zwei Jahre hinaus, kommt ein eigenes Label dazu. JTL-Shop bringt beides ab Version 5.8 selbst mit.
Für Shops, die bewusst auf 5.7 bleiben, habe ich es als Plugin gebaut: zwei Bausteine, die amtlichen Dateien der Kommission unverändert, keine Datei des Templates angefasst.
Was die Leitlinien verlangen und wo der OnPage Composer an Grenzen stößt →
Wo der Shop entscheidet — ob ein Artikel kaufbar ist, welche Feldnamen der OnPage Composer selbst belegt, wann ein Hook greift —, lese ich im Quellcode nach. Die Dokumentation sagt, was gedacht war. Der Code sagt, was passiert.
Welches Template ist aktiv, wie stehen die Einstellungen, wie sind die Artikel in der Wawi gepflegt? Das messe ich lesend, bevor ich baue. Annahmen über einen fremden Shop sind die häufigste Fehlerquelle.
Jede Erweiterung kann ausfallen. Entscheidend ist, was dann passiert. Fehlt der Vorbestellung ein gültiger Lizenzschlüssel, gibt sie keine neuen Vorbestellungen frei — der Shop verkauft normal weiter. Ist das Vorschau-Design nicht aktiv, greift keine einzige Regel des neuen Kopfbereichs, statt im Live-Shop am falschen Ort zu wirken.
An einer Kopie des Shops oder in einer abgeschirmten Vorschau. Die Proben stehen mit ihrem Ergebnis in der Dokumentation — und ebenso, was sich nicht prüfen ließ.
Dazu der Update-Prüfstand und zwei Werkzeuge für JTL-Wawi — alle auf der Übersicht der JTL-Werkzeuge.
Verkauft leere Artikel gegen den Zulauf — höchstens so viele, wie beim Lieferanten bestellt sind.
Ansehen →Sichert Dateien und Datenbank und stellt gezielt wieder her — bis hinunter auf ein einzelnes Plugin.
Ansehen →Fünfzehn Bausteine für Startseite und Artikelseiten, dazu Kopfbereich und Navigation.
Ansehen →Die amtliche Mitteilung in 24 Sprachen und das Garantielabel — für JTL-Shop 5.7, ohne Template-Eingriff.
Ansehen →Was beim Bauen im Quellcode von JTL-Shop aufgefallen ist — mit Fundstelle, damit man es nachprüfen kann.
Fünfzehn Bausteine für einen Relaunch — und neun Regeln aus dem Quellcode, die in keiner Anleitung stehen.
Lesen →Die Pflichtangabe ab 27. September 2026 ohne Update auf 5.8 — und die Falle im OnPage Composer.
Lesen →Fünf Stationen des Bestellwegs, an denen JTL-Shop den Bestand prüft — und was ein Häkchen dort alles öffnet.
Lesen →Beschreiben Sie, was der Shop können soll. Ich sage Ihnen, wo JTL das heute entscheidet — und was ein Plugin dort ausrichten kann.
Individuelle Software und Werkzeuge für Betriebe, die mit Standardlösungen an Grenzen stoßen.