Shopware-6-Plugins nach Maß entwickeln

Plugins nach Maß entwickeln heißt bei Shopware nicht, den Kern anzufassen: Shopware bringt eine offene Plugin-Schnittstelle mit, über die sich fast jede Funktion ergänzen lässt. Entscheidend ist, wie ein Plugin gebaut ist: Es soll das nächste Shopware-Update überstehen, die Storefront nicht ausbremsen, einer Sicherheitsprüfung standhalten und sich in zwei Jahren von jemand anderem erweitern lassen. Genau darauf ist die Arbeitsweise hier ausgelegt: mit den offiziellen Erweiterungspunkten von Shopware statt Eingriffen in den Kern und mit einer Dokumentation, die auch ein fremder Entwickler versteht.

In der Plugin-Entwicklung für Shopware 6 wiederholen sich vier Aufgabentypen, meist in Kombination. Der erste sind eigene Datenentitäten für Informationen, die Shopware von Haus aus nicht kennt: etwa Filialen mit eigenen Beständen, Öffnungszeiten und Zuordnung zum Sortiment. Der zweite sind Eingriffe in die Ausgabe der Storefront, damit diese Informationen dort ankommen, wo gekauft wird, zum Beispiel als Bestandsanzeige je Filiale auf der Produktseite oder als Staffelpreis, der sich während des Einkaufs berechnet. Der dritte sind Anbindungen an Systeme außerhalb des Shops: an die Warenwirtschaft (ERP), an ein Produktdaten-System (PIM), an die Logistik oder an Marktplätze, auf denen zusätzlich verkauft wird, meist über deren API. Der vierte ist eigene Logik im Bestellprozess, von Freigaben im B2B-Einkauf bis zur Betrugserkennung mit Sperrlisten, die auffällige Bestellungen aufhält, bevor sie in die Warenwirtschaft laufen. Shopware 6 ist seit dem Release 2019 im Einsatz; aus mehr als 20 Projekten sind sowohl die offiziellen Erweiterungspunkte vertraut als auch die Stellen, an denen es in der Praxis regelmäßig klemmt. Dieselben vier Aufgaben gab es davor schon in Magento, dort hießen sie nur Module statt Plugins: Filialbestände, Marktplatz-Anbindungen und Prüflogik im Bestellprozess sind seit 2008 wiederkehrende Themen, unabhängig vom Shopsystem.

Überall dort, wo ein Plugin Einstellungen mitbringt, gehört eine Bedienoberfläche im Backend dazu. Sie ist der Teil, der im Alltag zählt: Ohne sie müsste das interne Team jede Änderung direkt in der Datenbank vornehmen. Die Shopware-Administration ist mit Vue.js gebaut, dem Oberflächen-Framework, das Shopware auch für das eigene Backend nutzt, und bringt eine Bibliothek fertiger Bausteine mit. Die werden hier ebenfalls verwendet, damit sich die Konfiguration anfühlt wie der Rest des Backends und nicht wie ein Fremdkörper. Dazu kommen geprüfte Eingaben, verständliche Hilfetexte an den Feldern und sinnvolle Standardwerte. Dieser Teil ist kein Nebenprodukt der Funktion, sondern eigener Aufwand, und er steht deshalb auch in der Aufwandsschätzung als eigener Posten. Läuft ein Plugin dagegen vollständig im Hintergrund, etwa ein nächtlicher Abgleich mit der Warenwirtschaft, entfällt er.

Zum Lieferumfang gehört immer der vollständige Quelltext, abgelegt im Git-Repository des Auftraggebers oder, wo es keines gibt, als fertiges Paket zum Einspielen. Dazu kommt eine Installations- und Konfigurations-Doku, die auch ein anderer Entwickler ohne Rückfragen nutzen kann. Die Nutzungsrechte am erstellten Code liegen beim Auftraggeber. Automatisierte Tests mit PHPUnit für die tragenden Funktionen kommen auf Wunsch dazu; sie kosten zusätzliche Zeit, zahlen sich aber bei jedem späteren Shopware-Update aus. Eine Veröffentlichung im Shopware Store ist ein eigener Auftrag: Shopware prüft eingereichte Erweiterungen vor der Freigabe, und dazu kommen Store-Texte, Bilder, Versionspflege und Support für fremde Shops, in denen das Plugin später läuft.

Ein großer Teil der Plugin-Aufträge kommt von Agenturen, die für ein Kundenprojekt kurzfristig Backend-Kapazität brauchen: Die Agentur bleibt Hauptansprechpartner ihres Kunden, die Zusammenarbeit läuft diskret im Hintergrund, mit Verschwiegenheitsvereinbarung und ohne eigene Kennzeichnung am Ergebnis. Genauso läuft die Arbeit direkt mit Shop-Betreibern oder über IT-Vermittler. In allen drei Fällen gilt: standardmäßig zu 100 % remote und damit ortsunabhängig. Code und Dokumentation gehen über Git, die Abstimmung über Mail, Slack, Teams oder kurze Video-Calls, je nachdem was im Team ohnehin genutzt wird. Gearbeitet wird aus dem eigenen Büro im kontorworx-Coworking-Space in Rheine, persönliche Termine vor Ort sind nach Absprache möglich.