JTL Entwickler — Plugins, Templates und Schnittstellen
JTL deckt mit Bordmitteln sehr viel ab. Die verbleibenden Prozente sind aber oft genau die, an denen ein Geschäftsmodell hängt: eine Preislogik, die kein Standardfeld kennt, ein Datenformat, das ein Großkunde vorgibt, oder eine Shop-Funktion, die es so nicht gibt. Dafür braucht es einen JTL Entwickler — und die Disziplin, die Anpassung so zu bauen, dass sie das nächste Update übersteht.
Erst prüfen, ob es der Standard auch tut
Jeder Entwicklungsauftrag beginnt bei uns mit der Frage, ob er sich vermeiden lässt. Workflows, Eigenschaften, Versandprofile und vorhandene Plugins decken mehr ab, als viele vermuten. Was über Konfiguration lösbar ist, sollte über Konfiguration gelöst werden: Es kostet weniger, bleibt bei Updates unangetastet und lässt sich auch ohne uns weiterpflegen. Erst wenn die Bordmittel nachweislich nicht reichen, wird entwickelt.
Updatesicher gebaut
Child-Templates und Plugins statt Eingriffe in den Kern. Anpassungen überleben damit Shop-Updates, statt bei jedem Sprung neu nachgezogen zu werden.
Staging vor Produktion
Entwickelt und getestet wird auf einer Kopie, nicht am laufenden Shop. Updates werden dort vorab durchgespielt, bevor sie produktiv gehen.
Code bleibt bei Ihnen
Sie erhalten den Quellcode Ihrer Anpassungen. Kein Lock-in, der einen Wechsel des Dienstleisters technisch unmöglich macht.
Lesend, wo es um Daten geht
Eigene Auswertungen greifen lesend auf die Datenbank zu und sind so geschrieben, dass sie den Mehrplatzbetrieb nicht ausbremsen.
Plugin-Entwicklung für JTL-Shop
Der JTL-Shop lässt sich über Plugins erweitern, ohne den Kern anzufassen. Das ist der einzige Weg, der dauerhaft trägt: Wer stattdessen Kerndateien ändert, verliert die Anpassung beim nächsten Update oder blockiert das Update ganz. Typische Aufträge sind eigene Preis- und Rabattlogiken für B2B-Kunden, Funktionen im Bestellprozess, zusätzliche Zahlungs- oder Versandregeln sowie Anbindungen an externe Dienste.
Wie wir dabei vorgehen und woran sich ein sauber gebautes Plugin erkennen lässt, beschreibt der Beitrag zur individuellen JTL-Plugin-Entwicklung.
Template-Arbeit auf NOVA-Basis
NOVA ist das Standard-Template des JTL-Shops. Für gestalterische Anpassungen legen wir ein Child-Template an und überschreiben gezielt einzelne Bereiche, statt NOVA selbst zu verändern. Der Unterschied zeigt sich beim ersten Update: Ein Child-Template zieht die Verbesserungen des Eltern-Templates mit, eine Kopie mit eigenen Änderungen tut das nicht.
In der Praxis geht es dabei meist um die Bereiche mit direktem Umsatzbezug — Artikeldetailseite, Kategorieübersicht, Warenkorb und Checkout. Wer dabei an der Struktur arbeitet, sollte die SEO-Seite mitdenken; die technischen Punkte dazu stehen im Beitrag zur JTL-Shop SEO-Optimierung.
Workflows und eigene Übersichten in der JTL-Wawi
Vieles, was nach Entwicklung aussieht, ist in Wirklichkeit ein Workflow. Die Wawi kann auf Ereignisse reagieren — ein Auftrag erreicht einen Status, ein Bestand unterschreitet eine Schwelle, eine Zahlung geht ein — und daraufhin Aktionen auslösen. Richtig eingesetzt ersetzt das einen großen Teil der täglichen Klickarbeit. Der Beitrag zu JTL-Workflows zeigt die typischen Muster.
Wo Auswertungen fehlen, bauen wir eigene Übersichten auf Basis von SQL-Abfragen gegen die Wawi-Datenbank. Damit lassen sich Kennzahlen abbilden, die der Standard nicht kennt: Deckungsbeitrag je Vertriebskanal, Retourenquote je Artikelgruppe, Lieferfähigkeit über einen Zeitraum. Solche Abfragen laufen ausschließlich lesend und werden so geschrieben, dass sie im Mehrplatzbetrieb keine Sperren erzeugen.
Schnittstellen zu Drittsystemen
Die interessanten Integrationen sind meist die, für die es kein fertiges Plugin gibt. Je nach Gegenstelle bieten sich drei Wege an:
- Direkte Anbindung über die Schnittstellen des JTL-Shops — wenn die Gegenstelle eine brauchbare API hat und die Daten zeitnah fließen müssen.
- Dateibasierter Austausch über die JTL-Ameise — robust und nachvollziehbar, wenn es um Massendaten in festen Intervallen geht. Die Grundlagen dazu stehen im Beitrag zu JTL-Ameise: Import und Export.
- Eigene Middleware — wenn Formate übersetzt, Daten angereichert oder mehrere Systeme entkoppelt werden müssen. Sie hat den Vorteil, dass ein Ausfall der Gegenstelle nicht die Wawi blockiert.
Häufige Ziele sind Buchhaltungs- und Steuerberaterexporte, EDI-Anbindungen an Filialisten und Industriekunden, Versanddienstleister außerhalb des Standardumfangs sowie PIM- und Produktdatensysteme.
Shopanbindung und Datenabgleich
Der JTL-Worker ist die Komponente, die den Abgleich zwischen Wawi und Shop steuert. Die meisten Störungen, die als „Shop-Problem" gemeldet werden, sind in Wirklichkeit Worker-Themen: zu knapp bemessene Serverressourcen, Zeitüberschreitungen bei großen Datenmengen, fehlende PHP-Erweiterungen oder Firewall-Regeln, die den Zugriff blockieren. Wir gehen solche Fälle am Worker-Protokoll entlang an, statt an Symptomen zu arbeiten. Der Beitrag zur JTL-Wawi Shopanbindung beschreibt die Architektur und die häufigsten Fehlerquellen.
Beratung, Entwicklung oder flexible Kapazität?
Entwicklung ist einer von drei Wegen, auf denen wir mit JTL-Kunden arbeiten. Je nachdem, woran es gerade hakt, passt ein anderer:
Häufige Fragen
Wann braucht man einen JTL Entwickler statt einer Konfiguration?
Solange sich eine Anforderung über Einstellungen, Workflows oder ein vorhandenes Plugin abbilden lässt, braucht es keine Entwicklung — das ist billiger und updatesicherer. Entwicklung wird nötig, wenn Logik gebraucht wird, die der Standard nicht kennt: eigene Preisregeln, ein Datenformat, das kein Drittanbieter bedient, oder eine Darstellung im Shop, die sich mit Bordmitteln nicht erzeugen lässt.
Bleiben eigene Anpassungen beim nächsten JTL-Update erhalten?
Wenn sie richtig gebaut sind, ja. Im JTL-Shop arbeiten wir mit Child-Templates und Plugins statt mit Änderungen am Kern oder direkt am NOVA-Template. Damit überschreibt ein Update die eigenen Dateien nicht. Vollständig update-neutral ist keine Anpassung — deshalb gehört zu jedem Entwicklungsauftrag ein Test auf einer Staging-Umgebung vor dem Update, nicht danach.
Entwickeln Sie auch Auswertungen direkt in der JTL-Wawi?
Ja. Die Wawi erlaubt eigene Übersichten auf Basis von SQL-Abfragen gegen die Datenbank. Damit lassen sich Kennzahlen abbilden, die der Standard nicht mitbringt — etwa Deckungsbeiträge je Kanal, Retourenquoten je Artikelgruppe oder Auswertungen zur Lieferfähigkeit. Wichtig ist dabei, nur lesend zu arbeiten und die Abfragen so zu schreiben, dass sie den laufenden Betrieb nicht ausbremsen.
Können Sie JTL an Drittsysteme anbinden, für die es kein Plugin gibt?
Das ist einer der häufigsten Aufträge. Je nach Gegenstelle läuft die Anbindung über die Schnittstellen des JTL-Shops, über die Ameise für dateibasierte Übergaben oder über eine eigene Middleware, die zwischen Wawi und Drittsystem vermittelt. Typische Ziele sind Buchhaltung, EDI-Anbindungen an Filialisten, Versanddienstleister außerhalb des Standards und PIM-Systeme.
Übernehmen Sie auch bestehenden Code von einem anderen Dienstleister?
Ja, sofern der Quellcode vorliegt. Wir sichten zuerst, was vorhanden ist, und sagen ehrlich, ob Weiterpflege oder Neubau günstiger ist. Bei Plugins, die tief in den Shop-Kern eingreifen oder ohne Versionsverwaltung gewachsen sind, ist ein sauberer Neubau häufig der kürzere Weg.
