E-Commerce-Entwicklung: pluginfinance.com

#Eine Produktseite, die eigentlich ein Datenblatt ist

pluginfinance.com präsentiert und vertreibt Plugins für den Finanzsektor. Die Umsetzung begann 2012, umfasste auch die visuelle Identität, und die erste Fassung entstand in etwa sechs Wochen. Die Plattform wurde seither gepflegt und modernisiert, weshalb sie heute auf PHP 8 und MySQL 8 läuft, mit WordPress als Inhalts- und Handelsschicht und einem React-Frontend, das über REST und GraphQL mit ihr spricht.

Der Ausgangspunkt war nicht das Layout, sondern die Art der Ware. Ein Finanz-Plugin wird nach Parametern gekauft, nicht nach einem Produktfoto. Der Käufer will wissen, mit welchen WordPress- und PHP-Versionen das Produkt zusammenarbeitet, welche externen Abhängigkeiten es mitbringt, ob es in einer mehrsprachigen Installation funktioniert, was genau mit Zahlungsdaten geschieht und wie der Supportweg nach dem Kauf aussieht. Nichts davon gehört in einen Fließtext, denn alles davon muss filterbar und vergleichbar sein.

Produkte werden deshalb über eigene Inhaltstypen und Zusatzfelder auf Basis von Advanced Custom Fields beschrieben. Ein technischer Parameter ist ein Feld, kein Satz. Der offensichtliche Gewinn ist das Filtern und Sortieren. Der weniger offensichtliche zeigt sich in der Pflege: Erscheint eine neue Hauptversion von WordPress, ist die Aktualisierung der Kompatibilität für den gesamten Katalog eine Operation auf einem Feld und nicht das Durchlesen mehrerer Dutzend Beschreibungen auf der Suche nach dem Satz mit der Versionsangabe. Ein Katalog, der Kompatibilität in Prosa führt, lügt nach zwei Jahren bei der Hälfte seiner Einträge, und niemand bemerkt es.

Vergleichstabellen hängen von dieser Disziplin stärker ab als von allem anderen. Wer Finanzwerkzeuge bewertet, engt üblicherweise auf zwei oder drei Kandidaten ein und will sie nebeneinander sehen, Merkmal gegen Merkmal. Ein Vergleich ist nur so gut wie die Vollständigkeit der Felder: Ist bei der Hälfte der Produkte das Kompatibilitätsfeld leer, führt die Tabelle wirksamer in die Irre, als sie hilft. Die vergleichsrelevanten Felder sind daher bei der Veröffentlichung Pflicht und nicht optional. Das ist eine redaktionelle Regel, technisch erzwungen, und die einzige, die einen Vergleich nach zwei Jahren Produktzuwachs sinnvoll hält.

An dieser Stelle steht in Fallstudien meist eine Ergebnistabelle. Hier steht keine: Verkaufszahlen gehören dem Kunden und nicht einem Portfolio-Eintrag auf unserer Seite. Erzählbar sind die Entscheidungen und ihre Folgen.

#Der Verkauf ist der Anfang der Beziehung

Den Handel trägt WooCommerce, erweitert um Abonnements und Lizenzen. Genau hier liegt der schwierigste Teil des Projekts, denn im Moment des Kaufs beginnt die Arbeit des Shops, statt zu enden.

Der nach der Zahlung erzeugte Lizenzschlüssel ist nur der Auftakt. Die Installation des Kunden fragt den Dienst nach verfügbaren Aktualisierungen, der Shop ist also gleichzeitig Update-Server. Das bedeutet, dass Anfragen nicht nur von Menschen mit Browser kommen, sondern von Hunderten WordPress-Installationen, die im Hintergrund nach eigenem Zeitplan prüfen, unabhängig vom Besucherverkehr. Dieser Verkehr ist in der Besucherstatistik unsichtbar und in der Serverlast sehr sichtbar, wenn ihn niemand eingeplant hat.

Die Lösung trennt beide Welten. Der Endpunkt, der Lizenz und Version prüft, antwortet so knapp wie möglich, liest aus Redis und startet nicht den vollständigen Seitenaufbau. Die Update-Datei selbst wird von der Edge ausgeliefert, denn sie ist eine statische Datei und kein Ergebnis einer Datenbankabfrage. Die Trennung von Rechteprüfung und Dateiauslieferung ist der Kern: Die Prüfung muss günstig und exakt sein, die Übertragung ist teuer und gehört so weit wie möglich weg von der Anwendung.

Darunter liegt eine Regel, die juristisch klingt und in Code endet. Eine abgelaufene Lizenz darf ein installiertes Plugin nicht abschalten. Der Kunde hat für Software bezahlt, die weiterhin funktioniert; der Ablauf entzieht das Recht auf Updates und Support, nicht das Nutzungsrecht. Lizenzstatus und Funktionsstatus müssen deshalb zwei unabhängige Werte sein. Wer sie vermengt, hinterlässt bei der ersten verspäteten Verlängerung ein abgeschaltetes Modul im Produktivbetrieb des Kunden und eine Störung, die der Shop verursacht hat.

#Steuerregeln, die bis in den Warenkorb reichen

Jeder Shop, der digitale Waren über eine Grenze verkauft, stößt auf eine Anforderung, die keine nachgelagerte Buchhaltungsaufgabe ist, sondern eine Bedingung im Kaufprozess. Eine elektronische Leistung an einen Verbraucher in einem anderen EU-Land wird mit dem Satz des Bestimmungslandes besteuert, und der Verkauf an ein Unternehmen mit gültiger Umsatzsteuer-Identifikationsnummer wird anders abgerechnet als der Verkauf an eine Privatperson. Der Shop muss den Status des Käufers also feststellen, bevor er einen Endpreis zeigen kann, die Nummer im Register prüfen und Nachweise über den Ort des Käufers aufbewahren.

Das reicht in den Warenkorb und in die Rechnungsvorlage hinein. Es berührt außerdem das Caching auf eine Weise, die viele überrascht: Ein Preis, der vom Land des Besuchers abhängt, lässt sich nicht in eine für alle zwischengespeicherte Seite einbacken. Im Katalog erscheinen die Preise deshalb in einer definierten Grundform, und der länderabhängige Endbetrag entsteht im Warenkorb, wo die Anfrage ohnehin vom Edge-Cache ausgeschlossen ist.

#Headless und die ehrlichen Kosten dieser Entscheidung

Die Oberfläche ist eine Anwendung im Browser, WordPress liefert Inhalte und Handelslogik im Hintergrund. Diese Entscheidung hatte hier eine konkrete Begründung, und wir empfehlen sie nicht reflexhaft für jeden Shop.

Die Begründung ist das mehrdimensionale Filtern. Käufer engen den Katalog nach Integrationsart, Versionskompatibilität, Lizenzmodell und weiteren Merkmalen ein und ändern dabei mehrfach ihre Auswahl. Im klassischen Modell ist jede Filteränderung ein Seitenneuaufbau samt vollständigem Rendern auf dem Server. Bei einem Katalog mit vielen Merkmalen bedeutet das über ein Dutzend Datenbankabfragen pro Klick auf ein Auswahlfeld. Ein getrenntes Frontend holt hier nur die Ergebnisliste und nicht die ganze Ansicht.

Die Kosten sind real und gehören genannt. Im Browser erzeugte Inhalte können für Crawler schwerer sichtbar sein, weshalb die Seiten, die Suchverkehr bringen sollen, also Produktseiten und redaktionelle Beiträge, serverseitig gerendert und als fertiges HTML ausgeliefert werden. Nur die Katalogbedienung ist clientseitig. Die zweite Kostenstelle ist die API-Schicht selbst, die als weitere Grenze gepflegt und abgesichert werden muss. GraphQL löst einen Teil des Problems, weil eine Abfrage genau die Felder holt, die eine Ansicht braucht, statt drei REST-Aufrufen mit jeweils zu vielen Daten. Dafür verlangt GraphQL eine sorgfältige Begrenzung der Abfragekomplexität: Ein öffentlicher Endpunkt ohne Tiefenbegrenzung ist eine Einladung, den Server mit einer einzigen Anfrage zu erschöpfen.

#Wo der Edge-Cache aufhören muss

Redis trägt Objektcache und Sitzungen, Cloudflare steht an der Edge, dazu kommt serverseitiges Seiten-Caching. Drei Ebenen klingen nach Übermaß, bis man aufschreibt, welche Art von Anfrage wo landet.

Ein Shop teilt seinen Verkehr in zwei ungleiche Hälften. Katalogseiten und redaktionelle Inhalte sind für alle Besucher identisch, lassen sich also von der Edge ausliefern und berühren PHP nie. Warenkorb, Kundenkonto, Bestellhistorie und die Liste der Lizenzschlüssel sind persönlich und dürfen nirgendwo zwischengespeichert werden außer im Browser ihres Eigentümers. Die Grenze zwischen beiden Welten ist die häufigste Ursache schwerer Fehler in Onlineshops: ein falsch gesetzter Header, und die Edge liefert den Warenkorb eines Kunden an einen anderen aus.

Die Regel ist deshalb absolut und nicht Gegenstand von Optimierung: Das Vorhandensein eines Sitzungs-Cookies schließt eine Anfrage vom Edge-Cache aus, ohne Ausnahme. Das kostet bei angemeldeten Kunden Geschwindigkeit, und dieser Preis wird bewusst bezahlt, denn die Alternative ist der Abfluss von Bestelldaten. Sitzungsabhängige Fragmente wie der Warenkorbzähler im Kopfbereich werden nach dem Laden der Seite über eine eigene Anfrage nachgeholt, wodurch das Seitengerüst für alle gleich und weiterhin cachefähig bleibt.

Redis verkürzt, was in PHP übrig bleibt. In einem Shop mit vielen Produktmerkmalen entstehen die höchsten Kosten durch Metadatenabfragen, weil die Datenbank bei jedem Filtervorgang Produkte mit ihren Eigenschaften verknüpfen muss. Diese Ergebnisse liegen zusammen mit Merkmalslisten und Kategoriestruktur im Objektcache und werden bei einer Produktänderung invalidiert, nicht nach Ablauf einer Frist.

#Sicherheit bei einem Produkt im Finanzumfeld

Eine Seite, die Werkzeuge für den Finanzsektor verkauft, ist aus zwei Gründen gleichzeitig ein attraktives Ziel: Sie verarbeitet Zahlungen und sie verteilt Code, den Kunden auf ihren eigenen Seiten installieren. Das Zweite wiegt schwerer, denn eine kompromittierte Update-Datei verbreitet sich automatisch auf alle Installationen.

Daraus ergibt sich die Reihenfolge der Maßnahmen. Zahlungen laufen nicht über die Seite, sondern über den Zahlungsdienstleister, Kartendaten erreichen den eigenen Server also nie, und der Shop speichert lediglich eine Transaktionskennung. Release-Dateien sind signiert und werden erst nach der Lizenzprüfung ausgeliefert, und der Zugang zum Veröffentlichungsbereich ist von der normalen Inhaltsverwaltung getrennt. Sicherheit entsteht im Code und in der Serverkonfiguration, nicht durch ein weiteres Schutz-Plugin. Ein solches Plugin läuft innerhalb von PHP, also erst nachdem die Anfrage die Anwendung bereits gestartet hat, es belastet jede Anfrage und wird regelmäßig selbst zur Schwachstelle.

Hinzu kommt eine Datenschutzebene, die sich in einem Shop mit Lizenzschlüsseln nicht umgehen lässt. Ein Kundenkonto verbindet eine E-Mail-Adresse mit der Liste der Domains, auf denen die Lizenzen laufen, also mit Informationen über die Infrastruktur dieses Unternehmens. Das sind keine besonderen Kategorien personenbezogener Daten, aber ein Abfluss hat für den Kunden reale Folgen, weil er einem Angreifer zeigt, welches Werkzeug auf welcher Seite steht. Der Zugriff auf diese Liste ist auf API-Ebene ebenso beschränkt wie der Zugriff auf Bestelldaten, und die Protokolle speichern bewusst verkürzte Kennungen statt vollständiger Lizenzschlüssel.

#Leistung, Überwachung und Wartung

Die Wartung beginnt in einem Softwareshop an einer Stelle, die gewöhnlicher Handel nicht kennt. Jede WordPress-Aktualisierung auf Shopseite muss mit der Kompatibilität abgeglichen werden, die die verkauften Produkte angeben. Ein Shop, der selbst auf der neuesten Version läuft und Plugins als kompatibel mit einer zwei Jahre alten Version anbietet, entwertet seinen eigenen Katalog, bevor ein Kunde die erste Zeile gelesen hat. Der Abgleich gehört deshalb in den Aktualisierungsvorgang und ist keine getrennte redaktionelle Aufgabe. Dazu kommt das Übliche: Aktualisierungen von Kern, Theme und Erweiterungen, die Durchsicht der Protokolle und Sicherungen mit geprobter Wiederherstellung. Und die funktionalen Änderungen, die aus der Weiterentwicklung des Angebots folgen und sich nicht im Voraus planen lassen.

Getestet wird gegen eine Produktionskopie, nie gegen eine leere Installation, und der Grund ist hier wörtlicher als sonst. Eine leere Installation hat keine einzige aktive Lizenz. Die gesamte Logik aus Verlängerung, Ablauf und Versionsprüfung findet also nichts vor, woran sie laufen könnte, und jeder Test besteht, weil er nichts zu tun hat. Ein echter Lizenzbestand verhält sich anders: abgelaufene Einträge, mitten in der Laufzeit verlängerte Einträge, Lizenzen, die ein Kunde ohne Ankündigung auf eine andere Domain umgezogen hat. Erst diese Mischung zeigt, ob sich die Regeln so verhalten, wie es die Verkaufsbedingungen beschreiben.

Bei der Leistung liegt der teure Punkt nicht auf der Startseite, sondern am Lizenzendpunkt, den Hunderte Kundeninstallationen nach eigenem Zeitplan abfragen, nachts ebenso wie mittags. Dieser Verkehr taucht in keiner Besucherstatistik auf und dafür vollständig in der Serverlast. Er bekommt deshalb eine eigene Alarmierung, unabhängig von der allgemeinen Verfügbarkeitsüberwachung, denn ein stummer Endpunkt kostet keine Abschlüsse, sondern löst in derselben Minute Hunderte Update-Fehler bei Kunden aus und füllt den Support mit Meldungen über eine Störung, die beim Kunden gar nicht stattgefunden hat. Alles davor ist normale Frontend-Arbeit: kompilierte Ressourcen, geteilte Pakete, bedarfsweise geladener Code, beim Hochladen statt bei jeder Anzeige verarbeitete Bilder und statische Dateien über Cloudflare, was bei internationaler Kundschaft die größte Einzelersparnis bleibt.

#Zusammenfassung

WordPress trägt Softwarevertrieb, sofern man es als Inhalts- und Handelsschicht behandelt und nicht als die gesamte Anwendung. Außerhalb gehört das, was harte zeitliche oder sicherheitsbezogene Bedingungen hat, hier also zwei Dinge: die Lizenzprüfung und die Dateiauslieferung. Der Rest, also Katalog, versionierte Dokumentation, redaktionelles Material und Kasse, liegt dort, wo ein Redaktionssystem stark ist. Übertragbar sind vier Entscheidungen: strukturierte Produktdaten statt Fließtext, die Trennung von Nutzungsrecht und Aktualisierungsrecht, eine ausdrückliche Grenze um das Zwischenspeicherbare und die Trennung von Lizenzprüfung und Auslieferung.

Nicht übertragbar sind das Inhaltsmodell dieses Katalogs und seine Lizenzregeln, denn sie entstanden für ein Angebot und ein Regelwerk. Ein Anbieter, der dauerhafte Nutzung und befristeten Support getrennt verkauft, braucht vom ersten Feld an eine andere Form. Die nächste Umsetzung beginnt deshalb mit einer Frage statt mit einer Vorlage: was der Kunde genau kauft und für wie lange.