Zum Inhalt

Troubleshooting – Import Export Pro

Cron-Profile laufen nicht automatisch

Erste Diagnose:

# Läuft der Shopware-Scheduler überhaupt?
php bin/console scheduled-task:list

# Erwartet:
# kommora.iep.run_scheduled_profiles    active    last run ...

Wenn der Scheduler inactive zeigt:

php bin/console scheduled-task:register

Wenn der Scheduler aktiv ist, aber das Profil trotzdem nicht startet:

  1. Profil aktiviert? Im Profil oben „Profil aktiv" auf ein.
  2. Cron-Ausdruck korrekt? Im Profil unter „Zeitplan".
  3. Letzte Lauf-Zeit im Job-Log prüfen – ist der Scheduler überhaupt zur richtigen Zeit gelaufen?
  4. Webserver / Cron-Setup: läuft bin/console scheduled-task:run auf der Produktion regelmäßig (z.B. via systemd)?
Test ohne Cron

Manuelle Auslösung umgeht den Scheduler komplett: 

php bin/console kommora:iep:run <profile>
Wenn das funktioniert, ist das Problem bei der Scheduler-Infrastruktur, nicht im Plugin.

Datei wird nicht gefunden

Job startet, scheitert sofort mit „Quelldatei nicht gefunden":

  1. Pfad im Profil prüfen – ist er relativ zum var/import/ aus der globalen Konfig? Oder absolut?
  2. Datei-Pattern prüfen – lieferant_*.csv matcht lieferant_acme.csv, aber NICHT Lieferant_ACME.csv (case-sensitive!).
  3. Berechtigungen des Verzeichnisses – kann der Webserver-User (www-data) die Datei lesen?
  4. Bei FTP-Upload: ist die Datei vollständig hochgeladen (oder noch im Tmp-Status .csv.part)?
Race Conditions vermeiden

Bei FTP-Uploads kann es passieren, dass der Cron triggert, während die Datei noch hochgeladen wird. Lösung: Lieferant lädt zuerst nach .tmp hoch und benennt am Ende um – oder Du gibst dem Cron einen späten Start (z.B. 30 Min nach erwartetem Upload-Ende).

Datensätze werden übersprungen ohne klare Fehlermeldung

Symptom: Job läuft durch, Status partial, aber im Log steht nur „skipped" ohne Detail.

  1. Detail-Logging in globaler Konfig aktivieren → bringt pro Datensatz eine Begründung.
  2. Match-Strategie im Profil prüfen: wenn productNumber als Schlüssel, aber die Quelldatei hat das Feld leer, wird übersprungen.
  3. Pflicht-Felder im Mapping: wenn ein als Pflicht markiertes Feld leer ist, wird übersprungen.

Encoding-Probleme bei CSV

Symptom: Umlaute werden als ä, ö oder ? importiert.

  1. Im Profil CSV-Encoding auf Windows-1252 oder ISO-8859-1 stellen, wenn die Quelle nicht UTF-8 ist.
  2. CSV-Header genau prüfen: manche Tools setzen ein BOM (Byte-Order-Mark) an den Anfang – das Plugin kann es erkennen, aber sicherheitshalber die Datei in einem Editor wie VSCode öffnen und „ohne BOM" speichern.
  3. Test mit kleinem Test-CSV (3 Zeilen) bei verschiedenen Encodings.

XLSX-Datei wird nicht eingelesen

Symptom: „Datei kann nicht geöffnet werden" oder „Unbekanntes Format".

  1. Echtes XLSX? Manche Tools nennen .xls (altes Format) wie .xlsx. Das Plugin liest nur XLSX (Office 2007+).
  2. Passwortgeschützt? Wird nicht unterstützt – Passwort entfernen.
  3. Sehr große Datei? Über 100 MB kann der Memory-Bedarf hoch sein – Batch-Größe reduzieren oder Datei splitten.
  4. PHP-Extension zip installiert? XLSX ist intern ein ZIP-Archiv.

Custom-Field-Wert wird nicht geschrieben

  1. Custom-Field-Set existiert? Settings → System → Custom Fields prüfen.
  2. Set ist der richtigen Entity (Product/Order/etc.) zugewiesen?
  3. Technical Name im Mapping korrekt (case-sensitive!) – nicht der Anzeigename.
  4. Typ-Match: ein Number-Field will Zahl, ein Bool-Field will true/false. Bei Fehl-Typ wird der Wert abgelehnt.

Kategorie-Pfad wird nicht aufgelöst

Symptom: „Kategorie nicht gefunden: Hauptkategorie > Unterkategorie"

  1. Separator im Resolver-Setup korrekt? Standard ist > mit Spaces.
  2. Sprache – das Plugin sucht standardmäßig in der Default-Sprache. Wenn Deine Kategorien nur in EN gepflegt sind, im Resolver die Sprache wechseln.
  3. Sales-Channel-Beschränkung – manche Kategorien sind nur bestimmten Channels zugeordnet. Beim Import-Profil den korrekten Sales-Channel setzen oder die Kategorien channel-weit verfügbar machen.

„Out of Memory" beim großen Import

Symptom: Job bricht mit „Allowed memory size exhausted" ab.

  1. PHP-Memory-Limit erhöhen in php.ini oder per CLI-Flag (php -d memory_limit=2G bin/console kommora:iep:run …).
  2. Batch-Größe in der globalen Konfig reduzieren (z.B. 100 statt 500) – kleinere Batches = weniger Memory pro Iteration.
  3. Detail-Logging deaktivieren – pro Datensatz ein Log-Eintrag kostet Memory.
  4. CLI statt Webserver-Job verwenden – CLI hat oft mehr Memory verfügbar.

DB-Lock-Timeouts

Symptom: „Lock wait timeout exceeded" oder „Deadlock found".

  1. Max. parallele Jobs in der globalen Konfig auf 1 setzen.
  2. Batch-Größe reduzieren – kleinere Batches = kürzere Lock-Zeiten pro Transaktion.
  3. Datenbankseite prüfen: innodb_lock_wait_timeout, innodb_buffer_pool_size.
  4. Wenn andere langlaufende Jobs (z.B. Shopware-Indexer) parallel laufen, IEP-Jobs außerhalb deren Zeitfenster legen.

Mail-Benachrichtigung kommt nicht

  1. In der globalen Plugin-Konfig Empfänger gesetzt?
  2. Shopware-Mail-Versand funktioniert generell? (Test mit anderer Mail-Aktion.)
  3. Mail im Spam-Ordner?

Performance: einzelner Datensatz braucht zu lang

Symptom: 5–10 Datensätze pro Sekunde statt erwarteter 50+.

Verdächtige:

  • Kategorie-Pfad-Resolver mit tiefer Hierarchie und vielen verfügbaren Kategorien – jeder Aufruf kostet 1 DAL-Suche.
  • Custom-Field-Auflösung mit Custom-Field-Set-Pfad – jeder Aufruf macht extra Lookup.
  • Bilder-Download – Network-IO ist die langsamste Operation.

Tipps:

  • Custom Fields mit Technical Name direkt im Mapping referenzieren (nicht Set-Pfad).
  • Bilder vorab manuell in var/media/ ablegen und im Mapping nur den Pfad referenzieren (statt URL).
  • Mapping minimieren – nur die wirklich benötigten Felder verbinden.

Hilfe holen

E-Mail an support@kommora.de mit:

  • Shopware-Version, Plugin-Version
  • Beschreibung des Profils (Modus, Format, Match-Strategie, ungefähre Mapping-Größe)
  • Datensatz-Anzahl in der Quelldatei
  • Job-Log mit Fehler-Detail
  • Beispiel-Quelldatei (Dummy-Daten, 5 Zeilen) wenn möglich