Wer mit mehreren Lieferanten arbeitet, kennt das Problem: Jeder liefert Produktdaten in einem anderen XML-Format. Andere Attributnamen, andere Verschachtelung, andere Einheiten. Der native Import von Magento 2 – egal ob Open Source oder Adobe Commerce – scheitert daran regelmäßig, denn er erwartet sauber strukturierte CSV-Dateien nach dem Magento-eigenen Schema. Die Folge in vielen Shops: Stunden manueller Vorarbeit in Excel, bevor ein Produktkatalog überhaupt importierbar ist.
Der Lösungsansatz, der sich derzeit in der Magento-Community verbreitet, heißt XSLT – Extensible Stylesheet Language Transformations. Dabei wird die Lieferanten-XML vor dem eigentlichen Import durch ein Transformationsskript geschickt, das die fremde Struktur auf das Magento-Format abbildet. Aus <ArticleNumber> wird sku, aus <GrossPrice> wird price. Einmal definiert, läuft die Umwandlung bei jedem Import automatisch.
Warum scheitert der Standard-Import von Magento 2 an Lieferanten-XML?
Die Antwort ist einfach: Der eingebaute Import kennt keine Struktur-Mappings. Magento 2 verarbeitet nativ CSV-Dateien, deren Spaltennamen exakt den Attribut-Codes des Shops entsprechen müssen. Ein Lieferant, der seine Daten als XML mit eigener Feldhierarchie liefert – etwa Produkte verschachtelt unter Kategorien, Preise in einem separaten Knoten pro Kundengruppe –, liegt damit außerhalb der Spezifikation.
Die bisherigen Auswege sind bekanntlich unbefriedigend. Entweder konvertiert jemand die Dateien per Hand oder per Excel-Makro, was bei täglichen Bestandsaktualisierungen praktisch unmöglich ist. Oder es läuft eine externe Middleware, die Kosten und eine weitere Fehlerquelle in die Kette bringt.
So funktioniert die XSLT-Transformation im Import-Prozess
Technisch basiert XSLT auf Template-Regeln. Für jedes Element der Quell-XML definiert das Stylesheet, wie es im Zielformat aussehen soll. Das funktioniert auch bei komplexen Fällen: Attribute umbenennen, Werte umrechnen, Knoten zusammenführen oder splitten, leere Felder mit Defaults belegen. Da XSLT ein W3C-Standard ist und PHP die Verarbeitung nativ über die libxslt-Erweiterung unterstützt, ist keine zusätzliche Infrastruktur nötig.
Dieselbe Technik greift übrigens auch in die Gegenrichtung. Wer Daten aus Magento an ein ERP, CRM oder an den Lieferanten zurückgeben muss, definiert ein zweites Stylesheet für den Export – etwa wenn das Warenwirtschaftssystem ein festes XML-Schema für Bestellungen vorgibt.
In der Praxis setzen Händler dafür auf Extensions, die den XSLT-Schritt direkt in den Import-Workflow integrieren, etwa die Improved Import & Export Extension von Firebear Studio. Sie erlaubt, XSL-Templates pro Import-Profil zu hinterlegen und die Jobs per Cron zu automatisieren – passend zum Szenario täglicher Lieferanten-Feeds. Ähnliche Ansätze bieten Import-Module anderer Anbieter; entscheidend ist, dass das Stylesheet versionierbar bleibt und bei Änderungen am Lieferantenformat nur eine Datei angepasst werden muss.
Was bedeutet das für den Shop-Alltag?
Für Händler ab einer Million Euro Jahresumsatz mit mehreren Bezugsquellen ist das kein Randthema. Jeder neue Lieferant bringt ein neues Datenformat. Ohne Transformationsschicht wächst der Pflegeaufwand linear mit der Lieferantenzahl; mit XSLT-Mapping fällt er auf den einmaligen Aufbau des Templates. Preis- und Bestandsupdates laufen dann vollautomatisch, auch nachts per Cron.
Die Hürde liegt woanders: XSLT hat eine steile Lernkurve, und ein fehlerhaftes Stylesheet kann Daten stillschweigend verfälschen – etwa wenn Dezimaltrennzeichen oder Steuersätze falsch gemappt werden. Ein Test-Import in eine Staging-Umgebung mit Stichproben-Abgleich gegen die Quelldatei ist deshalb keine Kür, sondern Pflicht. Wer das einmal sauber aufsetzt, hat allerdings eine Import-Strecke, die jedes Lieferantenformat schluckt – und das ist im Magento-Alltag bares Geld wert.