Ein Katalog, den PrestaShop nicht modellieren konnte.
Ein Schlaf- und Wellness-Musiklabel betreibt einen hybriden Katalog: digitales Audio — Schlafklanglandschaften, Meditationssessions, Originalkompositionen — neben physischen Medien und Marken-Zubehör. Das Kundenerlebnis steht und fällt mit einer Interaktion: Kann ich genug von diesem Track hören, um eine Kaufentscheidung zu treffen, ihn dann zusammen mit der Vinyl-Pressung in den Warenkorb legen und in einem Ablauf bezahlen?
Das Standard-PrestaShop 1.7 modellierte nichts davon. Es kannte Produkte und Preise. Es kannte keine Audio-Tracks mit konfigurierbaren Sample-Cutoffs. Es kannte keine Komponisten und Sprecher als erstklassige Inhaltsentitäten. Es wusste nicht, dass das Marketing-Team die Startseite an einem Dienstag neu anordnen musste, ohne einen Code-Editor zu öffnen.
Das Briefing war direkt: Baut die E-Commerce-Oberfläche, die zu diesem Geschäft passt, nicht das Geschäft, das zur Plattform passt.
Fünf Module, die PrestaShop in der Domäne sprachfertig machten.
Wir erweiterten PrestaShop 1.7.4 — PHP 5.6, Symfony 3.4, Doctrine, MySQL, Smarty — um fünf maßgefertigte Module, ein eigenes Theme und markenkonforme PDF-Rechnungsvorlagen. Keines der Module stammte aus dem Marketplace. Alle fünf wurden von Grund auf geschrieben, um der spezifischen Form der Domäne zu entsprechen.
Das Music-Player-Modul gab jedem digitalen Produkt eine abspielbare Identität: Track-Metadaten, volle Dauer, eine pro Track vom Künstler festgelegte konfigurierbare Sample-Cutoff-Zeit und einen scrubbaren In-Page-Player. Der Künstler entscheidet, wie viel vor dem Checkout abgespielt wird. Diese Entscheidung ist eine Geschäftsregel; sie lebt im Datenmodell, nicht in JavaScript-Hacks gegen das Standard-Produkttemplate.
Das Autorenprofil-Modul machte Komponisten und Sprecher zu erstklassigen Entitäten mit eigenen Profilseiten, Biografien und Diskografien. Ein Track kennt seinen Autor. Eine Autorenseite listet seine Tracks. Die Beziehung ist abfragbar und aus dem Admin-Panel verwaltbar.
Das Startseiten-Builder-Modul gab dem Marketing-Team eine strukturierte Oberfläche — Header-Blöcke, Banner, CTAs — die es bearbeiten konnte, ohne das Theme anzufassen. Das Produktblock-Modul übernahm kuratierte Startseiten-Schaufenster nach Kategorie. Das Bedingungen-Modul gab der Rechtsabteilung eine Selbstbedienungsoberfläche für die AGB-Verwaltung. Kombiniert mit dem One-Page-Flow von SuperCheckout und der regionalen CM-CIC-Zahlungsintegration erfasste der Checkout die E-Mail-Adresse am Point of Sale und verrechnete über den regionalen Zahlungsabwickler des Kunden, ohne ein eigenes Zahlungs-Gateway.
Benutzerdefinierte PDF-Rechnungsvorlagen — 877 Zeilen, markenkonform — wickelten Belege serverseitig ab. Der Kunde erhält einen Beleg, der wie die Marke aussieht, bei der er gerade gekauft hat.
- F · 01Music-Player-Modul
- Track-Metadaten, Dauer, konfigurierbare Sample-Cutoff-Zeit und ein scrubbarer In-Page-Player. Der Künstler legt fest, wie viel vor dem Checkout abgespielt wird; diese Regel lebt im Datenmodell.
- F · 02Autorenprofil-Modul
- Komponisten und Sprecher als erstklassige Admin-Entitäten mit Profilseiten, Biografien und Diskografien. Tracks verweisen auf Autoren; Autorenseiten listen Tracks.
- F · 03Startseiten-Builder-Modul
- Strukturierte Header-Blöcke, Banner und CTAs, die das Marketing-Team aus dem Admin-Panel bearbeitet — kein Theme-Zugriff, kein Ingenieur in Bereitschaft.
- F · 04Produktblock-Modul
- Kuratierte Produkt-Schaufenster auf der Startseite, organisiert nach Kategorie. Der Betreiber entscheidet, was auf der Startseite erscheint, ohne das Template anzufassen.
- F · 05One-Page-Checkout + regionale Zahlung
- Der Single-Page-Flow von SuperCheckout mit regionaler CM-CIC-Zahlungsabwicklung und Mailchimp-E-Mail-Erfassung am Point of Sale. Digitales und Physisches in einem Warenkorb, einem Checkout.
- F · 06Markenkonforme PDF-Rechnungen
- Serverseitige Rechnungserzeugung — 877 Zeilen benutzerdefinierter Vorlagen. Belege, die wie die Marke aussehen, bei der der Kunde gerade gekauft hat.
Die Plattform erweitern; sie nicht neu schreiben.
Die Versuchung bei einem Projekt wie diesem ist, zu dem Schluss zu kommen, dass die Plattform falsch ist, und von vorn zu beginnen. PrestaShop weiß nicht, was ein Vorschau-Cutoff ist — also wechselt man zu einer eigenen Symfony-Anwendung, greift zu einem Headless-Stack, argumentiert für eine ganz andere Plattform.
Nichts davon war gerechtfertigt. Das Modulsystem von PrestaShop existiert genau dafür. Die Plattform übernimmt Katalogverwaltung, Auftragsabwicklung, Inventar, Steuern, Mehrwährung und ein Jahrzehnt von E-Commerce-Sonderfällen, die nicht interessant neu zu schreiben sind. Die Lücke war die Domänenmodellierung — Audio-Metadaten, Autorenentitäten, eine bearbeitbare Startseite — und diese Lücke hatte genau die richtige Größe für fünf Module.
Erweitere eine Plattform nur dort, wo ihr Vokabular falsch ist. Überall, wo es stimmt, lass sie die Arbeit machen.
Vier Monate, November 2018 bis März 2019, 356 Commits. Der Erweiterungsumfang wurde daran kalibriert, was die Plattform bereits gut beherrschte. Die Module sind isoliert und sauber abgegrenzt. Der Rest ist PrestaShop. Dieser Zwang ist ebenso sehr eine Disziplin wie eine Entscheidung: Wenn man nur dort erweitert, wo die Passung wirklich falsch ist, bleibt das System, das der nächste Ingenieur erbt, weiterhin lesbar.
Eine Plattform, die die Sprache der Marke sprach.
Der Storefront ging mit einem Katalog live, den der Betreiber verwalten konnte, einem Checkout, der Digitales und Physisches in einem Ablauf abwickelte, und einer Startseite, die das Marketing-Team ohne Support-Ticket bearbeiten konnte.
Die Plattform wusste, was ein Audio-Track ist. Sie wusste, was ein Autor ist. Sie wusste, dass ein Sample für ein konfigurierbares Zeitfenster abspielte und dann eine Kaufentscheidung verlangte. Das sind keine Funktionen, die an die Seite eines generischen Storefronts geschraubt wurden — sie sind das Domänenmodell, ausgedrückt im Code und im Admin-Panel sichtbar gemacht.
356 Commits, 4 Monate, 5 benutzerdefinierte Module. Der Betreiber ging termingerecht live und verwaltete den Katalog vom ersten Tag an ohne Engineering-Unterstützung.
Endlich fühlte es sich an wie unser Store, nicht wie ein PrestaShop-Store mit unserem Logo darauf.