Verbesserungen und Anpassungen in Commerce 2.x

In einem zweiten Blogpost werden wir detailliert beschreiben, auf welche Herausforderungen wir in unserem ersten E-Commerce-Projekt in Drupal 8 gestossen sind.

Einige der grundlegenden APIs wurden als generische API-Bibliotheken gebaut, die auch ausserhalb von Drupal verwendet werden können. Dies ermöglicht es den CommerceGuys, auch mit anderen eCommerce-Systemen zusammenzuarbeiten, die nicht zum Drupal-Ökosystem gehören.

Die Verwendung von Composer ist deshalb eine Voraussetzung für die Wartung von Commerce-Websites. Das funktioniert einwandfrei und sollte für erfahrene Entwickler kein grosses Problem darstellen. Vor allem für solche, die Erfahrung mit anderen PHP-Frameworks oder -Sprachen haben, bei denen ein Paket-Manager üblich ist. Für weniger erfahrene Benutzer und manche Hosting-Anbieter kann es allerdings ein Problem sein. Platform.sh, der Hosting-Provider, den wir für dieses Projekt verwenden, unterstützt Projekte, die Composer nutzen.

Im Gegensatz zu Commerce 1.x, das nur wenige Features beinhaltete und eine Menge an Site-Building und Anpassungen erforderte, ist Commerce 2.x ist näher an Commerce Kickstart als an einer einfachen Commerce 1.x Installation. Es enthält eine Reihe von anderen Modulen wie Inline Entity Form, um die UX zu verbessern sowie viele Features, die zuvor zusätzliche Module benötigten. Beispielsweise für das Abspeichern und Wiederverwenden von Zahlungsmethoden, Warenlager/Marktplatz und vieles mehr.

Das macht es viel einfacher, ein neues Commerce-Projekt zu starten. Vor allem, wenn es zu einer bestehenden Drupal-Website hinzugefügt wird oder einige Installationsprofile erstellt werden.

Statt Nodes, die auf Produkte verweisen, bietet Commerce jetzt standardmässig zwei Entitätstypen, Produkte und Produktvariationen, die eine ähnliche Funktionalität mit einer wesentlich besseren UX haben. Zahlungsmethoden in 1.x (z.B. Stripe oder PayPal) werden nun als Zahlungs-Gateways bezeichnet und eine Zahlungsmethode ist eine bestimmte Art, wie ein Nutzer bezahlt, beispielsweise eine spezifische Kreditkarte.

Es dauert ein bisschen, um sich daran zu gewöhnen, aber die neue Terminologie macht Sinn und sollte neuen Entwicklern den Einstieg in Commerce erleichtern.

Commerce 2.x hat eine klare Vorstellung, wie ein Shop und der Checkout-Prozess aussehen und funktionieren sollte. Es bietet weniger Konfigurationseinstellungen und Optionen, da die Vergangenheit gezeigt hat, dass weniger erfahrene Benutzer ihre Installationen oft durch falsche Einstellungen zerstören. Gleichzeitig vereinfacht die erwähnte Flexibilität Anpassungen durch Entwickler. Ein Beispiel ist die Bestätigungsnachricht nach Abschluss des Zahlungsvorgangs. In 1.x ist dies eine Konfigurationseinstellung. Wir haben aber noch nie eine Commerce-Website gebaut, bei der es ausreichte, nur diesen Text zu ändern. In 2.x ist es ein Twig-Template, das bereits viel mehr Flexibilität bietet, um eine schön gestaltete Bestätigungsseite implementieren zu können. Beim Bestätigungsmail ist es dasselbe: Es wird aus einem Twig-Template erstellt und sieht standardmässig schon gut aus.

Fast alles in Commerce ist ein Plugin und es kann mehrere Varianten von allem geben. Dazu gehört beispielsweise der Checkout-Workflow. Davon kann es mehrere Varianten geben und jede verwendet jeweils ein Plugin. Jeder beliebige Inhalt kann als "käuflich" markiert werden, wenn dies entsprechend implementiert wird. Zudem ist möglich, den Checkout-Prozess ohne ein ausgewähltes Produkt zu durchlaufen. Viele UI-Komponenten sind als wiederverwendbare Formularelemente vorhanden.

Unsere bisherige Erkenntnis ist, dass Commerce 2.x eine gute Balance gefunden hat zwischen einem starken Out-of-the-Box-Shop, guter Zahlungsabwicklung und grosser Flexibilität sowie Editierbarkeit für Entwickler.

Verpassen Sie nicht den zweiten Teil dieser Blog-Serie! Wir werden ausführlich über unsere Erfahrungen mit Drupal Commerce 2.x in einem Kundenprojekt informieren.