JTL-Shop-Plugin entwickeln lassen: Anforderungen, Aufwand und Projektablauf

Was ein individuelles JTL-Shop-Plugin leisten kann

Ein Plugin erweitert den JTL-Shop um Funktionen, die über reine Design- oder Templateänderungen hinausgehen.

Mögliche Einsatzbereiche sind:

• eigene Produktfunktionen
• individuelle Warenkorbregeln
• kundengruppenabhängige Inhalte und Prozesse
• zusätzliche Formulare
• Berechnungen anhand von Produkt- oder Kundendaten
• Verarbeitung externer Daten
• Schnittstellen zu Drittsystemen
• eigene Backendbereiche
• automatische Aufgaben
• zusätzliche Auswertungen und Protokolle

Die zentrale Leistung JTL-Pluginentwicklung umfasst die fachliche Planung, technische Umsetzung, Tests und Weiterentwicklung individueller Erweiterungen.

Wann ein individuelles Plugin wirklich notwendig ist

Vor einer Neuentwicklung sollte geprüft werden, ob JTL-Shop, das Template oder ein vorhandenes Plugin die Aufgabe bereits ausreichend erfüllt.

Ein individuelles Plugin wird besonders sinnvoll, wenn:

• unternehmensspezifische Regeln umgesetzt werden müssen
• neue Daten dauerhaft gespeichert werden
• eigene Einstellungen im Backend notwendig sind
• mehrere bestehende Funktionen miteinander verbunden werden
• externe Systeme angebunden werden
• eine Standardlösung dauerhaft manuelle Nacharbeit verursacht
• der Prozess für mehrere Produkte oder Shops skalieren soll
• die Funktion geschäftskritisch ist

Der Beitrag JTL-Shop-Plugin oder Templateanpassung zeigt, wann eine Templateänderung ausreicht und wann eine serverseitige Erweiterung erforderlich ist.

Vorhandene Plugins vor einer Neuentwicklung prüfen

Eine etablierte Standardlösung ist häufig wirtschaftlicher als eine vollständige Individualentwicklung.

Geprüft werden sollten:

• Funktionsumfang vorhandener Plugins
• Kompatibilität mit der eingesetzten Shopversion
• notwendige Konfigurationsmöglichkeiten
• Qualität von Wartung und Updates
• mögliche Erweiterbarkeit
• Abhängigkeit von einem bestimmten Template
• Lizenz- und Folgekosten

Deckt ein vorhandenes Plugin 90 Prozent der Anforderungen ab, muss bewertet werden, ob die fehlenden zehn Prozent wirklich eine eigene Entwicklung rechtfertigen oder ob der Prozess angepasst werden kann.

Phase 1: Das fachliche Ziel definieren

Zu Beginn muss beschrieben werden, welches konkrete Problem das Plugin lösen soll.

Wichtige Fragen sind:

• Welcher aktuelle Ablauf soll verändert werden?
• Welche manuelle Arbeit soll entfallen?
• Welche Fehler sollen verhindert werden?
• Welche Kunden oder Mitarbeiter nutzen die Funktion?
• Was muss nach erfolgreicher Ausführung geschehen?
• Welche bestehenden Prozesse dürfen nicht verändert werden?
• Wie wird der Erfolg der Funktion bewertet?

Eine Zieldefinition sollte nicht nur beschreiben, was sichtbar sein soll. Sie muss auch erklären, welche fachliche Wirkung die Funktion im Unternehmen oder im Kaufprozess erzielt.

Ein konkretes Ziel statt einer allgemeinen Funktionsliste

Eine lange Liste gewünschter Elemente ist weniger hilfreich als ein klar beschriebener Prozess.

Statt „Das Plugin benötigt ein Formular, eine Tabelle und mehrere Schaltflächen“ ist eine Beschreibung wie diese hilfreicher:

Ein Geschäftskunde soll auf der Produktseite eine gewünschte Länge eingeben. Das Plugin prüft den zulässigen Bereich, berechnet den Preis, speichert die Konfiguration im Warenkorb und übergibt alle Angaben nachvollziehbar an JTL-Wawi.

Aus dieser Beschreibung ergeben sich bereits Anforderungen an Eingabeprüfung, Berechnung, Datenspeicherung, Warenkorb und Auftragsübertragung.

Zielgruppen und Benutzerrollen festlegen

Nicht jeder Benutzer benötigt dieselben Funktionen und Berechtigungen.

Relevant können sein:

• nicht angemeldete Besucher
• Privatkunden
• Geschäftskunden
• bestimmte Kundengruppen
• Shopadministratoren
• redaktionelle Mitarbeiter
• technische Administratoren

Für jede Rolle sollte feststehen, welche Informationen sichtbar sind, welche Aktionen erlaubt werden und welche Änderungen eine zusätzliche Freigabe benötigen.

Phase 2: Den vollständigen Ablauf beschreiben

Der Prozess sollte vom ersten Auslöser bis zum endgültigen Ergebnis dokumentiert werden.

Dazu gehören:

1. Der Benutzer öffnet eine bestimmte Seite oder Funktion.
2. Das Plugin lädt die benötigten Daten.
3. Der Benutzer trifft eine Auswahl oder gibt Werte ein.
4. Die Eingaben werden geprüft.
5. Eine Berechnung oder Aktion wird ausgeführt.
6. Das Ergebnis wird gespeichert oder weitergegeben.
7. Der Benutzer erhält eine verständliche Bestätigung.
8. Fehler und Sonderfälle werden protokolliert.

Diese Beschreibung verhindert, dass während der Entwicklung immer neue Zwischenschritte entdeckt werden.

Standardfälle und Sonderfälle trennen

Viele Projekte werden auf Basis eines idealen Beispiels geplant und scheitern später an realen Ausnahmen.

Zu berücksichtigen sind beispielsweise:

• fehlende Produktdaten
• nicht verfügbare Varianten
• ungültige Kundeneingaben
• nicht angemeldete Benutzer
• abweichende Kundengruppen
• externe Dienste sind nicht erreichbar
• mehrere Browserfenster verändern denselben Vorgang
• der Benutzer bricht den Prozess ab
• der Warenkorb wird nachträglich verändert

Für jeden wichtigen Sonderfall sollte feststehen, ob er verhindert, abgefangen oder zur manuellen Prüfung weitergeleitet wird.

Phase 3: Datenquellen bestimmen

Ein Plugin kann nur zuverlässig arbeiten, wenn klar ist, woher die verwendeten Informationen stammen.

Mögliche Datenquellen sind:

• JTL-Wawi und Shopabgleich
• Artikelattribute
• Funktionsattribute
• Merkmale
• Kundengruppen
• Warenkorb und Session
• eigene Plugin-Datenbanktabellen
• externe APIs
• Importdateien
• Backend-Einstellungen

Für jedes Feld sollte festgelegt werden, welches System die verbindliche Quelle darstellt und wie Änderungen aktualisiert werden.

Bestehende JTL-Daten möglichst weiterverwenden

Informationen sollten nicht ohne Grund doppelt gespeichert werden.

Ist ein Wert bereits zuverlässig über JTL-Wawi im Shop verfügbar, sollte geprüft werden, ob das Plugin ihn direkt nutzen kann. Eine zusätzliche eigene Speicherung erhöht:

• Synchronisationsaufwand
• Risiko widersprüchlicher Daten
• Wartungsaufwand
• Fehlerquellen bei Updates

Eine eigene Datenhaltung ist sinnvoll, wenn das Plugin Informationen benötigt, die JTL-Shop oder JTL-Wawi nicht in geeigneter Form bereitstellen.

Verbindliche Datenquelle festlegen

Besonders bei Preisen, Beständen und Produktinformationen darf nicht unklar sein, welches System den gültigen Wert bestimmt.

Wird ein Wert gleichzeitig in JTL-Wawi, im Plugin und über eine externe Schnittstelle verändert, entstehen schnell Überschreibungen und widersprüchliche Ergebnisse.

Dokumentiert werden sollte:

• wo der Wert gepflegt wird
• wann er übertragen wird
• welches System bei Abweichungen Vorrang besitzt
• wie Fehler erkannt werden
• wer Änderungen vornehmen darf

Phase 4: Das Datenmodell planen

Eigene Datenbanktabellen sollten vor der Umsetzung fachlich und technisch geplant werden.

Zu klären sind:

• welche Informationen gespeichert werden
• welche Datentypen benötigt werden
• welche Datensätze miteinander verbunden sind
• welche Werte eindeutig sein müssen
• wie Zeitpunkte und Änderungen dokumentiert werden
• welche Daten gelöscht oder archiviert werden dürfen
• welche Daten personenbezogen sind
• welche Abfragen später häufig ausgeführt werden

Ein ungeplantes Datenmodell lässt sich später nur mit hohem Aufwand erweitern und kann Performanceprobleme verursachen.

Eigene Tabellen statt Änderungen an JTL-Standardtabellen

Plugin-Daten sollten möglichst in klar abgegrenzten eigenen Tabellen gespeichert werden.

Direkte Veränderungen an Standardtabellen des Shops können:

• Updates erschweren
• Konflikte mit anderen Plugins verursachen
• Deinstallation und Datenbereinigung erschweren
• bestehende Shoplogik unerwartet beeinflussen

Vorgesehene Schnittstellen, Services und Erweiterungspunkte sollten gegenüber direkten Eingriffen bevorzugt werden.

Personenbezogene Daten früh berücksichtigen

Sobald ein Plugin Kunden-, Kontakt- oder Nutzungsdaten speichert, entstehen zusätzliche Anforderungen.

Geprüft werden müssen:

• Zweck der Speicherung
• notwendiger Umfang
• Zugriffsrechte
• Aufbewahrungsdauer
• Löschmöglichkeiten
• Exportierbarkeit
• technische Absicherung

Nur weil Daten technisch gespeichert werden können, sind sie nicht automatisch für die Funktion notwendig. Datensparsamkeit reduziert rechtliche und technische Risiken.

Phase 5: Backend und Einstellungen planen

Ein gutes Plugin darf nicht für jede kleine Änderung einen Eingriff in den Quellcode benötigen.

Im Backend können beispielsweise konfiguriert werden:

• Aktivierung einzelner Funktionen
• Texte und Hinweise
• Grenzwerte
• Zuordnungen zu Kategorien oder Kundengruppen
• API-Zugangsdaten
• E-Mail-Empfänger
• Protokollierungsumfang
• Darstellungsoptionen

Einstellungen sollten verständlich benannt, gruppiert und mit sinnvollen Standardwerten versehen werden.

Nicht jede technische Option im Backend freigeben

Zu viele Einstellungen können die Bedienung unnötig kompliziert und fehleranfällig machen.

Konfigurierbar sollten vor allem Werte sein, die sich im Geschäftsbetrieb tatsächlich ändern können. Technische Grundlogik und sicherheitsrelevante Einstellungen sollten nicht ohne Not frei bearbeitbar sein.

Sinnvoll ist eine Trennung zwischen:

• normalen redaktionellen Einstellungen
• fachlichen Regeln
• technischen Administratoroptionen

Backend-Berechtigungen festlegen

Nicht jeder Shopmitarbeiter darf kritische Pluginregeln oder Zugangsdaten verändern.

Zu prüfen ist:

• Wer darf Einstellungen ansehen?
• Wer darf sie verändern?
• Wer darf Daten exportieren oder löschen?
• Welche Aktionen müssen protokolliert werden?
• Welche Einstellungen enthalten sensible Zugangsdaten?

Bei geschäftskritischen Änderungen kann zusätzlich ein interner Freigabeprozess sinnvoll sein.

Phase 6: Frontend und Benutzerführung planen

Die technische Funktion muss für Kunden verständlich und auf unterschiedlichen Geräten bedienbar sein.

Zu berücksichtigen sind:

• Position der Funktion auf der Seite
• verständliche Beschriftungen
• Pflichtfelder
• Fehlermeldungen
• Bestätigungen
• mobile Bedienung
• Tastaturbedienung
• mehrsprachige Inhalte
• Verhalten bei deaktiviertem JavaScript
• unterschiedliche Templates

Das Frontend sollte sich in die vorhandene Gestaltung einfügen und darf wichtige Kaufprozesse nicht unnötig komplizierter machen.

Fehlermeldungen als Teil der Funktion planen

Eine technische Fehlermeldung hilft dem Kunden meistens nicht weiter.

Gute Meldungen erklären:

• welche Eingabe nicht akzeptiert wurde
• warum sie ungültig ist
• welche Korrektur notwendig ist
• ob bisherige Eingaben erhalten bleiben
• wie bei einem technischen Problem weiter vorgegangen werden kann

Interne technische Details gehören in ein Protokoll und nicht in die sichtbare Meldung für den Kunden.

Mehrsprachigkeit nicht nachträglich improvisieren

Soll das Plugin in mehreren Sprachen eingesetzt werden, müssen Texte strukturiert verwaltet werden.

Dazu gehören:

• Beschriftungen
• Hilfetexte
• Fehlermeldungen
• E-Mails
• Bestätigungstexte
• Backendhinweise

Fest im Quellcode hinterlegte Texte erschweren Übersetzung und spätere Pflege.

Phase 7: Geeignete Hooks und Erweiterungspunkte auswählen

Hooks ermöglichen es einem Plugin, auf vorgesehene Ereignisse und Bereiche des JTL-Shops zu reagieren.

Ein Plugin kann beispielsweise eingreifen:

• beim Aufruf bestimmter Seiten
• bei Veränderungen des Warenkorbs
• während des Bestellprozesses
• bei der Ausgabe von Templatebereichen
• bei administrativen Aktionen
• während geplanter Hintergrundaufgaben

Die Auswahl des richtigen Erweiterungspunkts beeinflusst Stabilität, Performance und Kompatibilität.

Direkte Änderungen am Shopkern vermeiden

Anpassungen an Standarddateien können bei Updates überschrieben werden und erschweren spätere Fehleranalysen.

Bevorzugt werden sollten:

• offizielle Pluginstrukturen
• vorgesehene Hooks
• Templateblöcke
• eigene Pluginvorlagen
• Services und Schnittstellen des Shops

Nur wenn keine vorgesehene Erweiterungsmöglichkeit existiert, muss eine alternative technische Lösung bewertet werden.

Hooks nicht unnötig häufig ausführen

Eine Funktion, die auf jeder Shopseite ausgeführt wird, kann die Performance stärker beeinflussen als eine gezielte Verarbeitung.

Zu prüfen ist:

• Auf welchen Seiten wird die Funktion tatsächlich benötigt?
• Welche Daten müssen bei jedem Aufruf neu geladen werden?
• Welche Ergebnisse können zwischengespeichert werden?
• Kann die Verarbeitung erst nach einer konkreten Benutzeraktion erfolgen?

Phase 8: Schnittstellen und externe Systeme planen

Eine API-Anbindung benötigt mehr als Zugangsdaten und einen erfolgreichen Testaufruf.

Geplant werden müssen:

• Authentifizierung
• verwendete Endpunkte
• Datenformat
• Übertragungsrichtung
• Häufigkeit der Anfragen
• Zeitüberschreitungen
• Wiederholungsversuche
• Fehlerprotokollierung
• Schutz vor doppelten Übertragungen
• Verhalten bei Nichterreichbarkeit

Ein externer Dienst kann ausfallen oder seine technische Schnittstelle verändern. Das Plugin muss darauf kontrolliert reagieren.

Externe API nicht unnötig während des Seitenaufbaus abfragen

Langsame Antworten eines Drittanbieters können sonst den gesamten JTL-Shop verzögern.

Abhängig von der Funktion können bessere Ansätze sein:

• Zwischenspeicherung
• zeitgesteuerte Synchronisation
• asynchrone Verarbeitung
• manuelle Aktualisierung im Backend
• kontrollierter Ersatzwert bei Ausfall

Der richtige Ansatz hängt davon ab, wie aktuell die Daten sein müssen und welche Folgen ein veralteter Wert hätte.

Phase 9: Shopversionen und Kompatibilität festlegen

Vor der Entwicklung muss bekannt sein, welche JTL-Shop-Versionen unterstützt werden sollen.

Relevant sind:

• aktuelle produktive Shopversion
• geplante Updates
• eingesetzte PHP-Version
• verwendetes Template
• weitere aktive Plugins
• notwendige Bibliotheken
• mehrere Shopinstanzen

Eine Erweiterung für einen einzelnen konkreten Shop kann enger geplant werden als ein Plugin, das in verschiedenen Kundensystemen und Versionen eingesetzt werden soll.

Unterstützte Versionen klar begrenzen

Unbegrenzte Rückwärtskompatibilität erhöht Entwicklungs- und Testaufwand erheblich.

Für jede unterstützte Version müssen relevante Funktionen, Hooks, Templates und Datenbankmigrationen geprüft werden. Deshalb sollte festgelegt werden:

• ab welcher Shopversion das Plugin funktioniert
• welche Versionen vollständig getestet werden
• wann ältere Versionen nicht mehr unterstützt werden
• wie neue Shopversionen freigegeben werden

Phase 10: Installation und Standardkonfiguration planen

Ein Plugin muss sich nachvollziehbar installieren und in einen sicheren Ausgangszustand versetzen lassen.

Die Installation kann umfassen:

• Anlegen eigener Tabellen
• Einrichten von Standardwerten
• Registrierung benötigter Komponenten
• Prüfung technischer Voraussetzungen
• Hinweise auf notwendige Konfigurationen

Nach der Installation darf eine noch nicht konfigurierte Funktion keine falschen Preise, fehlerhafte Bestellungen oder unkontrollierte Datenübertragungen erzeugen.

Sichere Standardwerte verwenden

Kritische Funktionen sollten nach der Installation zunächst deaktiviert bleiben, bis alle notwendigen Einstellungen geprüft wurden.

Das betrifft insbesondere:

• externe API-Übertragungen
• Preisberechnungen
• automatische Datenlöschungen
• E-Mail-Versand
• Warenkorb- und Checkoutregeln

Phase 11: Datenbankmigrationen vorbereiten

Mit neuen Pluginversionen können sich Tabellen und gespeicherte Daten verändern.

Migrationen können notwendig sein, wenn:

• neue Felder hinzukommen
• bestehende Daten umgewandelt werden
• Tabellen aufgeteilt oder zusammengeführt werden
• neue Indizes benötigt werden
• alte Konfigurationen ersetzt werden

Jede Migration muss bestehende Daten erhalten oder nachvollziehbar umwandeln. Sie sollte vor dem produktiven Update mit realistischen Daten getestet werden.

Phase 12: Verhalten bei Deaktivierung und Deinstallation festlegen

Deaktivierung und Deinstallation sind unterschiedliche Vorgänge.

Bei der Deaktivierung sollten normalerweise:

• Frontendfunktionen beendet werden
• automatische Prozesse pausieren
• gespeicherte Einstellungen erhalten bleiben
• vorhandene Daten nicht gelöscht werden

Bei der Deinstallation muss geklärt werden:

• ob eigene Tabellen gelöscht werden
• ob Daten vorab exportiert werden können
• welche Dateien und Einstellungen entfernt werden
• welche Auswirkungen auf bestehende Bestellungen bestehen

Bei wichtigen Geschäftsdaten sollte eine Löschung nicht ohne ausdrückliche Bestätigung erfolgen.

Phase 13: Sicherheitsanforderungen definieren

Sicherheit betrifft Eingaben, Datenbank, Dateien, Berechtigungen und externe Verbindungen.

Geprüft werden müssen:

• serverseitige Validierung von Eingaben
• Schutz vor unberechtigten Aktionen
• sichere Datenbankabfragen
• Kontrolle hochgeladener Dateien
• Schutz von API-Schlüsseln
• Absicherung administrativer Funktionen
• Ausgabe von Daten ohne schädlichen Code
• Schutz vor automatisiertem Missbrauch

Sicherheitsanforderungen sind besonders wichtig, wenn das Plugin Formulare, Uploads, Zahlungsdaten oder externe Schnittstellen verarbeitet.

Phase 14: Performanceanforderungen berücksichtigen

Eine neue Funktion darf den gesamten Shop nicht bei jedem Seitenaufruf unnötig belasten.

Zu prüfen sind:

• Anzahl zusätzlicher Datenbankabfragen
• Ausführung auf betroffenen Seitentypen
• Cachefähigkeit
• Umfang zusätzlicher JavaScript- und CSS-Dateien
• externe API-Aufrufe
• Verarbeitung großer Datenmengen
• Hintergrundaufgaben

Besonders Funktionen auf Kategorie-, Produkt- und Checkoutseiten sollten mit realistischen Datenmengen getestet werden.

Große Datenmengen realistisch testen

Ein Plugin kann mit zehn Produkten schnell funktionieren und bei zehntausenden Datensätzen an Grenzen geraten.

Testdaten sollten deshalb berücksichtigen:

• große Kategorien
• viele Varianten
• umfangreiche Kundendaten
• lange Protokollhistorien
• mehrere gleichzeitige Benutzer
• langsame externe Schnittstellen

Performanceprobleme sollten vor dem produktiven Einsatz erkannt werden und nicht erst nach wachsender Nutzung.

Phase 15: Protokollierung und Fehlerbehandlung planen

Fehler müssen später nachvollziehbar sein, ohne dass Kunden technische Details sehen.

Ein Pluginprotokoll kann enthalten:

• Zeitpunkt
• betroffene Funktion
• verarbeiteter Datensatz
• Ergebnis
• Warnung oder Fehler
• technische Zusatzinformationen
• Pluginversion

Personenbezogene oder sensible Informationen sollten nicht unnötig in Protokollen gespeichert werden.

Fehlerarten sinnvoll unterscheiden

Nicht jeder abweichende Wert muss als kritischer Fehler behandelt werden.

Eine sinnvolle Einteilung ist:

• Information: Vorgang wurde erfolgreich ausgeführt.
• Warnung: Verarbeitung war möglich, aber ein Wert sollte geprüft werden.
• Fehler: Ein einzelner Vorgang konnte nicht abgeschlossen werden.
• Kritisch: Die gesamte Funktion oder ein zentraler Geschäftsprozess ist betroffen.

Benachrichtigungen sollten sich an dieser Einteilung orientieren, damit wichtige Fehler nicht zwischen unwesentlichen Meldungen verloren gehen.

Phase 16: Testfälle vor der Entwicklung definieren

Tests sollten nicht erst nach Abschluss der Programmierung improvisiert werden.

Bereits bei der Planung können Testfälle beschrieben werden:

• Standardfall mit gültigen Daten
• leere Pflichtfelder
• ungültige Werte
• Grenzwerte
• nicht berechtigter Benutzer
• externe Schnittstelle nicht erreichbar
• Warenkorb wird nachträglich geändert
• mehrsprachige Ausgabe
• mobile Nutzung
• Update von einer älteren Pluginversion

Jeder Testfall benötigt ein erwartetes Ergebnis. Nur so lässt sich objektiv prüfen, ob die Funktion korrekt arbeitet.

Technische Tests und fachliche Abnahme unterscheiden

Entwickler und Auftraggeber prüfen unterschiedliche Aspekte.

Eine technisch fehlerfreie Funktion kann fachlich trotzdem ungeeignet sein, wenn Regeln oder Benutzerführung nicht zum realen Prozess passen.

Testumgebung und produktiven Shop trennen

Neue Plugins sollten nicht zuerst im laufenden Verkauf getestet werden.

Eine geeignete Testumgebung ermöglicht:

• Installation und Updates ohne Kundenbetrieb
• Tests mit verschiedenen Konfigurationen
• vollständige Testbestellungen
• Kontrolle von Fehlerprotokollen
• Prüfung mit anderen Plugins
• Performancevergleiche

Die Testumgebung sollte Shopversion, Template, Plugins und Datenstruktur des Produktivsystems ausreichend realistisch abbilden.

Phase 17: Abhängigkeiten zu anderen Plugins prüfen

Mehrere Erweiterungen können dieselben Shopbereiche und Ereignisse beeinflussen.

Mögliche Konflikte entstehen bei:

• Warenkorbregeln
• Checkout
• Produktpreisen
• Templateausgaben
• JavaScript-Bibliotheken
• externen Schnittstellen
• Cacheverhalten

Vor der Entwicklung sollte eine Liste relevanter aktiver Plugins vorliegen. Nach Installation und Updates müssen die gemeinsamen Bereiche gezielt getestet werden.

Phase 18: Dokumentation von Beginn an einplanen

Dokumentation ist nicht nur für Entwickler relevant.

Benötigt werden können:

• Installationsanleitung
• Konfigurationsanleitung
• Beschreibung der Funktionen
• Benutzerrollen und Rechte
• Fehlerbehandlung
• Datenquellen
• Schnittstellen
• Updatehinweise
• Deinstallationsverhalten
• technische Entwicklerdokumentation

Eine verständliche Anwenderdokumentation reduziert Rückfragen. Technische Dokumentation erleichtert Wartung und spätere Weiterentwicklung.

Änderungen versioniert dokumentieren

Für jede veröffentlichte Version sollte nachvollziehbar sein, was verändert wurde.

Ein Änderungsprotokoll kann enthalten:

• neue Funktionen
• behobene Fehler
• geänderte Einstellungen
• Datenbankmigrationen
• veränderte Voraussetzungen
• bekannte Einschränkungen

Phase 19: Wartung und Support vereinbaren

Nach dem ersten produktiven Einsatz endet der Lebenszyklus eines Plugins nicht.

Wartungsbedarf entsteht durch:

• neue JTL-Shop-Versionen
• neue PHP-Versionen
• Templateänderungen
• Änderungen externer APIs
• neue Browser
• geänderte Geschäftsregeln
• zusätzliche Sprachen oder Shops
• Fehler aus dem produktiven Betrieb

Bereits im Projekt sollte geklärt werden, wer zukünftige Updates prüft, wie Fehler gemeldet werden und welcher Aufwand für Erweiterungen entsteht.

Garantie, Fehlerbehebung und neue Anforderungen trennen

Nicht jede spätere Änderung ist automatisch ein Fehler der ursprünglichen Entwicklung.

Unterschieden werden sollten:

• Abweichung von der vereinbarten Funktion
• Fehler unter den ursprünglich unterstützten Bedingungen
• Inkompatibilität durch eine neue Shopversion
• Änderung einer externen Schnittstelle
• neue fachliche Anforderungen
• Erweiterung auf weitere Shops oder Prozesse

Eine klare Anforderungs- und Versionsdokumentation erleichtert diese Abgrenzung.

Phase 20: Veröffentlichung und Go-live vorbereiten

Der produktive Einsatz sollte als eigener Projektschritt geplant werden.

Vor der Aktivierung sollten vorhanden sein:

• aktuelles Backup
• freigegebene Pluginversion
• Dokumentation
• vollständige Konfiguration
• Liste notwendiger Testfälle
• verantwortlicher Ansprechpartner
• Rückfallmöglichkeit
• Zeitraum für engere Überwachung

Der allgemeine Projektablauf zeigt, wie Analyse, Konzept, Umsetzung, Test und Go-live strukturiert miteinander verbunden werden.

Ein sinnvoller Projektablauf für individuelle JTL-Shop-Plugins

Ein strukturierter Ablauf reduziert Missverständnisse und spätere Mehrkosten.

Warum Prototypen bei komplexen Funktionen sinnvoll sind

Bei umfangreichen Benutzeroberflächen oder unklaren Abläufen kann ein früher Prototyp Missverständnisse verhindern.

Ein Prototyp kann zeigen:

• Position und Aufbau der Funktion
• Reihenfolge der Eingaben
• Benutzerführung
• Darstellung auf mobilen Geräten
• notwendige Rückmeldungen und Fehlermeldungen

Der Prototyp muss noch nicht die vollständige Geschäftslogik enthalten. Er hilft dabei, die Bedienung vor der aufwendigen technischen Umsetzung abzustimmen.

Warum Pluginprojekte schrittweise umgesetzt werden sollten

Umfangreiche Entwicklungen lassen sich besser kontrollieren, wenn sie in funktionsfähige Teilbereiche gegliedert werden.

Eine mögliche Reihenfolge ist:

1. Datenmodell und Grundstruktur
2. Backend und Einstellungen
3. zentrale Geschäftslogik
4. Frontendausgabe
5. Schnittstellen
6. Protokollierung und Fehlerbehandlung
7. Migration und Updatefunktionen

Nach jedem Abschnitt kann geprüft werden, ob die Umsetzung weiterhin zum vereinbarten Prozess passt.

Wie der Entwicklungsaufwand eines Plugins entsteht

Der Aufwand richtet sich nicht nur nach der Anzahl sichtbarer Seiten oder Schaltflächen.

Wesentliche Kostentreiber sind:

• Anzahl und Komplexität der Geschäftsregeln
• eigene Datenhaltung
• Backendfunktionen
• Frontend und mobile Darstellung
• externe Schnittstellen
• Anzahl unterstützter Shopversionen
• Mehrsprachigkeit
• Benutzerrechte
• Datenmigrationen
• Testumfang
• Dokumentation
• Performance- und Sicherheitsanforderungen

Eine äußerlich kleine Funktion kann technisch umfangreich sein, wenn sie mehrere Systeme, Datenquellen oder Bestellprozesse verbindet.

Warum ein seriöser Aufwand nicht nur aus einem Satz abgeleitet werden kann

Aussagen wie „Wir benötigen nur ein kleines Zusatzfeld“ lassen wichtige technische Fragen offen.

Für eine belastbare Einschätzung muss geklärt werden:

• Wo wird das Feld angezeigt?
• Wer darf es sehen und bearbeiten?
• Woher stammt sein Wert?
• Wird der Wert gespeichert?
• Muss er in den Warenkorb und Auftrag übernommen werden?
• Benötigt er eine Validierung?
• Wie verhält er sich bei Varianten?
• Wird er mehrsprachig benötigt?

Festpreis oder Abrechnung nach Aufwand?

Die geeignete Abrechnung hängt davon ab, wie vollständig die Anforderungen bereits definiert sind.

Ein Festpreis ist eher möglich, wenn:

• der Funktionsumfang klar abgegrenzt ist
• alle Datenquellen bekannt sind
• Ausnahmen beschrieben wurden
• Schnittstellen dokumentiert sind
• Abnahmekriterien feststehen

Eine aufwandsbezogene oder phasenweise Umsetzung ist sinnvoller, wenn technische Machbarkeit, Datenqualität oder externe Systeme zunächst untersucht werden müssen.

Änderungswünsche während der Entwicklung behandeln

Neue Erkenntnisse während eines Projekts sind normal, müssen aber kontrolliert bewertet werden.

Für jede Änderung sollte geprüft werden:

• Welche ursprüngliche Anforderung verändert sich?
• Welche bereits entwickelten Bereiche sind betroffen?
• Ändert sich das Datenmodell?
• Welche neuen Tests werden notwendig?
• Verändert sich Zeit- oder Kostenrahmen?
• Kann die Änderung in eine spätere Version verschoben werden?

Eine klare Priorisierung verhindert, dass ein ursprünglich überschaubares Plugin während der Entwicklung unkontrolliert wächst.

Eine erste Version bewusst begrenzen

Nicht jede denkbare Erweiterung muss bereits in Version 1.0 enthalten sein.

Die erste Version sollte:

• den zentralen Geschäftsprozess vollständig abbilden
• kritische Fehlerfälle behandeln
• sicher installierbar und aktualisierbar sein
• ausreichend dokumentiert werden
• eine Grundlage für spätere Erweiterungen besitzen

Komfortfunktionen und zusätzliche Auswertungen können anschließend anhand der tatsächlichen Nutzung priorisiert werden.

Typische Fehler bei der Planung eines JTL-Shop-Plugins

Viele Probleme lassen sich bereits vor der ersten Codezeile vermeiden.

Welche Unterlagen für eine erste Einschätzung hilfreich sind

Je konkreter der aktuelle Prozess beschrieben ist, desto belastbarer kann die technische Planung erfolgen.

Hilfreich sind:

• Beschreibung des aktuellen Problems
• gewünschter Zielablauf
• Screenshots oder Skizzen
• Beispieldaten
• betroffene Produktarten
• verwendete Shopversion
• eingesetztes Template
• Liste relevanter Plugins
• Dokumentation externer Schnittstellen
• bekannte Sonderfälle

Auch ein Bildschirmvideo des aktuellen manuellen Ablaufs kann helfen, versteckte Zwischenschritte und Entscheidungen zu erkennen.

Welche Fragen vor Projektstart beantwortet sein sollten

Eine kurze Checkliste hilft dabei, die technische und fachliche Reife der Anforderung zu bewerten.

1. Welches konkrete Problem löst das Plugin?
2. Wer nutzt die Funktion?
3. Welche Daten werden benötigt?
4. Woher stammen diese Daten?
5. Welche Regeln und Ausnahmen gelten?
6. Welche Informationen werden gespeichert?
7. Welche Backend-Einstellungen werden benötigt?
8. Welche Shopversionen sollen unterstützt werden?
9. Wie wird die Funktion getestet und abgenommen?
10. Wer übernimmt spätere Wartung und Updates?

Wann eine Machbarkeitsanalyse sinnvoll ist

Bei komplexen Schnittstellen oder tiefen Eingriffen sollte vor dem eigentlichen Projekt eine technische Prüfung erfolgen.

Eine Machbarkeitsanalyse kann klären:

• ob die benötigten Daten verfügbar sind
• ob geeignete Hooks existieren
• wie Informationen an JTL-Wawi übergeben werden können
• ob eine externe API die benötigten Funktionen bereitstellt
• welche technischen Risiken bestehen
• ob eine alternative Umsetzung wirtschaftlicher ist

Das Ergebnis ist ein technisches Konzept oder eine belastbarere Aufwandseinschätzung.

Wann ein Prototyp statt einer vollständigen Entwicklung sinnvoll ist

Ein Prototyp eignet sich, wenn Funktion, Datenquelle oder Benutzerführung zunächst praktisch geprüft werden müssen.

Er kann beantworten:

• Ist die gewünschte Datenverarbeitung technisch möglich?
• Reagiert die externe Schnittstelle wie erwartet?
• Verstehen Benutzer den geplanten Ablauf?
• Welche Performance ist mit realistischen Daten erreichbar?
• Welche Anforderungen fehlen noch?

Der Prototyp ist nicht automatisch eine produktionsreife Version. Sicherheits-, Update- und Wartungsanforderungen müssen anschließend vollständig umgesetzt werden.

Wie Faymax Consulting individuelle JTL-Shop-Plugins entwickelt

Faymax Consulting verbindet fachliche Prozessanalyse mit technischer Pluginentwicklung.

Die Zusammenarbeit kann umfassen:

• Analyse der bestehenden Arbeitsweise
• Prüfung vorhandener Standardlösungen
• Definition von Anforderungen und Ausnahmen
• Planung von Datenmodell und Backend
• Umsetzung von Frontend und Geschäftslogik
• Anbindung externer Schnittstellen
• Tests in einer geeigneten Umgebung
• Datenbankmigrationen und Updatefunktionen
• Dokumentation
• Go-live und spätere Wartung

Das Projekt erhält einen festen Ansprechpartner. Abstimmungen können während der Umsetzung per Microsoft Teams, WhatsApp oder Telefon erfolgen. Auftretende Änderungen und technische Risiken werden frühzeitig eingeordnet und priorisiert.

Weitere Informationen zur Zusammenarbeit finden Sie unter So arbeiten wir mit Ihnen.

Warum die Projektstruktur auch bei kleinen Plugins wichtig ist

Eine kleine Funktion benötigt weniger Entwicklungsaufwand, aber weiterhin klare Regeln und Tests.

Bereits ein kleines Plugin kann:

• Produktdaten verändern
• den Warenkorb beeinflussen
• personenbezogene Informationen verarbeiten
• bei Shopupdates inkompatibel werden
• mit anderen Erweiterungen kollidieren

Die Planung kann entsprechend kompakter ausfallen. Vollständig entfallen sollte sie jedoch nicht.

Häufige Fragen zur Entwicklung individueller JTL-Shop-Plugins