Nicht jede Shopanpassung benötigt ein Plugin und nicht jede Funktion gehört ins Template
Bei einer gewünschten Änderung im JTL-Shop stellt sich häufig zunächst die Frage nach der sichtbaren Umsetzung. Soll ein Bereich anders aussehen, eine zusätzliche Information erscheinen oder ein neuer Ablauf entstehen? Technisch entscheidender ist jedoch eine andere Frage: Verändert die Anforderung lediglich die Darstellung oder verarbeitet sie Daten und Geschäftslogik?
Eine falsche Einordnung kann spätere Updates erschweren, Fehler verursachen oder dazu führen, dass eine zunächst kleine Anpassung nur mit hohem Aufwand erweitert werden kann. Deshalb sollte vor der Umsetzung klar feststehen, ob eine Templateanpassung, ein Plugin oder eine Kombination aus beiden benötigt wird.
Der grundlegende Unterschied zwischen Template und Plugin
Template und Plugin greifen an unterschiedlichen Stellen des JTL-Shops ein.
Template
Das Template bestimmt hauptsächlich Aufbau, Darstellung und Bedienung des sichtbaren Shops.
Plugin
Ein Plugin erweitert den Shop um Funktionen, Einstellungen, Datenverarbeitung oder zusätzliche Geschäftslogik.
Kombination
Das Plugin stellt Daten und Funktion bereit. Das Template oder eine Pluginvorlage übernimmt die sichtbare Ausgabe.
Vereinfacht gesagt: Verändert sich nur, wie vorhandene Informationen angezeigt werden, reicht häufig eine Templateanpassung. Muss der Shop neue Informationen erzeugen, speichern oder verarbeiten, ist meistens ein Plugin notwendig.
Die sichtbare Änderung verrät nicht immer den technischen Aufwand
Ein zusätzlicher Hinweis auf der Produktseite kann eine einfache Templateausgabe sein. Derselbe Hinweis kann jedoch auch von Lagerbestand, Kundengruppe, Warenkorb oder eigenen Einstellungen abhängen und dadurch eine vollständige Pluginlogik benötigen.
Was ein JTL-Shop-Template steuert
Das Template bildet die sichtbare Oberfläche des Onlineshops.
Dazu gehören unter anderem:
- Header und Hauptnavigation
- Footer
- Startseite
- Kategorieseiten
- Produktseiten
- Warenkorb
- Checkoutdarstellung
- Schriftarten, Farben und Abstände
- Buttons und Formulare
- mobile Darstellung
- Position vorhandener Inhalte
Änderungen an diesen Bereichen können über CSS, JavaScript und Template-Dateien erfolgen. Voraussetzung ist, dass die benötigten Informationen bereits im Shop vorhanden sind.
Typische Aufgaben für eine Templateanpassung
Eine Templateanpassung ist geeignet, wenn vorhandene Inhalte anders gestaltet oder positioniert werden sollen.
Typische Beispiele sind:
- Farben und Schriftgrößen ändern
- Abstände und Breiten anpassen
- Produktinformationen neu anordnen
- vorhandene Merkmale an einer anderen Stelle anzeigen
- Buttons anders gestalten
- Elemente auf bestimmten Seiten ausblenden
- mobile Darstellung verbessern
- Footer oder Navigation neu strukturieren
- vorhandene Templateblöcke erweitern
- Ausgabe abhängig von bereits verfügbaren Werten verändern
Wird beispielsweise ein vorhandenes Artikelmerkmal zusätzlich unterhalb des Produktpreises ausgegeben, kann dies häufig ohne Plugin über das Template umgesetzt werden.
CSS verändert die Darstellung, aber keine Geschäftslogik
Über CSS lassen sich Farben, Größen, Positionen und Sichtbarkeit beeinflussen. CSS kann jedoch keine Daten aus der Datenbank laden, Einstellungen speichern oder einen neuen Shopprozess ausführen.
Wann CSS allein ausreicht
Für rein visuelle Anpassungen ist CSS häufig die einfachste und wartungsärmste Lösung.
Dazu gehören:
- andere Farben
- größere oder kleinere Schriften
- veränderte Abstände
- breitere Inhaltsbereiche
- andere Buttonformen
- Ausblenden dekorativer Elemente
- Anpassung bestimmter Bildschirmgrößen
CSS ist nicht ausreichend, wenn Inhalte anders sortiert, zusätzliche Daten geladen oder Benutzeraktionen verarbeitet werden müssen.
Wann JavaScript im Template sinnvoll ist
JavaScript kann die Bedienung und Darstellung im Browser erweitern.
Mögliche Aufgaben sind:
- Akkordeons öffnen und schließen
- Tabs umschalten
- bestimmte Elemente abhängig von einer Auswahl anzeigen
- Slider steuern
- kleine Berechnungen im Browser durchführen
- Formulareingaben vorab prüfen
Geschäftskritische Regeln dürfen jedoch nicht ausschließlich im Browser umgesetzt werden. JavaScript kann durch Benutzer verändert oder blockiert werden. Preise, Berechtigungen und verbindliche Warenkorbregeln benötigen deshalb eine serverseitige Kontrolle.
Frontendlogik ist keine sichere Geschäftslogik
Eine im Browser ausgeblendete Option ist nicht automatisch technisch gesperrt. Regeln mit Einfluss auf Preis, Bestellung oder Berechtigung müssen serverseitig geprüft werden.
Was ein JTL-Shop-Plugin leisten kann
Ein Plugin kann tiefer in die Abläufe des JTL-Shops eingreifen und eigene Funktionen bereitstellen.
Dazu gehören beispielsweise:
- eigene Einstellungen im Backend
- zusätzliche Datenbanktabellen
- Verarbeitung von Formularen
- Berechnungen anhand von Produkt- oder Kundendaten
- Änderungen an Warenkorbprozessen
- Kommunikation mit externen Schnittstellen
- automatische Aufgaben
- eigene Frontendbereiche
- zusätzliche Administrationsseiten
- strukturierte Installation und Deinstallation
Ein Plugin eignet sich damit für Anforderungen, die über eine reine visuelle Veränderung hinausgehen.
Typische Aufgaben für ein JTL-Shop-Plugin
Sobald neue Daten oder Abläufe entstehen, ist ein Plugin häufig die richtige technische Form.
Beispiele sind:
- individuelle Preisberechnungen
- kundengruppenabhängige Funktionen
- eigene Formulare mit Speicherung
- Produktkonfiguratoren
- zusätzliche Warenkorbregeln
- API-Anbindungen
- automatische Datenimporte
- eigene Auswertungen im Shopbackend
- Download- oder Lizenzverwaltung
- individuelle Produktinformationen aus eigenen Datenquellen
Der Beitrag Individuelle JTL-Shop-Plugins erläutert typische Einsatzbereiche und Planungsgrundlagen.
Eine neue Einstellung benötigt normalerweise eine technische Verwaltung
Soll ein Shopbetreiber Werte im Backend pflegen, aktivieren oder für verschiedene Bereiche konfigurieren können, reicht eine fest eingebaute Templateänderung häufig nicht aus.
Beispiel: Zusätzlicher Hinweis auf der Produktseite
Dieselbe sichtbare Anforderung kann technisch sehr unterschiedlich sein.
Fester Text
Ein auf allen Produktseiten identischer Hinweis kann häufig direkt im Template oder über einen vorhandenen Inhaltsbereich eingebunden werden.
Vorhandenes Attribut
Ein bereits in JTL-Wawi gepflegter Wert kann über eine Templateanpassung ausgegeben werden.
Eigene Regeln
Hängt der Hinweis von Bestand, Warenwert, Kundengruppe oder mehreren Produkteigenschaften ab, kann Pluginlogik erforderlich sein.
Backendpflege
Soll der Hinweis über eigene Einstellungen verwaltet werden, ist ein Plugin meist wartungsfreundlicher.
Beispiel: Versandhinweis im JTL-Shop
Auch Versandhinweise können von einer einfachen Darstellung bis zu einer komplexen Berechnung reichen.
Eine Templateanpassung kann ausreichen, wenn:
- ein vorhandener Lieferstatus anders dargestellt wird
- ein fester Link zu den Versandinformationen ergänzt wird
- eine vorhandene Versandkosteninformation neu positioniert wird
Ein Plugin wird wahrscheinlicher benötigt, wenn:
- Versandkosten dynamisch vorab berechnet werden
- mehrere Lager oder Lieferquellen berücksichtigt werden
- produktabhängige Hinweise erzeugt werden
- externe Versanddaten abgefragt werden
- eigene Einstellungen im Backend notwendig sind
Beispiel: Kundengruppenabhängige Darstellung
Vorhandene Kundengruppendaten können teilweise direkt im Template ausgewertet werden.
Soll lediglich ein vorhandener Inhalt für eine bekannte Kundengruppe ein- oder ausgeblendet werden, kann eine Templatebedingung ausreichen.
Ein Plugin ist dagegen sinnvoll, wenn:
- eigene Berechtigungen verwaltet werden
- neue Kundengruppenlogik entsteht
- Preise oder Bestellbedingungen verändert werden
- Freigabeprozesse benötigt werden
- zusätzliche Daten gespeichert werden
Anzeige und Berechtigung sind nicht dasselbe
Das Ausblenden eines Elements verhindert nicht automatisch den technischen Zugriff auf eine Funktion. Berechtigungen müssen dort geprüft werden, wo die Funktion serverseitig verarbeitet wird.
Beispiel: Produktkonfigurator
Produktkonfiguratoren verbinden Darstellung, Eingaben, Berechnungen und Warenkorbverarbeitung.
Eine einfache Auswahl bereits vorhandener Varianten kann über die normalen Shopfunktionen und eine angepasste Darstellung erfolgen.
Ein individuelles Plugin wird benötigt, wenn:
- abhängige Auswahlmöglichkeiten bestehen
- Preise dynamisch berechnet werden
- Maße oder Mengen eingegeben werden
- ungültige Kombinationen verhindert werden müssen
- Konfigurationen im Warenkorb gespeichert werden
- die Auswahl später in JTL-Wawi nachvollziehbar sein muss
Beispiel: Individuelles Kontaktformular
Ein einfaches vorhandenes Formular lässt sich häufig optisch über das Template anpassen.
Ein Plugin kann erforderlich sein, wenn das Formular:
- produktabhängige Felder benötigt
- Dateien entgegennimmt
- Daten in eigenen Tabellen speichert
- unterschiedliche Empfänger verwendet
- eine eigene Bestätigung oder Weiterverarbeitung auslöst
- mit einem externen CRM verbunden werden soll
Datenschutz, Spam-Schutz und sichere Validierung müssen bei individuellen Formularen von Beginn an berücksichtigt werden.
Formulardaten dürfen nicht nur im Browser geprüft werden
Eingaben müssen serverseitig validiert, kontrolliert verarbeitet und gegen missbräuchliche Anfragen geschützt werden.
Wann ein Child-Template verwendet werden sollte
Individuelle Änderungen sollten nicht direkt im unveränderten Standardtemplate vorgenommen werden.
Ein Child-Template ermöglicht:
- Trennung eigener Änderungen vom Basistemplate
- bessere Nachvollziehbarkeit
- gezieltes Überschreiben einzelner Dateien
- leichtere Prüfung nach Templateupdates
- geringeres Risiko, dass Anpassungen direkt überschrieben werden
Ein Child-Template macht Änderungen jedoch nicht automatisch vollständig updatefähig. Wenn sich die zugrunde liegende Datei im Basistemplate verändert, muss das eigene Override geprüft und gegebenenfalls angepasst werden.
Warum direkte Änderungen am Standardtemplate problematisch sind
Direkte Anpassungen können bei einem Update überschrieben werden oder verhindern, dass Aktualisierungen sauber eingespielt werden.
Typische Folgen sind:
- Änderungen gehen nach einem Update verloren.
- Standarddateien lassen sich nicht mehr mit dem Original vergleichen.
- Fehlerursachen sind schwerer zu erkennen.
- neue Templatefunktionen werden nicht übernommen
- Sicherheitskorrekturen bleiben teilweise aus
Eigene Änderungen sollten deshalb dokumentiert und in einer dafür vorgesehenen Struktur umgesetzt werden.
Ein Child-Template schützt vor Überschreiben, nicht vor Inkompatibilität
Nach einem größeren Update muss weiterhin geprüft werden, ob eigene Templatestrukturen, Blöcke und Variablen noch zur neuen Version passen.
Templateoverride oder Pluginhook?
Häufig kann eine Ausgabe entweder durch das Überschreiben einer Template-Datei oder über eine vorgesehene Erweiterungsstelle ergänzt werden.
Ein Pluginhook oder vorhandener Block ist meist vorzuziehen, wenn:
- nur ein zusätzlicher Bereich eingefügt werden soll
- die Standarddatei ansonsten unverändert bleiben kann
- mehrere Templates unterstützt werden sollen
- die Funktion unabhängig vom individuellen Shopdesign bleiben soll
Ein vollständiges Templateoverride kann notwendig sein, wenn der bestehende Aufbau grundlegend verändert werden muss. Es erhöht jedoch den späteren Prüfaufwand bei Updates.
Warum ein Plugin trotzdem Template-Dateien enthalten kann
Ein Plugin und eine Templateausgabe schließen sich nicht gegenseitig aus.
Ein sauber aufgebautes Plugin kann:
- Daten verarbeiten
- Einstellungen speichern
- Geschäftslogik ausführen
- eine eigene Ausgabevorlage bereitstellen
- Inhalte über Hooks oder Blöcke in das Shoptemplate einfügen
Die sichtbare Darstellung bleibt anpassbar, während die eigentliche Funktion im Plugin gekapselt wird.
Wann Plugin und Templateanpassung kombiniert werden sollten
Viele individuelle Funktionen benötigen beide Bereiche.
Eine Kombination ist sinnvoll, wenn:
- das Plugin neue Daten liefert
- die Ausgabe genau an das vorhandene Design angepasst werden muss
- unterschiedliche Seitentypen eigene Darstellungen benötigen
- mobile und stationäre Ausgabe unterschiedlich optimiert werden
- der Shop ein stark individualisiertes Child-Template verwendet
Die Verantwortlichkeiten sollten trotzdem getrennt bleiben: Daten und Regeln im Plugin, Darstellung im dafür vorgesehenen Templatebereich.
Geschäftslogik gehört nicht dauerhaft in eine Template-Datei
Werden umfangreiche Berechnungen und Datenbankzugriffe direkt in der Darstellung umgesetzt, wird die Lösung schwer testbar, schlecht wartbar und abhängig von einzelnen Template-Dateien.
Updatesicherheit richtig verstehen
Weder ein Plugin noch ein Child-Template bleiben ohne Prüfung automatisch mit jeder zukünftigen Version kompatibel.
Updatesicherheit bedeutet:
- Standarddateien werden möglichst nicht direkt verändert.
- vorgesehene Erweiterungspunkte werden genutzt.
- eigene Funktionen sind klar getrennt.
- Änderungen sind dokumentiert.
- Abhängigkeiten zu Shop- und Templateversionen sind bekannt.
- nach Updates werden gezielte Funktionstests durchgeführt.
Der Beitrag JTL-Shop-Plugins sinnvoll einsetzen zeigt, wie Erweiterungen über ihren gesamten Lebenszyklus bewertet werden sollten.
Welche Lösung verursacht mehr Wartungsaufwand?
Der Wartungsaufwand hängt nicht nur davon ab, ob die Lösung als Plugin oder Templateanpassung umgesetzt wurde.
Entscheidend sind:
- Umfang der Änderungen
- Abhängigkeit von internen Shopstrukturen
- Anzahl überschriebener Template-Dateien
- verwendete Hooks und Schnittstellen
- zusätzliche Datenbanktabellen
- externe APIs
- Dokumentationsqualität
- Testumfang nach Updates
Eine kleine, klar getrennte Pluginfunktion kann wartungsärmer sein als eine umfangreiche Templateanpassung mit zahlreichen überschriebenen Dateien.
Die technisch kürzeste Lösung ist nicht immer langfristig die günstigste
Eine schnelle Änderung direkt in einer Template-Datei kann zunächst wenig Aufwand verursachen. Muss sie nach jedem Update neu untersucht werden, steigen die langfristigen Kosten.
Performance von Plugin und Template vergleichen
Beide Lösungsarten können einen JTL-Shop verlangsamen, wenn sie ungeeignet umgesetzt werden.
Bei Templateanpassungen können problematisch sein:
- umfangreiche JavaScript-Dateien
- unnötig große CSS-Dateien
- komplexe Schleifen in der Ausgabe
- zu viele DOM-Elemente
- große Bilder und Animationen
Bei Plugins können problematisch sein:
- zusätzliche Datenbankabfragen auf jeder Seite
- ungecachete Berechnungen
- externe API-Aufrufe während des Seitenaufbaus
- unnötige Ausführung auf nicht betroffenen Seiten
- große zusätzliche Frontendressourcen
Der Beitrag JTL-Shop langsam: Ursachen systematisch finden erläutert die wichtigsten technischen Performancebereiche.
Sicherheit bei individuellen Erweiterungen
Je tiefer eine Funktion in Daten und Geschäftsprozesse eingreift, desto wichtiger wird eine sichere serverseitige Umsetzung.
Zu berücksichtigen sind:
- Validierung von Benutzereingaben
- Schutz vor unberechtigten Zugriffen
- sichere Datenbankabfragen
- Kontrolle von Uploads
- Schutz sensibler Einstellungen
- Protokollierung kritischer Aktionen
- datenschutzkonforme Verarbeitung
Reine Templateänderungen sollten keinen direkten, unkontrollierten Zugriff auf Datenbanken oder externe Dienste erhalten.
Datenspeicherung gehört in eine strukturierte Lösung
Sobald eigene Informationen dauerhaft gespeichert werden müssen, ist eine Pluginstruktur normalerweise sinnvoll.
Dazu gehören beispielsweise:
- Formulareingaben
- Konfigurationen
- Benutzereinstellungen
- Protokolle
- externe Zuordnungen
- individuelle Produktinformationen
Ein Plugin kann Installation, Datenbankstruktur, Updates und Deinstallation nachvollziehbar verwalten.
Daten dürfen nicht unkontrolliert an das Template gebunden sein
Wird das Design gewechselt, müssen gespeicherte Daten und Geschäftslogik weiterhin verfügbar bleiben. Diese Trennung ist ein zentraler Vorteil einer Pluginlösung.
Templatewechsel als Entscheidungskriterium
Unternehmen sollten berücksichtigen, ob das eingesetzte Template langfristig bestehen bleibt.
Eine stark an ein einzelnes Template gebundene Funktion muss bei einem späteren Designwechsel möglicherweise vollständig neu umgesetzt werden.
Ein Plugin kann die Kernfunktion unabhängig bereitstellen. Für das neue Template muss dann nur die sichtbare Ausgabe angepasst werden.
Mehrere JTL-Shops und wiederverwendbare Funktionen
Soll dieselbe Funktion in mehreren Shops eingesetzt werden, ist ein Plugin häufig die bessere Grundlage.
Vorteile sind:
- zentrale Funktionslogik
- strukturierte Installation
- eigene Konfiguration je Shop
- leichtere Verteilung von Updates
- geringere Abhängigkeit von einem bestimmten Template
Die Darstellung kann trotzdem an das jeweilige Shopdesign angepasst werden.
Wann eine vorhandene Standardfunktion ausreicht
Vor jeder individuellen Anpassung sollte geprüft werden, ob JTL-Shop, Template oder ein bestehendes Plugin die Anforderung bereits erfüllt.
Mögliche vorhandene Lösungen sind:
- OnPage Composer
- Templateeinstellungen
- eigene Inhalte und Linkgruppen
- Artikelattribute
- Funktionsattribute
- Merkmale
- Sprachvariablen
- vorhandene Plugins
Kostenlose Erweiterungen finden Sie unter Kostenlose JTL-Shop-Plugins.
Vorhandene Funktionen sollten nicht unnötig neu entwickelt werden
Eine Standardlösung ist häufig günstiger, besser getestet und leichter updatefähig. Eine individuelle Entwicklung lohnt sich dort, wo vorhandene Möglichkeiten den tatsächlichen Prozess nicht ausreichend abbilden.
Plugin oder Template nach wirtschaftlichen Kriterien auswählen
Die Entscheidung sollte nicht nur nach den unmittelbaren Entwicklungskosten getroffen werden.
Berücksichtigt werden sollten:
- Aufwand der ersten Umsetzung
- Wartung nach Updates
- Abhängigkeit vom Template
- spätere Erweiterbarkeit
- Testaufwand
- möglicher Templatewechsel
- Anzahl der Shops
- geschäftliche Bedeutung der Funktion
Für einen kleinen einmaligen Darstellungswunsch ist ein Plugin meist unverhältnismäßig. Für einen zentralen Prozess mit eigenen Daten und regelmäßiger Weiterentwicklung kann eine schnelle Templateänderung langfristig ungeeignet sein.
Eine einfache Entscheidungshilfe
Die folgenden Fragen helfen bei der ersten technischen Einordnung.
Nur Darstellung?
Werden ausschließlich Farben, Positionen oder vorhandene Inhalte verändert, spricht vieles für eine Templateanpassung.
Neue Daten?
Müssen zusätzliche Informationen erzeugt oder gespeichert werden, wird meistens ein Plugin benötigt.
Eigene Einstellungen?
Soll der Shopbetreiber die Funktion im Backend konfigurieren, ist eine Pluginstruktur meist sinnvoll.
Geschäftsregeln?
Preis-, Warenkorb-, Kunden- oder Berechtigungslogik gehört in eine serverseitige Erweiterung.
Nur ein Template?
Eine rein visuelle Sonderlösung für ein konkretes Design kann direkt im Child-Template umgesetzt werden.
Mehrere Shops?
Wiederverwendbare Funktionen sollten möglichst unabhängig vom einzelnen Template als Plugin aufgebaut werden.
Typische Fehlentscheidungen bei JTL-Shop-Anpassungen
Viele technische Probleme entstehen, weil der schnellste und nicht der passende Lösungsweg gewählt wird.
Geschäftslogik im Template
Berechnungen und Datenzugriffe werden direkt in Ausgabe-Dateien eingebaut und sind später schwer wartbar.
Plugin für reine Farbe
Eine einfache CSS-Änderung wird unnötig als komplexe Erweiterung umgesetzt.
Änderung im Standardtemplate
Die Anpassung wird beim nächsten Update überschrieben oder blockiert wichtige Aktualisierungen.
Keine Updateprüfung
Eigene Overrides und Plugins werden nach Shop- oder Templateupdates nicht getestet.
Funktion nur ausgeblendet
Eine serverseitige Berechtigung wird durch eine rein optische Ausblendung ersetzt.
Keine Dokumentation
Später ist nicht mehr erkennbar, welche Dateien und Prozesse verändert wurden.
Templateabhängiges Plugin
Die Funktion arbeitet nur mit einem einzelnen Design, obwohl sie grundsätzlich wiederverwendbar sein sollte.
Zu großer Eingriff
Für eine kleine Ausgabeänderung werden umfangreiche Standarddateien vollständig überschrieben.
Keine Testumgebung
Warenkorb- und Checkoutänderungen werden direkt im produktiven Shop ausprobiert.
Die passende Lösung verändert nur so viel wie notwendig
Je kleiner und klarer ein Eingriff bleibt, desto leichter lässt er sich testen, dokumentieren und nach einem Update kontrollieren.
Wie eine technische Anforderung vorbereitet werden sollte
Eine präzise Beschreibung hilft dabei, Plugin und Template korrekt voneinander abzugrenzen.
Hilfreich sind:
- betroffener Seitentyp
- gewünschte sichtbare Änderung
- verwendete Daten
- Regeln und Bedingungen
- notwendige Backend-Einstellungen
- betroffene Kundengruppen
- Einfluss auf Warenkorb oder Checkout
- Beispiele und Screenshots
- verwendetes Template
- eingesetzte JTL-Shop-Version
Besonders wichtig ist die Beschreibung, was vor, während und nach der Benutzeraktion geschehen soll.
Ein sinnvoller Ablauf für die Umsetzung
Vor der Entwicklung sollte die Anforderung technisch und fachlich vollständig verstanden werden.
Anforderung analysieren
Darstellung, Daten, Regeln, Benutzer und betroffene Shopprozesse werden getrennt erfasst.
Vorhandene Möglichkeiten prüfen
Standardfunktionen, Templateblöcke, Hooks und bestehende Plugins werden berücksichtigt.
Technische Form auswählen
Die Umsetzung erfolgt als CSS-, Template-, Plugin- oder kombinierte Lösung.
Testen und dokumentieren
Desktop, Mobilgeräte, relevante Kundengruppen und betroffene Bestellprozesse werden kontrolliert.
Welche Tests nach einer Templateanpassung notwendig sind
Auch eine rein visuelle Änderung kann andere Seiten oder Geräte beeinflussen.
Geprüft werden sollten:
- Desktopdarstellung
- Smartphone und Tablet
- unterschiedliche Browser
- lange und kurze Produktnamen
- Artikel mit und ohne Varianten
- mehrsprachige Inhalte
- unterschiedliche Kundengruppen
- Warenkorb und Checkout, sofern betroffen
Welche Tests nach einer Pluginentwicklung notwendig sind
Plugins müssen zusätzlich hinsichtlich Daten, Prozesse und Fehlerverhalten geprüft werden.
Je nach Funktion gehören dazu:
- Installation und Aktivierung
- Backend-Einstellungen
- unterschiedliche Eingabewerte
- leere und fehlerhafte Daten
- Benutzerrechte
- Warenkorb- und Bestellprozess
- externe Schnittstellen
- Protokollierung
- Deaktivierung und Deinstallation
- Verhalten nach Cachebereinigung
Besonders bei Warenkorb-, Preis- und Checkoutfunktionen sind vollständige Testbestellungen notwendig.
Eine funktionierende Produktseite beweist noch keinen funktionierenden Bestellprozess
Wird eine Plugininformation in den Warenkorb oder Auftrag übernommen, muss der vollständige Ablauf bis zu JTL-Wawi geprüft werden.
Wie Faymax Consulting zwischen Plugin und Template entscheidet
Faymax Consulting prüft zunächst, welche Teile der Anforderung Darstellung, Datenverarbeitung und Geschäftslogik betreffen.
Abhängig vom Ergebnis kann die Umsetzung erfolgen als:
- reine CSS-Anpassung
- Erweiterung eines Child-Templates
- Nutzung vorhandener Templateblöcke
- Installation eines bestehenden Plugins
- individuelle Pluginentwicklung
- Kombination aus Plugin und Designanpassung
Ziel ist nicht, grundsätzlich möglichst viel zu programmieren. Die technische Lösung soll den benötigten Funktionsumfang zuverlässig abbilden und gleichzeitig so wartbar und updatefähig wie möglich bleiben.
Einen Überblick über vorhandene und individuelle Lösungen bietet die Seite Plugins und Erweiterungen.
Häufige Fragen zu Plugin und Templateanpassung
Wann reicht eine Templateanpassung im JTL-Shop aus?
Wenn vorhandene Informationen nur anders gestaltet, positioniert oder abhängig von bereits verfügbaren Werten ausgegeben werden sollen, reicht häufig eine Templateanpassung.
Wann benötigt der JTL-Shop ein eigenes Plugin?
Ein Plugin ist meist notwendig, wenn neue Daten gespeichert, eigene Backend-Einstellungen benötigt, externe Schnittstellen angebunden oder Geschäftsregeln verändert werden.
Ist ein Child-Template vollständig updatesicher?
Nein. Es verhindert, dass eigene Änderungen direkt im Standardtemplate liegen. Nach Updates müssen überschriebene Dateien und verwendete Variablen trotzdem kontrolliert werden.
Kann ein Plugin auch die sichtbare Darstellung verändern?
Ja. Ein Plugin kann eigene Templates und Frontendressourcen bereitstellen oder Inhalte über vorgesehene Hooks und Blöcke in den Shop einfügen.
Prüft Faymax Consulting, welche Lösung sinnvoll ist?
Ja. Faymax Consulting bewertet Anforderung, Daten, Shopversion, Template und gewünschte Geschäftslogik und empfiehlt anschließend Templateanpassung, Plugin oder eine kombinierte Umsetzung.
JTL-Shop-Anpassungen technisch sauber umsetzen
Faymax Consulting prüft, ob Ihre Anforderung über CSS, Child-Template, vorhandenes Plugin oder eine individuelle Pluginentwicklung umgesetzt werden sollte.