Wahlplakat-Shop.de – individuelle E-Commerce-Entwicklung für komplexe Druckprodukte

Ein Kunde kommt mit 1.000 Plakaten, drei Motiven und einer Deadline vier Wochen vor der Wahl. Ein anderer bestellt für zwölf Ortsverbände gleichzeitig, jeder mit eigener Rechnungsadresse, eigenem Liefertermin, eigenen Mengen. Ein dritter lädt eine Druckdatei hoch, die technisch nicht passt, und merkt es erst, wenn es fast zu spät ist.

Für Wahlplakat-Shop.de haben wir ein B2B-Bestellsystem für Wahlkampf- und Druckprodukte entwickelt – von Parteien über Wählergemeinschaften bis zu einzelnen Kandidatinnen und Kandidaten. Kein Shop von der Stange, sondern eine individuell entwickelte PHP-Anwendung, die genau auf diese Art von Bestellung zugeschnitten ist: komplex, terminkritisch, mit echten Konsequenzen, wenn etwas nicht funktioniert.

Warum ein Standard-Shop hier nicht ausgereicht hätte

Die naheliegende Frage zuerst: Warum kein WooCommerce, kein Shopware, kein Standardsystem mit ein paar Anpassungen?

Weil die Anforderungen an Stellen kollidieren, an denen Standard-Shops nicht für gebaut sind. Ein Plakat ist kein Lagerartikel mit fester SKU – es hat ein Format, ein Material, eventuell eine Bohrung für die Befestigung, eine produktabhängige Lieferzeit und einen Preis, der sich aus Auflage, Motivanzahl und Staffelstufe zusammensetzt. Ein Kunde bestellt nicht "ein Produkt", sondern konfiguriert eine Kombination aus mehreren Variablen, die sich gegenseitig beeinflussen.

Dazu kommen Prozesse, die es in einem klassischen Onlineshop schlicht nicht gibt: eine Mehrmotiv-Logik innerhalb einer einzelnen Bestellung, ein Druckdaten-Workflow mit Prüfung vor Produktion, eine Lieferantensteuerung, die nur die jeweils relevanten Positionen an den richtigen Lieferanten weitergibt, und eine Rechnungsanbindung, die mit Angeboten, Organisationen und Sammelbestellungen umgehen kann. Jede dieser Anforderungen einzeln wäre mit Plugins lösbar. Zusammen ergeben sie ein System, das man entweder mühsam gegen ein bestehendes Shopgerüst zusammenbaut – oder von Grund auf für genau diesen Zweck entwickelt.

Wir haben uns für Letzteres entschieden: eine eigene Anwendung auf PHP 8.4 mit MariaDB und Redis, gehostet bei Hetzner, ohne Shop-Framework als Unterbau.

Komplexe Druckprodukte statt einfacher Artikel

Jedes Produkt im System trägt deutlich mehr Information als ein Name, ein Preis und ein Lagerbestand. Format, Material, Bohrungsoptionen und Varianten sind eigene Datenstrukturen, keine Freitextfelder. Das hat einen konkreten Grund: Nur so lassen sich Lieferzeiten, Mehrwertsteuersätze und Mengenschritte pro Produkt unterschiedlich hinterlegen, ohne dass im Frontend Sonderfälle einzeln abgefangen werden müssen.

Ein Beispiel, das im Wahlkampfgeschäft häufiger vorkommt, als man denkt: Zwei Produkte sehen im Shop fast identisch aus – gleiches Format, ähnliches Material –, haben aber unterschiedliche Lieferzeiten, weil eines im eigenen Bestand liegt und das andere produktionsabhängig ist. Diese Information muss im Preis, in der Lieferzeitanzeige und in der späteren Bestellabwicklung konsistent auftauchen. Sie wird an einer Stelle im Backend gepflegt und fließt von dort in jede Ansicht, in der sie relevant ist – nicht an fünf Stellen einzeln eingetragen und irgendwann inkonsistent.

Auch die Mengenlogik ist produktspezifisch: manche Artikel lassen sich nur in festen Schritten bestellen, andere frei nach Auflage. Beides musste im selben System sauber nebeneinander funktionieren, ohne dass ein Sonderfall den anderen bricht.

Eine eigene Preis- und Staffelpreislogik

Der Preis, den ein Kunde am Ende sieht, ist das Ergebnis mehrerer Rechenschritte, die im Hintergrund zusammenlaufen: Netto-Einkaufspreis, produktspezifischer Aufschlag, Staffelstufe je nach Auflage, und – sobald mehrere Motive im Spiel sind – ein Zusatzpreis ab dem zweiten Motiv. Diese Rechnung läuft intern mit sechsstelliger Präzision, damit sich Rundungsfehler nicht über mehrere Stufen aufsummieren, und wird erst am Ende korrekt auf den Endpreis gerundet.

Der Grund für diesen Aufwand ist unspektakulär, aber wichtig: Der günstigste "ab"-Preis auf einer Produktübersicht muss exakt aus derselben Logik stammen wie der Preis, der später im Warenkorb erscheint. Genauso müssen Preisfilter und Preissortierung dieselbe zentrale Berechnung nutzen wie die Detailseite. Zwei getrennte Preisberechnungen – eine fürs Anzeigen, eine fürs Bestellen – klingen nach einer Abkürzung, sind in der Praxis aber die häufigste Ursache für Support-Anfragen der Art "warum stimmt der Preis nicht", die wir von Anfang an vermeiden wollten.

Mehrere Motive innerhalb einer Bestellung

Die Mehrmotiv-Logik ist eine der Besonderheiten, die im Wahlkampfgeschäft immer wieder gebraucht wird, in Standard-Shops aber praktisch nie vorgesehen ist: Eine Partei bestellt 1.000 Plakate, verteilt auf drei unterschiedliche Motive – etwa für verschiedene Kandidatinnen und Kandidaten oder Themenschwerpunkte.

Der Ablauf: Der Kunde wählt zunächst, wie viele Motive er benötigt. Das System verteilt die Gesamtauflage automatisch möglichst gleichmäßig – bei 1.000 Stück auf drei Motive etwa 334 / 333 / 333. Diese Verteilung ist ein Vorschlag, keine feste Vorgabe: Der Kunde kann die Mengen anschließend manuell anpassen, etwa wenn ein Motiv in einer Region mit höherer Bevölkerungsdichte hängen soll.

Damit daraus keine fehleranfällige Excel-Tabelle im Kopf des Kunden wird, prüft das System bei jeder Anpassung mehrere Dinge gleichzeitig: dass die Summe der Einzelmengen wieder der Gesamtauflage entspricht, dass Mindestmengen und Mengenschritte pro Motiv eingehalten werden, und dass der korrekte Zusatzpreis ab dem zweiten Motiv in die Kalkulation einfließt. Jedes Motiv wird als eigene Position im Warenkorb und in der späteren Bestellung geführt.

Druckdaten als eigener digitaler Workflow

Sobald die Bestellung steht, beginnt der Teil, der in vielen anderen Shops komplett fehlt: die Druckdatenverwaltung. Kunden laden ihre Dateien per Drag & Drop hoch, ordnen sie dem jeweiligen Motiv zu und erhalten eine Vorschau – für PDF ebenso wie für Bilddateien. Unterstützt werden PDF, JPG/JPEG, TIF/TIFF und EPS.

Vor der Produktion durchlaufen die Dateien eine technische Prüfung. Produkte können unterschiedliche DPI-Anforderungen hinterlegt haben – ein großformatiges Plakat verzeiht andere Auflösungen als ein kleines Faltblatt –, und das System prüft entsprechend produktabhängig, nicht pauschal. Fällt eine Datei durch, landet die Bestellung nicht einfach in der Produktion, sondern bekommt einen Korrekturstatus: Der Kunde wird informiert, bevor Zeit und Material in eine Datei investiert werden, die ohnehin nicht drucktauglich gewesen wäre.

Ein Punkt, der uns beim Aufbau besonders wichtig war: Druckdaten sind sensible Dateien – teils mit Kandidatenfotos, teils mit noch nicht veröffentlichten Kampagnenmotiven vor dem eigentlichen Wahlkampfstart. Sie liegen deshalb in einer geschützten Speicherstruktur, nicht einfach über einen öffentlich erratbaren Pfad erreichbar.

Vom Kundenauftrag bis zum Lieferanten

Ein Bestellvorgang endet nicht mit der Zahlung, sondern beginnt dort erst richtig. Kunden können als Gast bestellen oder ein Konto anlegen, einzeln oder als Teil einer Organisation mit mehreren Mitgliedern – relevant etwa für Ortsverbände, die zentral über einen Zugang für mehrere Personen bestellen. Rechnungs- und Lieferadresse sind dabei bewusst getrennt geführt, weil Rechnungsstelle und Auslieferungsort im Vereins- und Parteiumfeld selten identisch sind.

Aus einer Bestellung wird im Hintergrund automatisch aufgeteilt, was an welchen Lieferanten geht. Jeder Lieferant sieht ausschließlich seine eigenen Positionen: Produktdaten, Mengen, Motivaufteilung, Links zu den freigegebenen Druckdaten und die Lieferadresse des Kunden – keine Einsicht in andere Lieferanten, keine Einsicht in Preise, die nichts mit seiner Position zu tun haben. Der Versand erfolgt neutral direkt an den Endkunden, ergänzt um einen ebenfalls neutralen Lieferschein als PDF.

Bei gemischten Warenkörben – manche Produkte versandkostenfrei, andere nicht – berechnet das System die Versandkosten ausschließlich für die tatsächlich versandpflichtigen Artikel, nicht pauschal über den gesamten Warenkorb.

Ein Backend für echte tägliche Arbeit

Ein Shop dieser Komplexität lebt oder stirbt an seinem Backend. Wer täglich zwanzig Produkte mit Staffelpreisen pflegt, merkt sehr schnell, ob ein System für echte Arbeit gebaut wurde oder nur für eine Produktvorführung.

Deshalb lassen sich Produkte duplizieren, statt sie jedes Mal neu anzulegen, Preisstaffeln direkt inline bearbeiten und als Batch speichern, statt jede Stufe einzeln zu öffnen. Wer viele Produkte auf einmal pflegen muss, kann per CSV oder XLSX importieren. Preisänderungen zeigen sich live in der Kalkulation, bevor sie gespeichert werden. Bilder lassen sich per Drag & Drop hochladen, Produkttexte über einen Rich-Text-Editor pflegen, SEO-, GEO- und AEO-Felder sowie strukturierte FAQ-Einträge direkt am Produkt.

Das Backend deckt darüber hinaus die komplette Organisationsstruktur ab: Kunden, Organisationen, Bestellungen, Angebote, Lieferanten, Druckdaten-Freigaben, Statistiken und Systemeinstellungen bis hin zu Wartungsmodus und Indexierungssteuerung – an einer Stelle, nicht verteilt über mehrere Tools.

Schnittstellen zu Lexware Office und PayPal

Bestellungen, die nicht in die Buchhaltung finden, sind für ein Unternehmen wertlos, egal wie gut der Shop davor funktioniert. Die Anbindung an Lexware Office überträgt Rechnungen als Entwurf, ebenso Angebote, Kontakte und Artikel – als Entwurf deshalb, damit vor der endgültigen Buchung noch eine Kontrolle stattfinden kann. Ein Idempotenz- und Dublettenschutz verhindert, dass dieselbe Bestellung bei einer erneuten Übertragung ein zweites Mal in der Buchhaltung landet. Die Zugangsdaten selbst liegen zu keinem Zeitpunkt im Klartext vor.

Für die Zahlungsabwicklung ist PayPal angebunden, mit sauberer Trennung zwischen Sandbox- und Live-Umgebung. Auch hier greifen Idempotenzschutz sowie eine Prüfung von Betrag und Währung, bevor eine Zahlung als abgeschlossen gilt. Die Zugangsdaten werden verschlüsselt gespeichert.

SEO, GEO und AEO von Beginn an berücksichtigt

Sichtbarkeit in klassischen Suchmaschinen war ein Ziel, aber nicht das einzige. Immer mehr Anfragen laufen heute über generative Systeme, die Inhalte nicht nur crawlen, sondern strukturiert verstehen müssen, um sie in einer Antwort zusammenzufassen. Deshalb wurde von Anfang an mitgedacht, wie Produktinformationen sowohl für klassisches SEO als auch für GEO (Generative Engine Optimization) und AEO (Answer Engine Optimization) aufbereitet werden.

Konkret bedeutet das: strukturierte Daten nach Schema.org für Produkte, Angebote, Breadcrumbs und Produkt-FAQs, sauber gepflegte Meta-Titel und -Beschreibungen, Canonical-Tags, Open-Graph-Daten, eine aktuelle Sitemap, eine korrekt gepflegte robots.txt – und ergänzend eine llms.txt, die KI-Systemen eine strukturierte Zusammenfassung des Angebots bereitstellt.

Sicherheit und Betrieb

Ein System, das Zahlungen, personenbezogene Daten und zum Teil politisch sensible Kampagnenmaterialien verarbeitet, verträgt keine Sicherheitslücken, die man "später nachrüstet". Deshalb war Sicherheit von der ersten Architekturentscheidung an Teil der Planung.

Der Login läuft mehrstufig: E-Mail und Passwort, ergänzt um einen Einmalcode per E-Mail. Dazu kommen Rate Limiting gegen automatisierte Anmeldeversuche, CSRF-Schutz, Prüfungen gegen unautorisierten Zugriff auf fremde Datensätze, sichere Session-Verwaltung, rollenbasierte Backend-Rechte sowie Datei-Uploads, die nach tatsächlichem Dateityp geprüft werden, nicht nur nach Dateiendung. API-Zugangsdaten liegen verschlüsselt vor, Druckdaten sind nicht über öffentlich erratbare Pfade erreichbar.

Im laufenden Betrieb sorgen Redis und OPcache für Geschwindigkeit unter Last, ergänzt um Worker- und Queue-Prozesse. Heartbeats überwachen den Systemzustand, tägliche Backups sichern den Datenbestand – gehostet bei Hetzner, betrieben mit PHP 8.4 und MariaDB.

Das Ergebnis

Aus einer Anforderung, die mit einem Standard-Shop nur mit Kompromissen umsetzbar gewesen wäre, ist ein System entstanden, das die tatsächlichen Abläufe im Wahlkampf- und Druckgeschäft abbildet, statt sie an ein bestehendes Shopgerüst anzupassen: individuelle Preislogik, Mehrmotiv-Bestellungen, ein eigener Druckdaten-Workflow, saubere Lieferantensteuerung und eine Buchhaltungsanbindung, die im Alltag tatsächlich entlastet.

Für uns war Wahlplakat-Shop.de ein Projekt, das zeigt, wofür wir als Full-Service-Partner stehen: von der Konzeption über die Backend-Architektur bis zur Anbindung externer Systeme aus einer Hand entwickelt – nicht, weil "individuelle Softwareentwicklung" gut klingt, sondern weil die Anforderungen es an mehreren Stellen schlicht erforderten.