OXID 6.3 → Shopware 6.7 Migration

Zwei entkoppelte Teile, die ausschliesslich über eine JSON-Datei kommunizieren: der Export läuft auf dem alten OXID-Server, der Import auf dem neuen Shopware-Server. Das gesamte Mapping passiert zur Export-Zeit über mapping.yaml; die JSON ist self-contained, der Importer braucht keine eigene Konfiguration.

Verzeichnisse

Wähle einen Exporter — alle drei erzeugen dieselbe oxid-export.json und sind funktional deckungsgleich (inkl. Bild-Diagnose, Steuer-Mapping, Zahlart, Datums-Logik). Der Standalone ist die robusteste Wahl auf Altservern, weil Composer/Packagist nicht benötigt wird.

Schritt 1 — Export aus OXID

cd oxid-export-standalone        # oder oxid-export / oxid-export-php72
composer install                 # beim Standalone NICHT nötig

php bin/export \
  --oxid-config=/var/www/oxid/source/config.inc.php \
  --mapping=mapping.yaml \
  --out=oxid-export.json

Zugangsdaten wahlweise über --oxid-config (liest config.inc.php) oder --db-host/--db-name/--db-user/--db-pass bzw. OXID_DB_*-Umgebungsvariablen.

Weitere Optionen: --default-vat=19, --skip-orders, --skip-customers, -o/--out, -m/--mapping, --help.

mapping.yaml

default_vat: 19.0

vat:
  mode: oxid            # oxid | standard | reduced
  standard_rate: 19.0
  reduced_rate: 7.0
  map:                  # optional, hat Vorrang vor mode
    16: standard
    5: reduced

images:
  base_url:   "https://alt-shop.de/out/pictures/master/product"
  source_dir: "/var/www/oxid/source/out/pictures/master/product"
  copy_to:    "./media-export"
  pic_fields: [1,2,3,4,5,6,7,8,9,10,11,12]

manufacturers: { enabled: true }
orders:        { enabled: true }
customers:     { enabled: true }

properties:
  - group: "Zustand"
    source: attribute          # oxobject2attribute / oxattribute
    oxid_attribute: "Zustand"
    options: { "sehr gut": "Sehr gut", "gut": "Gut" }   # optional Whitelist+Rename
  # - { group: "Material", source: field, oxid_field: "OXMATERIAL" }

attributes:                    # Kurzform: jeder Name wird zur Property-Gruppe
  - Farbe
  - Größe

Umsatzsteuer (vat.mode)

map-Einträge schlagen den Modus. Alles auf 7 %: mode: reduced und keine map.

Bilder — drei Betriebsarten

Der Kopier-Modus kopiert die Master-Bilder unter eindeutigen, stabilen Namen nach copy_to — den Ordner anschliessend auf den neuen Server synchronisieren und beim Import mit --media-dir darauf zeigen. Enthält ein OXPIC-Feld bereits eine komplette URL, wird sie unverändert übernommen.

Bild-Diagnose: Werden 0 Bilder exportiert, erklärt der Exporter warum — Bild-Export deaktiviert, keine OXPIC-Werte vorhanden (inkl. Prüf-SQL), oder Dateien nicht unter source_dir gefunden (mit bis zu 5 konkreten Pfaden).

Schritt 2 — Plugin installieren

# MojoOxidImport/ nach custom/plugins/ kopieren
bin/console plugin:refresh
bin/console plugin:install --activate MojoOxidImport
bin/console cache:clear

Bei der Aktivierung legt das Plugin das Produkt-Custom-Field condition_of_used an.

Schritt 3 — Import nach Shopware

bin/console mojo:oxid:import --file=oxid-export.json --media-dir=/pfad/zu/media-export

Reihenfolge: Hersteller → Property-Gruppen → Kategorien → Produkte (inkl. Bilder) → Kunden → Bestellungen → Bestand-Wiederherstellung → Index-Rebuild.

Während des Imports werden keine E-Mails versendet. Ein ImportStateService-Flag plus Subscriber stoppen CustomerRegisterEvent und den Catch-all MailBeforeValidateEvent, sodass keine Flow-Builder-/Transaktionsmail rausgeht. Die Indizierung ist während der Schreibvorgänge deaktiviert und wird am Ende einmal neu aufgebaut.

Feld-Mapping

Produkte

Doppelte Artikelnummern: OXID erzwingt keine Eindeutigkeit, Shopware schon. Duplikate werden deterministisch entschärft (ca03, ca03-<hash>); Kollisionen mit bereits vorhandenen Shopware-Produkten ebenso. Alle Umbenennungen werden am Ende aufgelistet. Schlägt ein Batch fehl, wird produktweise nachgefasst, damit ein fehlerhafter Datensatz nicht den Lauf abbricht.

Kunden, Adressen, Passwörter

Passwörter migrieren ohne Klartext. Der mitgelieferte OxidLegacyEncoder (Service-Tag shopware.legacy_encoder) prüft beim ersten Login beide OXID-Varianten — bcrypt ($2y$…) und sha512+Salt. Danach re-hasht Shopware transparent und leert die Legacy-Felder.

Bestellungen

Historische Snapshots — sie werden nicht durch die State-Machine gespielt.

Bezahlt-Erkennung: Viele Shops pflegen OXPAID bei Vorkasse nie. Als bezahlt gilt daher: OXPAID gesetzt oder OXSENDDATE gesetzt oder OXFOLDER = ORDERFOLDER_FINISHED. Abschaltbar mit --strict-paid.

Zahlarten: Die installierten Shopware-Zahlarten werden einmalig klassifiziert (über Handler/technischen Namen), PayPal also nur erkannt, wenn das Plugin installiert ist.

Bestelldatum: Bei unbrauchbarem OXORDERDATE (0000-00-00, z. B. abgebrochene Gateway-Zahlungen) wird nie die aktuelle Zeit gesetzt. Reihenfolge: OXORDERDATE → Versanddatum → Sentinel 1970-01-01, damit solche Datensätze erkennbar bleiben statt als „heute" zu erscheinen.

Lagerbestand: Shopwares Stock-Subscriber bucht bei jeder importierten Position Bestand ab, als wäre es ein frischer Verkauf. Der OXID-Bestand bildet diese Bestellungen aber bereits ab — deshalb wird der Bestand nach dem Order-Import automatisch aus dem Export wiederhergestellt.

Fehlerdiagnose: Bestellungen werden einzeln geschrieben. Fehlschläge werden nach Ursache gruppiert ausgegeben (innerste Exception, IDs normalisiert) — inklusive Beispiel-Bestellnummern, damit die tatsächliche Ursache sichtbar ist statt nur einer Fehlerzahl.

Idempotenz

Alle IDs sind deterministische Hashes der OXID-Identifier bzw. Bildquellen; geschrieben wird per upsert. Wiederholte Läufe aktualisieren bestehende Datensätze, statt zu duplizieren. Bereits geladene Bilder werden nicht erneut geholt.

Bekannte Grenzen

• Varianten werden flach importiert (jede oxarticles-Zeile = eigenes Produkt); parentOxid bleibt in der JSON für eine spätere Parent/Child-Rekonstruktion erhalten.
• Einsprachig (OXID-Basissprache 0); *_1-Spalten werden nicht gelesen.
• Properties sind filterbare Eigenschaften, keine varianten-bildenden Optionen.
• Bestellungen ohne Lieferungen (order_delivery); Zahlung als eine Transaktion. Positionen ohne auffindbares Produkt werden als custom-Positionen geschrieben.
• Staffelpreise (oxprice2article) und Lieferanten (oxvendor) fehlen noch.
• Produkte werden in allen Sales-Channels sichtbar gesetzt (VISIBILITY_ALL).

Voraussetzungen

• Exporter: PHP ≥ 8.2 (oxid-export/), ≥ 7.2 (oxid-export-php72/, oxid-export-standalone/), jeweils mit ext-pdo, ext-mbstring, ext-json und MySQL-Zugriff auf die OXID-Datenbank.
• Importer: Shopware-6.7-Projekt (PHP 8.2+).

Troubleshooting

pCon UI

Eine pCon-UI-Integration für Shopware 6

Dieses Plugin bindet den pCon-Konfigurator als iframe-Lösung in die Produktdetailseite ein – aufgerufen über einen Konfigurations-Button.

EasternGraphics / Pcon-Solutions

Pcon Solutions ist eine leistungsfähige grafische Produktkonfigurations-Lösung – der Name sagt es bereits (product Configurator). Sie ermöglicht die Spezifikation und Präsentation komplexer Produkte auf einfache und verständliche Weise. Produkte werden nach vordefinierten Regeln konfiguriert, sodass keine Spezifikationsfehler entstehen.

Link: EasternGraphics

Link Pcon-Solution

Support: E-Mail: pm_p-cloud@easterngraphics.com Telefon: +49 3677 6782-0

HOOK_URL

Die konfigurierten Produktdaten des pCon-Konfigurators werden als POST-Daten an die Hook-URL übertragen. Die Hook-URL wird im Shopware-Backend als Plugin-Konfiguration gesetzt.

HOOK_URL: shop.domain.com /pconui/postdata

PCON UI URL

Die Domain für den pCon-UI-iframe, gehostet von EasternGraphics.

PCONUI_URL: ui.pcon-solutions.com

Price Service

Die Price-Service-Datei ist für die Berechnung der Umsatzsteuer auf Nettopreise zuständig. Der direkte Link zum Price Service wird von EasternGraphics für den iframe gesetzt: https://shop.domain.com/priceservice.php

Shopware-6-Verzeichnis → public/ priceservice.php

OPC API Version

Das Plugin erkennt die neue API-Version OPC 5.0 und passt das Daten-Set für das POST-Daten-Array des pCon-Konfigurators entsprechend an.

Zugänge

pCon Login: https://login.pcon-solutions.com/

pCon Admin: https://ui.pcon-solutions.com/#GATEKEEPER_ID=xxxxxxxxxx&ap=true

Lizenz

The MIT License (MIT). Siehe LICENSE-Datei für weitere Informationen.

Comic-Antiquariat Katalog

Software zur Sammlungsverwaltung, zum Katalogdruck und -versand: eine Sammlung – vom einzelnen Heft bis zum Konvolut – erfassen, bewerten und pflegen, und daraus auf Knopfdruck einen druckfertigen Verkaufskatalog erzeugen, wahlweise als PDF zum Versand oder als Druckvorlage.

Ausgangslage. Umfangreiche Sammlungen – Comics, Romanhefte, Sammelbilder – werden bei vielen Antiquariaten und privaten Sammlern nach wie vor auf Papier, in Karteikarten oder in unverbundenen Tabellen geführt. Das erschwert drei Dinge zugleich: den Überblick über den eigenen Bestand, die laufende Wertermittlung und die Erstellung aktueller Verkaufslisten für Kundinnen und Kunden. Vorhandene historische Listen – oft die einzige vollständige Bestandsaufnahme überhaupt – lassen sich mit vertretbarem Aufwand kaum digitalisieren.

Diese Anwendung löst das in einem durchgängigen Arbeitsablauf: historische Listen einlesen, im Bestand prüfen und pflegen, daraus jederzeit einen aktuellen, professionell gestalteten Katalog erzeugen. Ein zentraler Nachweis dafür ist bereits erbracht, nicht nur behauptet: Eine reale, 17-seitige Verkaufsliste eines Comic-Antiquariats aus dem Jahr 1987 mit über 4.400 Einzelpositionen in rund 210 Serien wurde vollständig eingelesen – siehe „Lebenszyklus eines importierten Eintrags“ weiter unten.

Technische Basis: Symfony 7.x, PHP 8.3, Vue 3 im Frontend, MariaDB als Datenbank. Lauffähig auf gängigem Webhosting, Deployment per SFTP – keine Bindung an einen Cloud-Anbieter. Den vollständigen Funktionsumfang und die Versionsgeschichte zeigt CHANGELOG.md.

Enthalten

Bestandsseite

Werte und Verwaltung

Katalog-Import (umgebaut) und Katalog-PDF

Anmeldung

Die Anwendung hat jetzt eine Anmeldung: alles außer /login verlangt ein Konto (security.yaml, access_control). Es gibt keine Registrierung im Browser und keine Zurücksetzung per E-Mail – Konten legt die Konsole an:

ddev console app:benutzer person@example.org             # fragt das Passwort verdeckt ab
ddev console app:benutzer person@example.org --name="Per-Olof"
ddev console app:benutzer person@example.org --passwort=…  # für Skripte; landet in der Shell-Historie
ddev console app:benutzer --liste                        # Konten und letzte Anmeldung

Dasselbe Kommando setzt bei einem vorhandenen Konto das Passwort neu. Mindestlänge: 10 Zeichen.

Abgemeldet wird über den Knopf in der Kopfzeile; die Route /logout fängt die Firewall ab, mit CSRF-Token wie beim Login (csrf.yaml führt authenticate und logout bereits). Gespeichert wird in der Symfony-Session, also einem Cookie ohne Datenbanktabelle.

Die Vue-Komponenten schicken ihre Anfragen mit credentials: same-origin, laufen also über dieselbe Session. Ist sie abgelaufen, kommt aus /api/… ein sauberes 401 mit JSON statt der Login-Seite als HTML.

Beim ersten Start nach dem Update:

ddev composer require symfony/security-bundle:7.*
ddev console doctrine:migrations:migrate
ddev console app:benutzer deine@adresse.de

Gegenüber der Vorlage geändert

1. parseLine() vs. parse() – der Command rief eine Methode auf, die es nicht gab. Jetzt: parse() liefert ein CatalogParseResult, der Command baut die Entities.
2. (float) $price widersprach der eigenen Regel „decimal, niemals float“. Preise laufen jetzt durchgängig als String.
3. Symfony\Component\Routing\Annotation\Route ist in Symfony 7 deprecated → Symfony\Component\Routing\Attribute\Route.
4. Regex erweiterte Fälle: 1-2/2, o. Nr., 33a, Komma-Preise, mehrere Attribute („N S“), optionale Währung. oS steht vor S in der Alternation.
5. Heftnummer bekommt issueSortKey – sonst sortiert die Liste 1, 10, 2.
6. Nicht erkannte Zeilen werden als NEEDS_REVIEW mit Rohtext gespeichert statt verworfen.
7. importHash (unique) macht den Import wiederholbar, ohne Dubletten anzulegen.
8. symfony/mime fehlte in composer.json, obwohl CoverImageStorage und MediaStorageService $file->getMimeType() aufrufen - diese Methode braucht das Paket immer, unabhängig vom Mime-Typ des Uploads, sonst wirft sie eine LogicException. Jeder Foto- und Titelbild-Upload endete deshalb mit HTTP 500. Jetzt in composer.json eingetragen; nach dem Einspielen einmal composer update symfony/mime laufen lassen.

Einbau

Die vollständige Anleitung steht in SETUP.md (DDEV, Datenbank, erster Importlauf, Stolpersteine). Kurzfassung:

ddev start                       # nutzt .ddev/config.yaml aus diesem Paket
ddev console make:migration
ddev console doctrine:migrations:migrate --no-interaction
ddev console app:seed-condition-grades
ddev katalog var/imports/beispiel-katalog.txt --source "Katalog August 87" --dry-run --show-failures

Danach ohne --dry-run importieren und unter /catalog?status=NEEDS_REVIEW prüfen. Freigegebene Einträge übernehmen:

ddev exec php bin/console app:seed-condition-grades
ddev exec php bin/console app:transfer-catalog-entries --dry-run

Ergebnis unter /bestand. config/packages/doctrine.yaml enthält nur den relevanten Auszug (UUID-Typ).

Erfassen ohne Import

/catalog/new legt einen Eintrag von Hand an – für Hefte, die in keiner Liste stehen. Solche Einträge starten als APPROVED (ein Mensch hat sie getippt), tragen einen manual--Hash statt eines Zeilen-Hashes und lassen sich mit „Speichern und nächster Eintrag" am Stück erfassen, wobei die Serie stehen bleibt. Gelöscht werden kann nur, was noch nicht im Bestand ist – übernommene Einträge bleiben als Beleg.

Zwei Wege in den Bestand

1. Über den Katalog: importieren → prüfen → freigeben → app:transfer-catalog-entries. Der CatalogEntry bleibt als Beleg am Objekt hängen.
2. Direkt vom Regal: /bestand/new. Serienname als Freitext mit Vorschlagsliste (neue Serien entstehen beim Speichern), fehlende Hefte als Kommaliste, „Anlegen und nächstes Objekt" behält Serie und Standort.

Danach: /bestand/{id}/edit ändert Zustand, Standort, Preise und Notizen; die Positionstabelle auf der Objektseite schaltet jedes Heft zwischen vorhanden, fehlt, Farbkopie, Nachdruck und Ersatzkopie um, entfernt Zeilen und trägt neue nach – alles in einem Formular. Vollständigkeit und Stückzahl rechnet refreshCounts() danach neu, außer bei Objekten mit einer nicht aufgelösten Sammelposition.

Beide Wege laufen durch den ComicBookAssembler, damit ein von Hand erfasstes Konvolut genauso aufgebaut ist wie ein importiertes – gleiche Regeln für Bereiche, gleiche Positionslogik. CatalogTransferService ist dadurch von 190 auf 117 Zeilen geschrumpft.

Konsolenbefehle

Alle Befehle laufen im Web-Container. Wegen der Anführungszeichen bei Werten mit Leerzeichen besser ddev exec php bin/console … als ddev console … (siehe SETUP.md).

Lebenszyklus eines importierten Eintrags

Ein CatalogEntry ist das Zwischenlager zwischen Liste und Bestand. Er wandert durch sechs Status (App\Enum\ImportStatus), und nur zwei Schritte legen Objekte an:

Datei ──app:import-catalog──▶ NEW / PARSED / NEEDS_REVIEW
                                   │
                    Liste /catalog │ prüfen und korrigieren
                                   ▼
        Knopf „freigeben“ oder app:approve-catalog-entries
                                   │
                                   ▼
                               APPROVED
                                   │
                    app:transfer-catalog-entries
                                   ▼
                        IMPORTED  ──▶ ComicBook im Bestand

Ein typischer Durchlauf für eine große Liste, Serie für Serie:

# 1. Einlesen, erst ohne zu schreiben
ddev exec php bin/console app:import-catalog var/imports/friedrich-aug-87.txt --dry-run --show-failures
ddev exec php bin/console app:import-catalog var/imports/friedrich-aug-87.txt

# 2. In /catalog die Zeilen mit Status „zu prüfen" durchgehen und korrigieren

# 3. Freigeben - entweder in der Liste („Alle auf dieser Seite freigeben")
#    oder auf der Konsole, gefiltert:
ddev exec php bin/console app:approve-catalog-entries --series="Micky Maus" --dry-run
ddev exec php bin/console app:approve-catalog-entries --series="Micky Maus" --limit=200

# 4. In den Bestand überführen
ddev exec php bin/console app:transfer-catalog-entries --series="Micky Maus" --dry-run
ddev exec php bin/console app:transfer-catalog-entries --series="Micky Maus"

app:approve-catalog-entries nimmt standardmäßig nur PARSED. NEEDS_REVIEW kommt nur mit --status=NEEDS_REVIEW dran, --status=alle deckt beides plus NEW ab. Ohne --dry-run fragt der Befehl vor dem Schreiben nach; --no-interaction überspringt das. Wird die Grenze ausgeschöpft, sagt der Befehl das und man ruft ihn erneut auf.

Die Preise stehen nach dem Import in der Buchwährung (EUR, Kurs aus APP_RATE_DM, Standard 1:1). Der Originalbetrag bleibt in rawText und der Umrechnungsvermerk in den Notizen – siehe „Import rechnet immer in Euro".

Modellentscheidungen der Bestandsseite

• ComicIssue ist bibliografisch, ComicBook physisch. Zwei Exemplare desselben Hefts sind zwei ComicBook-Zeilen, ohne Sonderlogik.
• Konvolute führen Positionen statt JSON. „Heft 12 fehlt" ist über ComicBookItem.status = MISSING abfragbar (findMissingBySeries()).
• Bereiche werden nur expandiert, wenn es eindeutig ist. „33-36" wird zu vier Positionen; „1-2" bleibt ein Einzelheft mit komplexer Nummer; „1-5000" bleibt eine Sammelposition mit Prüfhinweis. Grenze über --expand-limit.
• Aus Bereichen entstehen keine Heft-Stammdaten. Abgeleitete Positionen haben derivedFromRange = true und keine ComicIssue-Verknüpfung.
• Katalogpreise landen in PriceObservation, nicht in estimatedValue. Ohne Katalogdatum bleibt observedAt leer.
• DM-Vergleichswert 1:1. Der DM-Betrag bleibt unverändert als Beleg stehen; daneben steht ein abgeleiteter Vergleichswert in EUR (convertedAmount, conversionRate). Kurs über APP_RATE_DM (Standard 1.0). Das ist bewusst keine Währungsumrechnung – der amtliche Einführungskurs wäre 0.51129 (1 EUR = 1,95583 DM) und lässt sich jederzeit eintragen; danach app:recalculate-price-conversions.

Medien: public/media-export/

Ablage unter public/media-export/<serie>/<inventarnummer>/<zufallsname>.<ext>, der Originalname bleibt in der Datenbank. Dedupliziert über SHA-256 je Objekt, erlaubt sind JPG, PNG, WebP, HEIC, TIFF und PDF – SVG bewusst nicht, weil es Skripte enthalten kann und hier im Web-Root liegt.

Drei Punkte, die aus dieser Lage folgen:

1. Kein Zugriffsschutz. Wer die URL hat, sieht die Datei. Für eine interne Sammlung in Ordnung; falls die Anwendung je öffentlich erreichbar wird, ist das die Stelle, an der ein Media-Controller nachgerüstet werden müsste.
2. Deployment muss das Verzeichnis aussparen. Ein SFTP-Upload, der public/ spiegelt, löscht sonst die Sammlung. public/media-export/ gehört auf die Ausschlussliste des Deployments – bei der Release-Struktur aus der Spec also nach shared/ und von dort verknüpft oder gemountet.
3. Kein PHP im Verzeichnis. Eine .htaccess unterbindet Ausführung und Directory Listing (Apache). Unter nginx entspricht das einem location ^~ /media-export/ { } ohne fastcgi_pass.

app:check-media zeigt Dateien ohne Datensatz und Datensätze ohne Datei – löscht aber nichts von selbst.

Lagerwert und Wertübersicht

ComicBook und ComicBookItem haben jetzt stockValue + Währung, das Objekt zusätzlich stockValuedAt. Maßgeblich ist, in dieser Reihenfolge:

1. der am Objekt festgesetzte Lagerwert,
2. sonst die Summe der Positionswerte (für Konvolute mit unterschiedlich wertvollen Heften – erfassbar direkt in der Positionstabelle der Objektseite),
3. sonst der Einkaufspreis als Ersatzwert.

Die Quelle wird überall mit angezeigt, damit ein übernommener Einkaufspreis nicht wie eine Bewertung aussieht. Die Wertübersicht (/werte, auf der Startseite als Vue-Komponente) summiert je Serie Einkauf, Schätzwert, Katalogwert und Lagerwert in Euro. Leere Werte bleiben leer – „nicht erfasst" ist nicht „0,00". Beträge in einer Währung ohne Kurs werden gezählt und angezeigt, nicht stillschweigend weggelassen.

Hinweis: Die Reihenfolge ist eine Arbeitsregel für die Sammlung, keine Bewertungsregel im steuerlichen Sinn. Wird der Bestand bilanziert, legt das die Steuerberatung fest.

Verwaltung (Vue)

/verwaltung bearbeitet alle Entities über /api/admin/*. Welche Entities und Felder bearbeitbar sind, steht ausschließlich in src/Admin/EntityRegistry.php – Beleg-Felder (Inventarnummer, Rohtext, Katalogbetrag) sind readonly, neue Felder erscheinen im Editor ohne Frontend-Änderung. Gespeichert wird nur, was sich geändert hat (PATCH mit den geänderten Feldern).

Sicherheit: /verwaltung verlangt wie alles außer /login ein Konto (security.yaml, siehe „Anmeldung"). Schreibende API-Aufrufe brauchen zusätzlich das CSRF-Token, damit sie nicht von einer fremden Seite ausgelöst werden können.

Löschfolgen

Bevor der Editor einen Datensatz löscht, zeigt er, was das nach sich zieht - App\Admin\DeleteImpact liest dafür die Doctrine-Metadaten statt einer eigenen Liste, neue Entities und Beziehungen sind also ohne Zutun erfasst. Drei Fälle:

• wird mitgelöscht (Kaskade in der Datenbank oder cascade: remove / orphanRemoval im ORM) - z. B. die Positionen eines Objekts
• verliert den Verweis (SET NULL) - der Datensatz bleibt, z. B. ein Katalogeintrag, dessen Objekt gelöscht wird
• blockiert das Löschen (RESTRICT bzw. kein onDelete) - z. B. eine Serie mit Objekten im Bestand

GET /api/admin/{typ}/{id}/loeschfolgen liefert die Liste, der Editor zeigt sie beim Öffnen eines Datensatzes und nochmals in der Rückfrage vor dem Löschen; ist das Löschen blockiert, ist der Knopf deaktiviert. Das DELETE selbst prüft dieselbe Liste vorab noch einmal serverseitig - SQLite und mancher Webspace prüfen Fremdschlüssel nicht, ohne die Vorabprüfung bliebe dort ein Verweis ins Leere stehen.

Schnelleingabe: Zeilen direkt einfügen

Im Reiter „Katalogeinträge" gibt es „+ Zeilen eingeben": eine Serienzeile, darunter Heft Zustand Preis je Zeile, genau wie in den historischen Listen -

Sigurd/GB
72 1 8.00
77 3-4 N 4,00

Läuft durch dieselben Regeln wie der Datei-Import (CatalogParserService, CatalogLineInspector) und über denselben CatalogImporter: Eine Vorschau zeigt beim Tippen, was erkannt wird und was zur Prüfung geht, „Anlegen" speichert per Hash-Abgleich - wer denselben Block zweimal abschickt, bekommt „schon vorhanden" statt Dubletten. Für einzelne Objekte oder Katalogeinträge bleibt die Schnellerfassung in der Kopfzeile (+ Objekt, + Eintrag) der kürzere Weg.

Katalog-Import: Text und CSV

app:import-catalog liest jetzt zwei Formate; das Command selbst macht nur noch Ein- und Ausgabe:

Datei ─► CatalogReaderRegistry ─► TextCatalogReader | CsvCatalogReader
                                   └─► CatalogParseResult (formatunabhängig)
      ─► CatalogImporter ─► CatalogLineInspector (Prüfregeln) ─► CatalogEntry

ddev katalog var/imports/comic_collection_import_eur.csv --source "OCR-Liste 2026" --dry-run --show-review
ddev katalog var/imports/beispiel-katalog.txt --format txt

CSV-Spalten (Groß-/Kleinschreibung egal, Komma, Semikolon oder Tab): title|serie, issue|heft|nr, condition|zustand, source_price_dm|preis_dm, price_eur|preis_eur oder price + currency, optional stock|bestand, year_volume|jahrgang, ocr_uncertain, ocr_notes.

Regeln, die bewusst so sind:

• Der DM-Betrag ist das Original. Steht source_price_dm in der Datei, wird er mit DM gespeichert; der EUR-Wert der Tabelle (schon mit 1,95583 gerechnet) nur, wenn kein DM-Betrag da ist. Der Vergleichswert entsteht wie bisher über APP_RATE_DM.
• rawText ist die unveränderte CSV-Zeile, die Zeilennummer die physische Zeile der Datei.
• stock = Anzahl Einträge. Drei Exemplare ergeben drei Einträge und später drei Objekte. Exemplar 1 behält den bisherigen Hash, frühere Importe bleiben also erkannt.
• Micky Maus/70 wird zu Serie Micky Maus, Jahrgang 70 - wie beim Serienkopf im Textimport. Akim-NA/Pic bleibt ganz.
• OCR-Notizen werden nur übernommen, wenn sie aus Katalogkürzeln bestehen (N, S, oS, (B)). 68 oder gel bleiben unangetastet im Rohtext.

Prüfregeln (CatalogLineInspector, gleich für Text und CSV) - nichts wird verworfen, Auffälliges geht mit Grund in die Notizen und nach NEEDS_REVIEW:

Die Liste /catalog zeigt bei zu prüfenden Einträgen den Befund unter der Originalzeile. Mit der OCR-Liste vom September: 4.468 Zeilen, 601 zur Prüfung (499 OCR unsicher, 89 Serie unleserlich, 62 Zustand, 14 Heftnummer).

Der Parser zieht für eine fehlende Serie nichts mehr ab - das macht jetzt der Inspector, sonst würde doppelt abgezogen.

Katalog-PDF

/katalog-pdf verwaltet gespeicherte Zusammenstellungen. Gespeichert wird die Auswahl, nicht das PDF: Jeder Abruf erzeugt den Katalog aus dem aktuellen Bestand. Auswahl, Texte und Titelbild lassen sich im Baukasten auf der Startseite (Vue) pflegen; erzeugt wird weiter unter /katalog-pdf - Vorschau und Download laufen serverseitig und brauchen kein JavaScript.

• Auswahl: ganze Serien, einzelne Objekte und einzelne Katalogeinträge. Serien- und Objektauswahl wirken zusammen; alles leer bedeutet „der ganze Bestand". Für Serien gibt es Checkboxen mit Objektzahl, Suchfeld, „alle sichtbaren"/„keine", „leere ausblenden" - eine leere Auswahl bleibt vollständig, auch wenn später neue Serien dazukommen.
• Katalogeinträge kommen als eigener Angebotsteil hinter die Bestandslisten, mit Quelle und Vermerk „ungeprüft", wo der Eintrag noch nicht freigegeben ist.
• Titelblatt: Titel, Untertitel, Absender (mehrzeiliger Briefkopf wie bei den alten Listen), Stand (leer = Tag der Erzeugung), Einleitung, Titelbild, Zahlen, Zeichenerklärung.
• Einleitung über einen kleinen HTML-Editor (RichTextEditor.js): Fett, Kursiv, Unterstrichen, zwei Überschriftenstufen, Absatz, Zitat, zwei Listenarten, Link. Eingefügter Text kommt immer als reiner Text an - eingefügtes HTML aus Word oder einer Webseite brächte sonst fremde Schriften, Farben und Tabellen mit. Gespeichert wird serverseitig bereinigt (App\Text\IntroductionHtml): Nur die genannten Tags bleiben stehen, <script>, Ereignis-Attribute (onclick …) und javascript:-Links fallen weg, echte http(s)- und mailto-Links bleiben erhalten. Alte Einleitungen aus reinem Text werden weiter als Absätze gesetzt, das Editor-Feld bleibt ohne JavaScript ein normales Textfeld.
• Titelbild als JPG, PNG oder PDF, wahlweise ganzseitig auf einer eigenen Seite vor dem Titelblatt (nur JPG/PNG - ein PDF-Titelblatt steht ohnehin auf eigenen Seiten). Ein PDF-Titelbild wird nicht eingebettet, sondern dem Katalog vorangestellt - ein fertig gestaltetes Titelblatt bleibt damit exakt erhalten. Dafür braucht es setasign/fpdi; fehlt das Paket, wird der Katalog ohne Titelblatt ausgeliefert und die Oberfläche sagt warum. JPG/PNG liegen unter public/media-export/_katalog-pdf/<id>/, werden beim Hochladen (mit ext-gd) nach EXIF gedreht und auf 2000 px verkleinert und kommen als data:-URI ins PDF - Dompdf braucht damit weder Netzwerk noch Dateizugriff außerhalb des Projekts. app:check-media kennt diese Dateien.
• Optionen: A4/A5, Preise (Lagerwert nach StockValueResolver), Zustand, Inventarnummern, fehlende Hefte bei Konvoluten, Legende, Übersichtsseite (listet vor den Tabellen jeden Abschnitt mit Objekt-, Heft- und Betragszahlen, Bestand und Katalogeinträge getrennt).
• Abschnitte je Serie und Jahrgang (Micky Maus/69 und /70 getrennt), Hefte nach issueSortKey, Summe je Serie und Gesamtsumme. Läuft eine Serie über den Seitenumbruch, steht ihr Name oben auf der neuen Seite noch einmal.
• Aktionen: PDF ansehen, herunterladen, HTML-Vorschau, als Kopie speichern, löschen. Löschen entfernt Zusammenstellung und Titelbild, nie den Bestand.

Dompdf (reines PHP, passt zum SFTP-Deployment). Schrift ist Courier als PDF-Grundschrift: nichts wird eingebettet, Umlaute gehen. Gemessen mit 4.468 Zeilen in 262 Abschnitten: 97 Seiten A4, rund 22 s, 370 MB Spitze, 440 KB Datei. Der Renderer hebt memory_limit bei Bedarf auf 768 MB und das Zeitlimit auf 300 s. Für den Gesamtkatalog ist die Konsole bequemer:

ddev console app:catalog-pdf                       # Liste mit Ids
ddev console app:catalog-pdf <id> -o var/katalog.pdf

Import rechnet immer in Euro

Beim Import wird jeder Preis in die Buchwährung umgerechnet und als EUR gespeichert. So lassen sich Einträge sortieren, filtern und summieren, ohne bei jeder Abfrage einen Kurs anzuwenden. Verloren geht dabei nichts: die Katalogzeile steht unverändert in rawText, und in der Notiz steht ein Vermerk wie „Originalpreis 25,00 DM, übernommen als 25,00 EUR (Kurs 1:1)".

Der Kurs kommt weiter aus APP_RATE_DM (Standard 1:1 – eine Vergleichskonvention, keine amtliche Umrechnung; amtlich wäre 0.51129). Eine Währung ohne hinterlegten Kurs wird nicht umgerechnet: der Betrag bleibt stehen und der Eintrag landet als NEEDS_REVIEW in der Prüfliste, statt eine Zahl zu erfinden.

Noch offen

Person (Zeichner, Texter, Übersetzer) fehlt noch, ebenso eine serienübergreifende Suche und der CSV-/JSON-Export aus der MVP-Liste. Katalogdateien lassen sich noch nicht über die Weboberfläche hochladen - der CatalogImporter ist dafür vorbereitet. Im Katalog-PDF fehlt ein Inhaltsverzeichnis mit Seitenzahlen (Dompdf kennt die Seiten erst nach dem Umbruch).