PIM für Shopware 6.

Das PIM ist ein vollwertiges Product Information Management direkt im Shopware-Admin. Statt Pflege in Drittsystemen, ETL-Pipelines oder Excel-Exporten erweitert das Plugin Shopware um das, was im Standard fehlt: massenhafte Bearbeitung, Variantengenerierung mit Mustern, sprachsensible CSV-Workflows und ein durchgehendes Snapshot-System.

Module im Überblick

Systemvoraussetzungen

Shopware

6.5, 6.6 oder 6.7 — eine Plugin-Version pro Major-Release

PHP

8.2 oder höher (8.3 empfohlen)

Datenbank

MySQL 8.0 oder MariaDB 10.11+

Admin-Stack

Vue 3 (ab Shopware 6.6) bzw. Vue 2 (Shopware 6.5)

Hosting

On-premise — keine externen API-Aufrufe, keine Cloud-Abhängigkeiten

Es gibt drei Wege, das PIM zu installieren — je nachdem, ob du das Plugin aus dem Shopware Store, als ZIP oder per Composer beziehst.

Weg 1 — Shopware Store

1. Im Shopware-Admin Erweiterungen → Store öffnen und nach „PIM für Shopware“ suchen.
2. Plugin kaufen und herunterladen.
3. Unter Erweiterungen → Meine Erweiterungen auf Installieren und anschließend Aktivieren klicken.
4. Cache löschen (passiert in der Regel automatisch).

Weg 2 — ZIP-Upload

1. Die Datei StawPim-vX_Y_Z.zip herunterladen.
2. Im Admin unter Erweiterungen → Meine Erweiterungen auf Erweiterung hochladen klicken.
3. Installieren und aktivieren wie unter Weg 1.

Weg 3 — Composer / CLI

# Plugin entpacken nach custom/plugins/StawPim
$ cd /var/www/shop
$ bin/console plugin:refresh
$ bin/console plugin:install --activate StawPim
$ bin/console cache:clear

Nach der Installation

Im Admin erscheinen unter Kataloge drei neue Menüpunkte: PIM-Dashboard, PIM (Produktliste) und PIM-Konfigurationsmatrix. Innerhalb des PIM-Moduls erreichst du außerdem Import & Export, das Audit-Log und die Translation-Übersicht. Beim ersten Aufruf der Konfigurationsmatrix wird automatisch die Feldmatrix mit allen Standard- und Custom-Fields aufgebaut.

Für die optionalen Module: OpenAI-API-Key (für KI-Textgenerierung) und DeepL-API-Key (für Übersetzungen) in der Konfigurationsmatrix unter KI & Übersetzung hinterlegen. Beide Module sind ohne Keys einfach inaktiv.

Der schnellste Weg, das PIM kennenzulernen: drei typische Workflows nacheinander durchspielen.

Das Dashboard zeigt die Katalog-Gesundheit auf einen Blick: Wo fehlen Bilder, Preise oder Übersetzungen? Welche Produkte sind unvollständig? Erreichbar über Kataloge → PIM-Dashboard.

Vollständigkeits-Score

Pro Produkt wird ein Score in Prozent berechnet, basierend auf der Befüllung der in der Konfigmatrix als relevant markierten Felder. Was als relevant gilt, ist pro Shop einstellbar — z.B. Name, Beschreibung, mind. ein Bild, Meta-Title.

Health-Kacheln

Die Übersichtsseite zeigt aggregierte Kennzahlen:

• Produkte ohne Cover-Bild — mit Direkt-Link auf die Filter-Auswahl
• Produkte ohne Preis — Stammartikel und Varianten getrennt
• Produkte ohne Beschreibung — pro Sprache
• Produkte ohne Meta-Title / Meta-Description
• Produkte mit Bestand < Schwellenwert (Schwellenwert konfigurierbar)
• Inaktive Produkte mit Lagerbestand — möglicherweise vergessen
• Top-Kategorien nach Produktzahl mit Vollständigkeit

Übersetzungs-Vollständigkeit

Pro Shopsprache erscheint ein Balken mit der Vollständigkeit aller Translation-Felder. Klick auf den Balken filtert das Listing auf die unvollständigen Produkte dieser Sprache.

Das Listing ist der zentrale Einstiegspunkt. Es zeigt Stammartikel und Varianten in einer einzigen Tabelle und ist die Quelle aller Bulk-Operationen.

Anzeigeformat

Oberhalb und unterhalb der Tabelle steht die Aggregatzeile im Format:

Produkte: 153 (Varianten: 543)

Die Zahl in Klammern bezieht sich auf die aktuell gefilterte Menge — wer einen Variantenfilter setzt, sieht hier sofort, wie viele Varianten matchen.

Inline-Aufklappen

Jeder Stammartikel mit Varianten zeigt einen kleinen Badge mit der Variantenzahl. Ein Klick darauf klappt die Varianten direkt in der Tabelle aus — ohne Modal, ohne Seitenwechsel. Varianten werden lazy geladen, erst beim Aufklappen.

Filter

Über 25 spezialisierte Filter-Kriterien stehen zur Verfügung — von Standard-Operatoren bis zu fachspezifischen Filtern wie Sichtbarkeit-Level, SEO-Meta-Status, Gewichts-/Maß-Bereiche und Datums-Ranges. Beliebig viele Bedingungen können mit UND / ODER verknüpft werden. Die Suche kennt automatisch Variantenfelder — eine Bedingung auf einem Variantenattribut trifft auch den Stammartikel, wenn mindestens eine Variante matcht.

Filter-Presets

Ein häufig genutztes Filter-Set einmal speichern, dann mit einem Klick wiederherstellen. Presets werden pro User abgelegt — jeder Pfleger hat seine eigene Sammlung. Aktive Filter-Chips bleiben oberhalb der Tabelle sichtbar; ein Klick auf das × entfernt eine einzelne Bedingung.

Inline-Edit direkt in der Tabelle

Statt jeden Wert über die Detailansicht zu pflegen, sind die häufig genutzten Felder direkt in der Listing-Zeile editierbar. Funktioniert auch für Varianten.

• Aktiv-Toggle — schaltet das Produkt an/aus, ohne Neuladen
• Bestand — Inline-Editor mit sofortigem Speichern
• Preis — Brutto-Preis, System-Währung wird korrekt erkannt
• EAN und Herstellernummer — Klick auf den Wert, ändern, fertig
• Gewicht — numerische Eingabe mit Komma-Tolerant

Nach dem Speichern wird der gespeicherte Wert verifiziert (Read-back). Wenn Shopware den Wert verwirft — z.B. wegen Vererbungslogik bei Varianten — erscheint ein Warnhinweis statt fälschlich Erfolg zu melden.

Quickview-Modal

Wer schnell mehr ändern will als nur ein Feld, klickt auf das Quickview-Icon in der Zeile. Es öffnet sich ein kompaktes Modal mit allen wichtigen Stammdaten:

• Artikelnummer, Name, EAN, MPN, Aktiv-Status
• Preis (Brutto/Netto), Einkaufspreis, Omnibus-Preis
• Bestand, Wiederauffüllzeit, Closeout-Toggle, Versandkostenfrei
• Min/Max/Schrittweite für Bestellmengen
• Beschreibung als Textarea
• Meta-Title, Meta-Description, Suchbegriffe

Welche Felder im Quickview sichtbar sind, lässt sich in der Konfigmatrix pro Sektion ein- und ausblenden. Leere Sektionen werden automatisch ausgeblendet.

Pagination & Performance

• Zeilenanzahl wählbar: 10, 25, 50, 100, 200, 500
• Pagination oben und unten verfügbar
• Schnell-zurück-nach-oben-Button rechts unten
• Spaltenkonfiguration und Page-Size werden pro User persistiert

Die Bulk-Edit-Operation ist das Herzstück des PIM. Sie verändert beliebig viele Produkte in einem Schritt, legt vorher einen Snapshot an und zeigt vor dem Apply eine vollständige Vorschau.

Ablauf einer Bulk-Operation

1. Im Listing filtern und/oder Zeilen manuell selektieren.
2. Button Mehrfachbearbeitung klicken.
3. Im Modal die zu ändernden Felder aktivieren und Werte eingeben.
4. Scope wählen: Aus Auswahl oder Aus Filter-Preset; mit/ohne Varianten.
5. Vorschau prüfen — Live-Counter „X Produkte betroffen“ und neue Werte pro Feld.
6. Übernehmen — Snapshot wird angelegt, Änderung wird ausgeführt, Audit-Log-Eintrag entsteht.

Die 22 Bulk-Felder

Snapshot-System

Vor jeder Bulk-Operation auf snapshot-fähigen Feldern wird der Vorher-Zustand der betroffenen Produkte erfasst und in der DB abgelegt. Im Audit-Log erscheint der Eintrag mit:

• User, Datum, Anzahl betroffener Produkte
• Liste der geänderten Felder
• Diff vorher/nachher pro Produkt (auch für Translations pro Sprache)
• Button Wiederherstellen direkt in der Zeile

Auf Filter beschränken

Ein häufiges Szenario: Du filterst im Listing nach einem Variantenfeld (z.B. „nur rote Schuhe“) und willst alle gefundenen Varianten ändern — aber nicht den Stammartikel, dessen andere Varianten den Filter nicht treffen.

Genau dafür gibt es im Bulk-Modal den Toggle „Auf Filter beschränken“. Aktiviert, folgt die Bulk-Aktion exakt dem aktiven Filter — der Parent bleibt unangetastet, nur die filter-treffenden Children werden geändert.

Scope-Optionen

Aus Auswahl

Nur die im Listing manuell selektierten Zeilen.

Aus Preset

Alle Produkte, die dem aktuellen Filter entsprechen — auch über mehrere Seiten hinweg.

Mit/ohne Varianten

Auf Stammartikel beschränken, oder Varianten mit einbeziehen.

Nur Varianten

Stammartikel ignorieren, nur Children verändern (sinnvoll bei Filter-Beschränkung).

Der Variantengenerator erzeugt vollständige Variantenstrukturen — von der Eigenschaftenauswahl über Artikelnummer- und Namens-Patterns bis zur Bestätigung via Vorschau. Funktioniert pro Produkt oder als Mehrfachoperation.

Workflow

Variablen für Patterns

Siehe Abschnitt 13 — Variablen-Referenz für die vollständige Liste mit Beispielen.

Per Produkt vs. Mehrfachoperation

Die Variantenmatrix funktioniert auf zwei Ebenen:

• Pro Produkt: Im Produkt-Detail-Modal kann ein einzelner Stammartikel sein eigenes Pattern, eigene Optionen und ein Override gegenüber der Konfigmatrix haben. Existierende Configurator-Settings werden respektiert, die Variantenposition wird automatisch fortgeführt.
• Bulk: Im Listing mehrere Stammartikel auswählen, Varianten generieren klicken. Dasselbe Pattern wird auf alle gewählten Parents angewendet.

Variantenmatrix · Bulk-Preise und Bestand

Bei einem Variant-Produkt mit vielen Optionen ist die Preis- und Bestandspflege zeilenweise mühsam. Die Variantenmatrix legt alle Varianten in einer Tabelle übereinander: Eine Achse zeigt die erste Eigenschaft (z.B. Farbe), die andere die zweite (z.B. Größe). Pro Zelle stehen Preis und Bestand zum direkten Editieren.

• Inline-Edit für Preis, Bestand, EAN, MPN
• Spaltenkonfiguration: welche Werte angezeigt werden, ist umschaltbar
• Sortierung der Eigenschaften per Drag-and-Drop
• Optional: Werte aus dem Stammartikel auf alle leeren Zellen anwenden

Daten vom Stammartikel an Varianten übertragen

Im Varianten-Tab gibt es Aktionen, die Daten vom Parent auf alle Children kopieren — sinnvoll für Felder, die sich zwischen Varianten nicht unterscheiden:

• Beschreibung und Meta-Texte übertragen
• Staffelpreise auf Varianten anwenden
• Cross-Selling-Streams übertragen
• Bilder und Mediengalerie an Varianten weitergeben
• SEO-Felder (Title, Description, Keywords) übernehmen

Sicheres Löschen

Varianten lassen sich aus dem Generator-Modal heraus auch wieder entfernen — mit zwei Modi:

Modus „Sicher“

Löscht nur Varianten ohne Bestellungen. Aktive Variants bleiben erhalten.

Modus „Alle“

Löscht die gesamte Variantenstruktur, inklusive solcher mit Order-History. Vor Apply wird die Anzahl explizit in einem Bestätigungsdialog gezeigt.

Hauptvarianten-Vorauswahl

Nach dem Generieren steht die Frage, welche Variante als Hauptvariante fungieren soll — also die Variante, die als Default ausgewählt ist, wenn ein Kunde auf das Produkt klickt. StawPim wählt diese automatisch nach einer konfigurierbaren Strategie:

Erste Variante

Die in Generierungsreihenfolge zuerst erzeugte Variante wird Hauptvariante.

Niedrigste Artikelnummer

Sortierung nach productNumber, die kleinste wird Hauptvariante. Sinnvoll für deterministische Auswahl unabhängig von Erzeugungsreihenfolge.

Hauptartikel verbergen

Optional: Der Parent wird im Listing und in Suchergebnissen versteckt — Kunden sehen nur die Variante.

Globale Defaults dafür stehen in der Konfigmatrix unter Varianten; pro Operation überschreibbar.

CSV, TSV oder XML — alles drei werden unterstützt. Sie sind der Standardweg, um große Datenmengen außerhalb des Admin zu bearbeiten: in Excel, Numbers, OpenOffice oder einem Texteditor. Das PIM verwendet eine einheitliche Spaltenkonvention, die alle Sprachen in einer Datei abdeckt.

Export

Im Import-/Export-Modul: gewünschte Felder, Sprachen, Verkaufskanäle und Dateiformat (CSV, TSV, XML) wählen — die Auswahl wird pro Shop gespeichert und beim nächsten Export vorgeschlagen.

Was exportiert werden kann

• Alle Standard-Produktfelder
• Übersetzungen pro Sprache (auch je Verkaufskanal)
• Custom Fields, auch pro Sprache
• Variantenfelder — Parent-Daten und Variant-Daten in einer Datei
• Eigenschaften (Properties), Tags, Kategorien

Spaltenkonvention

Die Spalten folgen einem einfachen Schema mit doppeltem Unterstrich als Trenner. Siehe auch Abschnitt 14 — CSV-Spalten-Referenz.

# Standard-Feld (sprachneutral)
productNumber, active, stock

# Translation eines Standard-Felds
trans_name__de_DE
trans_name__en_GB
trans_description__de_DE

# Custom Field (sprachneutral)
cf_meinFeld

# Custom Field pro Sprache
cf_meinFeld__de_DE
cf_meinFeld__en_GB

Import

Beim Import läuft alles über die Shopware-Sync-API in Batches — auch 10.000 Produkte sind in wenigen Minuten durch. Drei Dateiformate werden akzeptiert:

CSV

Komma- oder Semikolon-getrennt, UTF-8 (mit oder ohne BOM). Standardweg für Excel.

TSV

Tab-getrennt — geeignet für Daten mit Kommas in Feldwerten.

XML

Strukturiertes Format, ideal für Lieferanten-Feeds.

Der Workflow ist für alle drei Formate identisch:

1. Pre-Fetch: Bestehende Werte aller betroffenen Produkte werden gelesen.
2. Snapshot: Vorher-Zustand wird abgelegt — auch Translation-Werte.
3. Match: Produkte werden per productNumber identifiziert.
4. Anlage oder Update: Existiert ein Match, wird geupdatet; sonst wird das Produkt neu angelegt.
5. Translation-Phase: Sprachspalten werden separat verarbeitet, Custom-Field-JSON wird gemerged, nicht überschrieben.
6. Audit-Log: Eintrag mit Diff entsteht, Revert-fähig.

Auflösung per Artikelnummer oder EAN

Für Felder, die normalerweise eine UUID erwarten — parentId, mainVariantId, parentProductNumber — akzeptiert das PIM drei Eingabe-Formate, in dieser Reihenfolge:

1. UUID (32 Hex-Zeichen) — direkt verwendet
2. Artikelnummer — wird per POST /api/search/product aufgelöst
3. EAN — als Fallback, falls keine Artikelnummer matcht

Damit kannst du beim Import neuer Artikel mit lesbaren Werten arbeiten statt UUIDs aus dem Quell-System mitschleppen zu müssen. Auflösungen werden gecacht — kein doppelter Lookup beim selben Wert.

Custom Fields als eigene Spalten

Aktivierte Custom Fields aus der Konfigmatrix bekommen im Export jeweils eine eigene Spalte (cf_meinFeld). Beim Import werden diese Spalten erkannt und landen automatisch in der richtigen Custom-Field-Property. Translatable Custom Fields nutzen cf_meinFeld__de_DE, cf_meinFeld__en_GB etc.

Die Spalte customFields mit komplettem JSON wird nicht mehr zusätzlich exportiert, wenn die Custom Fields als einzelne Spalten vorhanden sind — sonst stünde derselbe Wert doppelt in der Datei.

Datentyp-Erkennung

Das PIM erkennt Datentypen locale-bewusst — deutsche Zahlen mit Komma genauso wie angloamerikanische mit Punkt, ISO-Daten genauso wie dd.mm.yyyy.

Statt im Shopware-Header zwischen Sprachen zu wechseln und jedes Mal neu zu laden, zeigt das PIM alle Übersetzungen pro Produkt parallel — in einer Spaltenansicht.

Translation-Tab

Im Produkt-Detail erscheint ein eigener Translations-Tab. Pro Sprache eine Spalte; pro Feld eine Zeile. Name, Beschreibung, Meta-Title, Meta-Description und Keywords sind parallel editierbar — auch lange Texte mit dem Rich-Text-Editor.

Custom Fields pro Sprache

Klassisches Shopware speichert Custom Fields im sprachneutralen customFields-JSON der Product-Entity. Für mehrsprachige Inhalte ist das zu wenig. Das PIM erweitert das:

• Custom Fields können als translatable markiert werden.
• Werte werden dann in der jeweiligen Product-Translation gespeichert.
• CSV-Spalten folgen dem Schema cf_<name>__<lang>.
• Im Translations-Tab erscheinen sie automatisch in der Spaltenansicht.

Translation-Dashboard

Welche Produkte sind in welcher Sprache komplett? Das Dashboard zeigt:

• Abdeckung pro Sprache in Prozent
• Abdeckung pro Verkaufskanal (Sprachen je Channel werden respektiert)
• Direkt-Links zu unvollständigen Produkten
• Pflichtfelder pro Sprache (in Konfig einstellbar)

Verkaufskanal-Awareness

Nicht jeder Verkaufskanal hat alle Sprachen — der deutsche B2B-Channel braucht vielleicht nur DE, der internationale Storefront DE + EN + FR. Das PIM kennt diese Zuordnung und zeigt im Detail-Tab nur die für den jeweiligen Kontext relevanten Sprachen an. Im Dashboard wird Vollständigkeit pro Channel separat aggregiert.

Optionale Module — Text-Generierung mit KI (wahlweise ChatGPT von OpenAI oder Claude von Anthropic) und Massen-Übersetzung mit DeepL. Beide funktionieren komplett separat von den Kernfunktionen; das PIM läuft auch ohne sie. Wer sie nutzen möchte, hinterlegt einen API-Key in der Konfigmatrix unter Texte & Übersetzungen.

KI-Textgenerierung — ChatGPT oder Claude

In der Konfigmatrix wählst du den Anbieter (OpenAI ChatGPT oder Anthropic Claude) und das Modell (z.B. gpt-4o, claude-sonnet-4). Beide werden über die gleiche Oberfläche bedient — das Backend wickelt die Provider-spezifischen API-Aufrufe ab. Bei aktivem Key erscheinen kleine KI-Buttons neben den Textfeldern. Verfügbare Aktionen:

• Beschreibung generieren — aus Produktname, Kategorie, Properties
• Meta-Title vorschlagen — SEO-optimiert, mit Längenlimit
• Meta-Description vorschlagen — Call-to-Action am Ende
• Keywords extrahieren — aus Name und Beschreibung
• Text umschreiben — Tonalität ändern (formell/casual/SEO-fokussiert)
• Text kürzen / verlängern — auf gewünschte Länge bringen

KI in der Mehrfachbearbeitung

Statt jedes Produkt einzeln zu bearbeiten, lässt sich die KI auch im Bulk-Modus nutzen: Filter setzen, Produkte markieren, Mehrfachbearbeitung → KI-Text generieren. Pro Produkt wird ein passender Text gebaut. Snapshot wird wie bei jeder Bulk-Operation vorher angelegt — Rollback möglich, wenn das Ergebnis nicht passt.

Prompts sind in der Konfigmatrix als Templates hinterlegt und pro Sprache überschreibbar. Variablen im Prompt: {name}, {category}, {properties}, {manufacturer}, {currentText} und weitere.

DeepL-Übersetzung

Im Translation-Tab erscheint pro Sprachspalte ein Übersetzen-Button. Klick übersetzt die aktuelle Zeile (oder alle Felder) von der konfigurierten Quellsprache in die Zielsprache. Bestehende Texte können wahlweise überschrieben oder nur leere Felder gefüllt werden.

Massen-Übersetzung

Im Translation-Dashboard: Sprache und Felder wählen, „Alle fehlenden mit DeepL befüllen“ klicken. Das PIM iteriert über alle unvollständigen Produkte und befüllt sie batch-weise. Fortschritts-Anzeige, Abbruch möglich, Snapshot wird vorher angelegt — Rückrollen via Audit-Log.

Glossare

DeepL-Glossare werden unterstützt. Begriffe wie Markennamen, Produktbezeichnungen oder Fachterminologie können pro Sprachpaar als Glossar hinterlegt werden — DeepL übersetzt sie dann konsistent.

Permissions

Für KI und DeepL gibt es separate Permissions (pim.ai_use, pim.ai_bulk, pim.deepl_use, pim.deepl_bulk) — sodass z.B. Texter KI im Einzel-Modus nutzen, aber nur ein Administrator Massen- Generierung oder Massen-DeepL anstoßen darf.

Das PIM deckt den kompletten Produktlebenszyklus ab. Hier die wichtigsten Module außerhalb von Bulk/CSV.

Medien

• Drag & Drop-Upload direkt aus dem Produkt-Detail.
• Alternative: Auswahl aus der Shopware-Media-Bibliothek.
• Coverbild-Definition per Klick auf das Stern-Symbol.
• Galerie-Reihenfolge per Drag & Drop — atomare Batch-Speicherung mit Fehleranzeige.
• Alt-Texte pro Bild und Sprache.

Preise

• Beliebig viele Preisstaffeln pro Produkt.
• Brutto/Netto-Eingabe je Steuersatz mit Live-Berechnung.
• Listenpreis (UVP) zur Anzeige als „Statt-Preis“ im Shop.
• Optional: Bulk-Übertragung der Staffelpreise auf alle Varianten (nicht-revertierbar).

Properties

• Property-Zuweisung pro Produkt — oder im Bulk für viele auf einmal.
• Suche, Gruppierung, Mehrfachselektion.
• Erstellen und Editieren von Property-Gruppen direkt im PIM — inkl. Farb-Swatches, Bildern, Übersetzungen.
• Auch im Translations-Tab pro Sprache pflegbar (Property-Übersetzungen).

Cross-Selling

• Mehrere Cross-Selling-Streams pro Produkt.
• Manuelle Produktliste oder dynamische Produktgruppe (Stream).
• Produkt-Suche mit Drag & Drop-Sortierung.
• Bulk-Zuweisung über Mehrfachbearbeitung.
• Optional Übertragung auf Varianten (nicht-revertierbar).

Kategorien

• Standard-Kategorienzuweisung wie im Shopware-Admin.
• Hauptkategorie pro Verkaufskanal — für korrekte Breadcrumbs und SEO.
• Anzeige als Kategoriename (auch bei 500+ Kategorien performant).
• Im Bulk änderbar.

SEO

• Meta-Title, Meta-Description, Keywords pro Sprache.
• Im Bulk-Modus änderbar.
• SEO-URL wird von Shopware generiert (nicht im Snapshot).

Wenn mehrere Personen Produkte pflegen, ist Nachvollziehbarkeit alles. Das PIM protokolliert jede schreibende Operation, kann auf einen Vorher-Zustand zurückrollen und verhindert über einen Edit-Lock paralleles Überschreiben.

Audit-Log

Jeder Eintrag enthält:

Zeitstempel

Wann die Operation lief (auf Sekundengenau)

User

Welcher Admin-User die Aktion ausgelöst hat

Operation

Bulk-Edit, CSV-Import, Variantengenerierung, manuelle Einzeländerung, KI-Generierung, DeepL-Übersetzung

Scope

Anzahl betroffener Produkte + Liste der productNumbers

Diff

Vorher/Nachher pro Feld, auch für Translations pro Sprache

Snapshot-Status

Ob ein Revert möglich ist (ja/nein)

Die Aufbewahrungsfrist für Audit-Einträge ist in der Konfigmatrix einstellbar (Standard: 90 Tage). Ein scheduled task räumt ältere Einträge automatisch auf, inklusive der zugehörigen Snapshots.

Ein-Klick-Revert

Aus dem Audit-Log direkt zurückrollen — der komplette Produktzustand vor der Operation wird wiederhergestellt. Translations werden mit zurückgesetzt. Der Revert selbst erzeugt einen neuen Audit-Log-Eintrag, sodass die Historie lückenlos bleibt.

Edit-Lock mit Heartbeat

Wenn zwei Pfleger gleichzeitig dasselbe Produkt öffnen, würde ohne Schutz der letzte Speichern-Vorgang gewinnen und Änderungen des anderen Users überschreiben. Der Edit-Lock verhindert das:

• Beim Öffnen eines Produkt-Details wird ein Lock mit User-ID und Timestamp gesetzt.
• Ein Heartbeat erneuert den Lock alle 30 Sekunden, solange das Tab offen ist.
• Ein anderer User, der dasselbe Produkt öffnet, sieht einen Hinweis: „Wird bearbeitet von {Name} seit {Zeit}“ und kann nur lesend zugreifen.
• Bleibt der Heartbeat 2 Minuten aus (Tab geschlossen, Browser-Crash), wird der Lock automatisch freigegeben.
• Admins mit pim.lock_break-Permission können einen Lock manuell brechen.

Produkt-Vorschau (inaktive Artikel)

Inaktive Produkte sind im Storefront unsichtbar — was die Vorschau im Browser zur Qual macht. Mit dem Preview-Modul kann ein inaktiver Artikel temporär aktiviert werden, ohne dass er regulär verkaufsbereit ist:

• Im Produkt-Detail Button Vorschau anzeigen mit konfigurierbarer Dauer (15s / 30s / 60s / 120s).
• Aktivierung mit temporärer Sichtbarkeit „Nur per Direktlink“ (Level 10) — nicht in Listings, nicht in Suche.
• Direkt-URL wird in einem neuen Tab geöffnet.
• Nach Ablauf wird die Sichtbarkeit automatisch entfernt und das Produkt wieder deaktiviert.
• Auch bei Navigation oder Tab-Schließung wird sauber aufgeräumt.

Approval-Workflow

Optionales Feature: Produkte können nach Anlage oder Import auf pending gesetzt werden und müssen vor der Aktivierung im Shop von einem Benutzer mit Approval-Recht freigegeben werden. Sinnvoll bei:

• Mehrstufigen Pflegeprozessen (Texter → Lektor → Freigabe)
• Bulk-Imports von Lieferanten-CSVs
• Externen Pflegern mit eingeschränkten Rechten

Permissions

Das Berechtigungssystem ist feingranular und lehnt sich an die Shopware-ACL an. Jede Bulk-Aktion, jeder Modus von CSV, jedes Löschen ist als eigene Permission freischaltbar:

Die zentrale Konfigmatrix steuert, welche Felder sichtbar sind, welche Patterns als Default gelten und wie sich das Listing verhält. Erreichbar über PIM → Konfiguration.

Feldmatrix

Pro Feld vier Toggles:

Custom Fields werden automatisch erkannt und in die Matrix aufgenommen, sobald sie in Shopware angelegt sind. Bei Bedarf Custom Fields neu scannen klicken.

Sektionsreihenfolge per Drag-and-Drop

Die Reihenfolge der Sektionen in der Produkt-Detailansicht (Stammdaten, Preise, Medien, SEO, Properties, Cross-Selling, etc.) lässt sich per Drag-and-Drop frei festlegen. Dasselbe gilt für die Sektionen im Varianten-Detail-Modal — beide werden getrennt konfiguriert.

Sektionen, in denen alle Felder deaktiviert sind, werden automatisch ausgeblendet. Kein leerer Akkordeon-Header mit nichts dahinter.

Standard-Steuersatz für neue Produkte

Beim Anlegen eines neuen Produkts wird automatisch der erste Steuersatz aus dem Shopware-System vorausgewählt (sortiert nach position ASC). Sowohl taxId als auch taxRate werden gesetzt, sodass die Brutto/Netto-Berechnung sofort funktioniert.

Vollständigkeitsbewertung

Welche Felder zählen für den Vollständigkeits-Score im Dashboard? In der Konfigmatrix pro Feld eine Gewichtung (0–10) vergeben. Felder mit Gewichtung 0 werden ignoriert; höhere Werte zählen stärker. Pro Produkt wird ein Prozent-Wert daraus berechnet.

Variantenmuster

Pro Shop kannst du Default-Patterns für Artikelnummer und Variantennamen hinterlegen. Diese gelten in allen Variantenoperationen — pro Produkt überschreibbar.

# Default-Pattern für Artikelnummern
{number}-{option1}-{option2}

# Default-Pattern für Variantenname
{parentName} · {option1} {option2}

Export-Defaults

Im Konfigmatrix-Tab Import & Export hinterlegst du Standardwerte für CSV-Exporte — Profil-Auswahl, Trennzeichen (Komma / Semikolon / Tab), Maximum-Zeilen pro Datei, Dateiformat (CSV / TSV / XML), und ob Varianten standardmäßig mit exportiert werden sollen.

Konfig-Suche (Strg+K)

Die Konfiguration kann groß werden — gerade bei vielen Custom Fields. Mit Strg+K (oder ⌘+K auf Mac) öffnet sich eine Schnellsuche:

• Sucht über alle Tabs der Konfigseite
• Match-Counter pro Tab
• Auto-Scroll zum ersten Treffer
• Mit ↑/↓ zwischen Treffern navigieren
• Enter zum Übernehmen, Esc zum Abbrechen

Validation-Modal mit Scroll-to-Section

Klick auf Speichern während Pflichtfelder leer sind: statt einer Warn-Banner-Wand öffnet sich ein Modal mit allen Fehlern. Klick auf einen Fehler springt direkt zur betroffenen Sektion — sie wird automatisch aufgeklappt, das Feld wird mit einer indigo Outline kurz hervorgehoben.

Pro-User-Persistenz

Folgende Einstellungen werden pro Admin-User gespeichert, nicht global:

• Spaltenkonfiguration im Listing (welche Spalten sichtbar, in welcher Reihenfolge)
• Page-Size
• Filter-Presets
• Sortierung

Jeder Pfleger hat damit seine eigene Sicht — ohne sich gegenseitig die Einstellungen zu überschreiben.

Patterns für Artikelnummer und Variantenname akzeptieren Variablen in geschweiften Klammern. Sie werden zum Zeitpunkt der Generierung deterministisch ersetzt.

Beispiele

Klassische Variantennummer mit Optionen

# Pattern
{number}-{option1}-{option2}

# Ergebnis (Farbe=rot, Größe=M)
SW-1001-rot-M

Sortierbare Variantennummer mit Counter

# Pattern
{number}-V{counter:3}

# Ergebnis (3 Varianten)
SW-1001-V001
SW-1001-V002
SW-1001-V003

Lesbarer Variantenname

# Pattern
{parentName} ({group1}: {option1}, {group2}: {option2})

# Ergebnis
Sneaker Pro (Farbe: rot, Größe: M)

Die folgenden Spaltennamen werden vom Import erkannt. Beim Export werden sie nach derselben Konvention erzeugt.

Stammdaten (sprachneutral)

Translations

Spalten beginnen mit trans_ und enden mit __<lang>.

Custom Fields

Spalten beginnen mit cf_.

Die größeren Erweiterungen aus den letzten Release-Zyklen — nach Thema sortiert.

Mein CSV-Import lädt nicht — was tun?

• Kodierung prüfen: Das PIM erwartet UTF-8 (mit oder ohne BOM).
• Trennzeichen prüfen: Semikolon (;) oder Komma (,) — wird automatisch erkannt, aber muss konsistent sein.
• Pflichtfeld productNumber muss vorhanden sein.
• PHP-Memory-Limit auf min. 512 MB setzen für Imports > 5.000 Zeilen.
• PHP-Execution-Time auf 300+ Sekunden setzen oder Cronjob nutzen.

Die Snapshot-Wiederherstellung wirft einen Fehler

Möglicher Grund: Das Produkt wurde zwischen dem ursprünglichen Snapshot und dem Revert manuell gelöscht oder verändert. Das PIM zeigt im Detail-Dialog des Audit-Logs an, welche Zeilen nicht zurückgerollt werden konnten, und führt den Rest dennoch aus.

Custom Fields tauchen nicht in der Konfigmatrix auf

In der Konfigseite auf Custom Fields neu scannen klicken. Wenn das nicht hilft: Shopware-Cache löschen und Seite neu laden.

Wie kann ich Translations für einen ganz neuen Custom Field nachträglich aktivieren?

1. Custom Field in Shopware bearbeiten und translatable aktivieren.
2. In der PIM-Konfig Custom Fields neu scannen.
3. Bestehende Werte werden als Default-Sprache (Shop-Default) übernommen — andere Sprachen müssen befüllt werden.

Bulk-Edit dauert sehr lange

Bei mehreren tausend Produkten: kein Problem grundsätzlich, aber abhängig vom Server. Empfehlungen:

• Auf produktivem Server: keine Bulk-Operationen während Stoßzeiten.
• PHP-OPcache aktivieren.
• MySQL innodb_buffer_pool_size > 1 GB.
• Wenn möglich: SSD-Storage.

Kann ich das PIM parallel zu anderen PIM-Plugins betreiben?

Technisch ja — das PIM patcht keine Core-Files und schreibt nur in seine eigenen Tabellen sowie die Standard-Shopware-Produkttabellen. Konflikte kann es geben, wenn ein anderes Plugin dieselbe Field-Definition überschreibt. Bei Bedarf Support kontaktieren.

Wie häufig erscheinen Updates?

Patch-Releases (1.0.x) alle 2–4 Wochen, Minor-Releases (1.x.0) bei größeren Features. Major-Releases sind an Shopware-Versionen gekoppelt — eine Plugin-Version pro Shopware-Major.

Für Entwickler und technisch interessierte Admins — ein kurzer Blick unter die Haube.

Plugin-Struktur

StawPim/
├── composer.json
├── src/
│   ├── StawPim.php                # Plugin-Bootstrap, install/activate/update Hooks
│   ├── Controller/                # Admin-API-Routes (/api/_action/staw-pim/...)
│   ├── Service/
│   │   ├── BulkEditService.php
│   │   ├── SnapshotService.php
│   │   ├── CsvImportService.php
│   │   ├── CsvExportService.php
│   │   ├── VariantGenerator.php
│   │   ├── TranslationService.php
│   │   └── AuditLogService.php
│   ├── Migration/                 # DB-Migrationen
│   └── Resources/
│       ├── app/administration/   # Vue 3 Admin-Components
│       ├── config/services.xml
│       ├── snippet/de-DE.json
│       └── snippet/en-GB.json
└── tests/                         # PHPUnit + Vitest

Datenbanktabellen

staw_pim_snapshot

Vorher-Zustände aller revertierbaren Operationen (JSON-Spalte mit Produkt-Daten)

staw_pim_audit

Audit-Log-Einträge mit User, Timestamp, Operation, Diff (FK auf snapshot)

staw_pim_preset

Filter-Presets pro User

staw_pim_config

Feldmatrix-Konfiguration und Default-Patterns pro Shop

staw_pim_user_settings

Spaltenkonfiguration, Page-Size und User-Präferenzen pro Admin-User

Admin-API-Endpoints

Alle Endpoints sind unter /api/_action/staw-pim/* erreichbar und benötigen ein gültiges OAuth-Token (wie alle Shopware-Admin-APIs).

Frontend-Stack

• Vue 3 mit Composition API (für Shopware 6.6+)
• Components nach Shopware-Komponenten-Konvention (sw-*)
• Eigene Components mit Prefix staw-pim-*
• Vite-Build für Production (.vite/manifest.json)
• Snippet-System für i18n — keine hartkodierten Strings

Sauberer Code

• DI-Container-Services, keine globalen Statics
• DAL-konformer Datenzugriff (keine direkten SQL-Queries in Business-Logik)
• Keine Patches an Core-Files
• Symfony Messenger für Async-Tasks (große CSV-Imports)
• PHPUnit-Tests für alle Services, Vitest für Vue-Components