Shopware 6 Certified Developer Training bei Shopware

Am 21. August 2019 war ich für das Shopware 6 Developer Training bei Shopware in Schöppingen. Es ging um die Entwicklerseite von Shopware 6, also um Architektur, Datenmodell und das Plugin-System der damals noch jungen Version 6.

Warum ein Training und nicht die Dokumentation

Bei einer neuen Version liegt der Gedanke nahe, sich alles selbst anzulesen. Bei Shopware 6 spricht etwas dagegen: Die Version ist kein Nachfolger im üblichen Sinn, sondern ein Neubau. Wer aus Shopware 5 kommt, kann wenig übertragen. Das Template arbeitet nicht mehr mit Smarty, der Datenzugriff folgt einem eigenen Konzept, und die Administration ist eine eigenständige Anwendung.

In so einer Lage ist die Dokumentation zwangsläufig im Rückstand, weil die Software sich schneller bewegt, als sie beschrieben wird. Ein Training bei den Leuten, die den Code schreiben, schließt genau diese Lücke: Man erfährt nicht nur, wie etwas geht, sondern warum es so gebaut wurde. Das zweite ist beim Debuggen später mehr wert.

Jeder Platz mit vorbereiteter Entwicklungsumgebung, der praktische Teil beginnt früh.

Themen des Trainings

• Aufbau und Architektur von Shopware 6 auf Basis von Symfony
• Der Data Abstraction Layer (DAL) als zentraler Zugriff auf das Datenmodell
• Eigene Entitäten und Datenbank-Migrationen
• Das Plugin-System: Struktur, Services und Dependency Injection
• Erweiterungen für die Administration und die Storefront
• Zusammenspiel von Backend-Logik und API

Der Data Abstraction Layer

Der DAL war für mich der wichtigste Teil des Tages. Shopware 6 greift nicht über ein verbreitetes ORM auf die Datenbank zu, sondern über eine eigene Schicht, die Entitäten, Beziehungen und Felder in Definitionsklassen beschreibt. Abfragen laufen über Criteria-Objekte, die Filter, Sortierung und Nachladen von Beziehungen zusammenfassen.

Das ist zunächst gewöhnungsbedürftig, wenn man aus einer anderen Welt kommt. Es hat aber einen Grund: Weil jede Entität formal beschrieben ist, kann Shopware daraus die API ableiten, Erweiterungen fremder Plugins an bestehende Entitäten hängen und Berechtigungen an einer Stelle prüfen. Wer den DAL umgeht und direkt SQL schreibt, verliert genau diese Eigenschaften und merkt es meist erst, wenn ein anderes Plugin dazukommt.

Aus der Übung: Zugriff über Repository und Criteria statt über SQL, dazu eine eigene API-Route im Plugin.

Plugins als eigenständige Pakete

Der zweite Schwerpunkt lag auf dem Plugin-System, das bis heute die Grundlage jeder Plugin-Entwicklung bildet. Ein Plugin ist in Shopware 6 ein eigenes Paket mit klarer Struktur, das seine Dienste über Dependency Injection registriert, statt sich in bestehenden Code einzuklinken. Erweiterungen greifen über Events und Decorator-Muster ein.

Das macht Plugins besser verträglich untereinander, verlangt aber mehr Disziplin beim Entwurf. Die Frage ist nicht mehr, wo man am schnellsten eingreift, sondern welche Schnittstelle für den gewünschten Eingriff vorgesehen ist. Diese Umstellung im Kopf ist der eigentliche Aufwand beim Wechsel von Shopware 5.

Zwei Welten im Backend

Ein Punkt, der beim Umstieg regelmäßig unterschätzt wird: Die Administration wechselt das Framework. Shopware 5 setzte im Backend auf ExtJS, ein kommerzielles JavaScript-Framework von Sencha mit eigener Klassenhierarchie und eigener Komponentenwelt. Es begleitete Shopware lange, schon die erste Community Edition von 2010 hatte es an Bord. Im PHP-Umfeld blieb es trotzdem stets ein Fremdkörper, den man nur lernte, weil ein bestimmtes Projekt es verlangte. Shopware 6 nutzt an dieser Stelle Vue.

Für die Praxis heißt das zweierlei. Bestehende Backend-Erweiterungen lassen sich nicht übertragen, sie werden neu geschrieben. Und die Suche nach Verstärkung wird leichter: ExtJS-Erfahrung fand man fast nur bei Leuten, die ohnehin in diesem Umfeld arbeiteten, Vue kann praktisch jeder Frontend-Entwickler.

Was bleibt, ist die Zweiteilung der Arbeit. Ein Plugin mit eigener Verwaltungsmaske besteht aus zwei Hälften: der Logik im PHP-Kern und der Oberfläche in der Administration. Wer nur eine davon beherrscht, kommt genau dann an eine Grenze, wenn ein Kunde eine zusätzliche Einstellmöglichkeit im Backend möchte.

Pausen mit Palmen

Zum Gebäude gehört ein angelegter Strandbereich mit Sand, Palmen in Kübeln, Liegestühlen und einem Beachvolleyballfeld. In der Mittagspause im August ist das ein sehr angenehmer Ortswechsel, und es sagt nebenbei etwas über den Hersteller: Wer im Münsterland Entwickler halten will, konkurriert mit Köln, Hamburg und Berlin. Ein solcher Hof ist Teil der Antwort darauf.

Der Strandbereich von oben, dahinter Felder: Schöppingen ist kein Großstadtstandort.

Prüfung und Zertifizierung

Das Training selbst fand vor Ort statt. Die eigentliche Zertifizierungsprüfung habe ich erst später online abgelegt.

Die API als eigentliche Weichenstellung

Der Punkt, der über einzelne Techniken hinausgeht, ist die Rolle der Schnittstelle. In Shopware 6 ist die API kein Anbau, sondern der Weg, über den auch die mitgelieferte Verwaltungsoberfläche mit dem Kern spricht. Was die Administration kann, kann folglich jedes andere System auch.

Praktisch heißt das: Der Shop lässt sich betreiben, ohne die mitgelieferte Storefront zu benutzen. Kasse, Katalog und Kundenkonten bleiben, die Oberfläche davor kann etwas anderes sein, eine eigene Anwendung, eine App, ein Kassensystem im Ladengeschäft.

Für die Entscheidung, sich hier einzuarbeiten, war das für mich ausschlaggebender als jede einzelne Funktion. Ein System mit verbreiteten Werkzeugen im Unterbau und einer vollwertigen Schnittstelle nach außen lässt sich in mehr Richtungen einsetzen als eines, das nur seinen eigenen Weg kennt.

Einordnung

Für den Einstieg in die Shopware-6-Entwicklung war das Training eine solide Grundlage. Die Konzepte von damals, allen voran der Data Abstraction Layer und das Plugin-System, prägen die Arbeit an Shopware-6-Projekten bis heute.