Vor gut zwei Jahren habe ich schon \u00fcber unsere ersten Erfahrungen mit Drupal Commerce berichtet, und schon damals hat sich das E-Commerce Framework f\u00fcr Drupal 7 als unglaublich m\u00e4chtiges Werkzeug erwiesen. Doch mit der Zeit kommen neue Projekte und Herausforderungen, die bestehende Werkzeuge auf die Probe stellen. Jetzt kann ich mit Gewissheit sagen dass ich vor zwei Jahren nur an der Spitze des Eisbergs vorbeigeschrammt bin.<\/p>\n

Gestiegene Anforderungen<\/h2>\n

Im letzten Jahr durften wir uns in Sachen E-Commerce an etwas Neuem versuchen. In den meisten F\u00e4llen enth\u00e4lt ein Webshop nur die ersten Schritte im Verkaufsprozess weltlicher G\u00fcter. Im Falle von\u00a0Garden Gnome Software<\/a>, einem Projekt, an dem wir letztes Jahr gearbeitet haben, ging es jedoch um den Vertrieb von digitalen G\u00fctern, konkret Softwarelizenzen. Kein Mitarbeiter der Bestellungen entgegen nimmt und diese durchf\u00fchrt. Der komplette Prozess, von der Produktpr\u00e4sentation bis zur Lieferung wird komplett vom Shopsystem \u00fcbernommen.<\/p>\n

Drupal Commerce erweitern<\/h2>\n

Zugegeben, Drupal Commerce kann das nicht\u00a0out of the box<\/em>. Aber Dank der soliden Basis aus\u00a0Views<\/a>\u00a0und\u00a0Rules<\/a>\u00a0ist es bekannter Ma\u00dfen keine Schwierigkeit die Funktionalit\u00e4t zu erweitern.<\/p>\n

Die grundlegende API von Rules ist genauso einfach wie m\u00e4chtig. Eigene\u00a0Conditions<\/em>\u00a0und\u00a0Actions<\/em>\u00a0sind einfach zu realisieren (siehe\u00a0Dokumentation<\/a>). Die Lizenzen, die von Kunden gekauft werden, wurden als eigene\u00a0Entity Typen umgesetzt<\/a>. Dank der\u00a0Entity API<\/a>\u00a0sind diese automatisch mit Rules kompatibel und k\u00f6nnen problemlos im Kaufprozess von Drupal Commerce generiert oder ver\u00e4ndert werden.<\/p>\n

Praktische Zusatzmodule f\u00fcr Rules, die zum Einsatz kamen sind\u00a0Conditional Rules<\/a>\u00a0und das\u00a0Rules Bonus Pack<\/a>. Ersteres erm\u00f6glicht konditionale Verzweigungen innerhalb der Aktionen einer Regel. Prinzipiell ist das auch immer mithilfe von\u00a0Rules Components<\/em>\u00a0l\u00f6sbar. In einigen F\u00e4llen, wo der verzweigte Pfad nur aus wenigen Aktionen besteht und auch nicht anderwertig wiederverwendet wird, bekommt man mehr \u00dcbersichtlichkeit f\u00fcr weniger Konfigurationsaufwand. Das\u00a0Rules Bonus Pack<\/a>\u00a0stellt eigentlich ein experimentelles Modul f\u00fcr potentielle Features von Rules dar, wird nie in einem stabilen Zustand verf\u00fcgbar sein und ist dementsprechend mit Vorsicht zu genie\u00dfen. Features wie das laden von Entities aus einer View und die Integration mit Panels kann aber Gold wert sein.<\/p>\n

Produktvarianten und konfigurierbare Produkte<\/h2>\n

In meinem\u00a0letzten Beitrag zum Thema Drupal Commerce<\/a>\u00a0habe ich die gedankliche H\u00fcrde erw\u00e4hnt, vor der man steht, wenn man andere Shopsysteme gewohnt ist. Zur Erinnerung: Ein T-Shirt in drei verschiedenen Farben und vier verschiedenen Gr\u00f6\u00dfen ist kein konfigurierbares Produkt sondern ein Aggregation von 12 Produkten die im selben Produkt Display dargestellt werden. Was f\u00fcr diesen Fall Sinn macht, da diese auch verschiedene SKU-Nummern, Preise und Lagerbest\u00e4nde haben k\u00f6nnen.<\/p>\n

Das bedeutet aber nicht, dass der umgekehrte Weg unm\u00f6glich ist. Im Fall von\u00a0Garden Gnome Software<\/a>\u00a0sind die vertriebenen Produkte Lizenzen. Diese k\u00f6nnen erstens in beliebiger Menge bestellt werden und haben zus\u00e4tzlich eine variable Anzahl der inkludierten\u00a0Seats<\/em>, also Arbeitspl\u00e4tze f\u00fcr die diese genutzt werden d\u00fcrfen. Es macht jedoch keinen Sinn, f\u00fcr jede m\u00f6gliche Seat-Menge eine eigene Produktvariante zu erstellen.<\/p>\n

Die L\u00f6sung ist nicht allzu kompliziert:\u00a0Line Items<\/em>\u00a0stellen in Drupal Commerce einzelne Zeilen einer Bestellung dar. Also zum Beispiel\u00a0„3 rote Shirts in Gr\u00f6\u00dfe L“<\/em>.\u00a0Line Items<\/em>\u00a0sind aber gleichzeitg Entities, und wie Nodes oder Produkte mit weiteren Feldern best\u00fcckbar. Also wurde kurzerhand neben dem bereits eingebauten Feld f\u00fcr die Bestellmenge auch noch eine\u00a0Seats<\/em>-Menge eingef\u00fchrt. Der darin enthaltene Wert hat nat\u00fcrlich Auswirkung auf den entg\u00fcltigen Preis, was sich aber mit\u00a0Product Pricing Rules<\/a>\u00a0sehr einfach l\u00f6sen l\u00e4sst.<\/p>\n

Spannender war es, die Menge der Seats im Warenkorb ver\u00e4ndern zu k\u00f6nnen. Da der Commerce Warenkorb auch nichts anderes als eine View – beziehungsweise eine Form View – darstellt, muss dazu ein\u00a0Views Field Handler<\/a>\u00a0implementieren der ein Formularfeld hinzuf\u00fcgt werden. Wie das funktioniert l\u00e4sst sich am Beispiel des\u00a0Views Handlers f\u00fcr die Bestellmenge<\/a>\u00a0erlernen.<\/p>\n

Kaufabschluss und Auslieferung<\/h2>\n

Ein Punkt den man in seiner Komplexit\u00e4t leicht untersch\u00e4tzt ist der automatische Abschluss einer Bestellung. Sobald die Bezahlung eingeht, wird die Bestellung in den Status\u00a0completed<\/em>\u00a0versetzt und die gekauften Lizenzen werden generiert. Klingt einfach, ist es aber nicht. Einige wichtige Punkte auf die man achten sollte:<\/p>\n

Drupal Commerce schlie\u00dft eine Bestellung (aus gutem Grund)\u00a0nicht<\/strong>\u00a0automatisch ab,wenn diese vollst\u00e4ndig bezahlt wurde. Es existiert jedoch ein Event namens\u00a0„When an order is first paid in full“<\/em>, welches ausgel\u00f6st wird sobald die Order Balance\u00a00<\/em>\u00a0erreicht.<\/p>\n

Wann<\/strong>\u00a0die Order Balance\u00a00<\/em>\u00a0erreicht ist je nach Payment Provider jedoch zum Teil nicht kalkulierbar. Wir hatten F\u00e4lle, in denen\u00a0Paypal<\/a>\u00a0erst Stunden sp\u00e4ter das Clearing bekannt gab und gleichzeitig solche, in denen die Order schon voll bezahlt war, bevor der Benutzer \u00fcberhaupt den Kaufprozess ganz abgeschlossen hatte. Letzterer Fall f\u00fchrt vor allem zu Problemen, da Commerce Accounts f\u00fcr anonyme Kunden erst bei vollst\u00e4ndigem Bestellabschluss generiert. Das macht Sinn, da man die eigene Datenbank nicht mit Benutzeraccounts von abgebrochenen Bestellungen bef\u00fcllen m\u00f6chte. Es f\u00fchrt jedoch zu Problemen wenn man sich darauf verl\u00e4sst, dass bei Transaktionsabschluss auch schon eine User-ID existiert der man eine neu erstellte Lizenz zuweisen m\u00f6chte.<\/p>\n

Versucht man das Problem direkt mit aufw\u00e4ndigen Rules Conditions zu erschlagen, l\u00e4uft man recht schnell Gefahr in einem Sumpf von Race Conditions zu versinken. Ich w\u00fcrde raten stattdessen die Weiterverarbeitung gleich im\u00a0Rules Scheduler<\/a>\u00a0abzuwickeln, was eine weitaus stabilere und einfachere L\u00f6sung darstellt.<\/p>\n

Fazit<\/h2>\n

Drupal Commerce hat wieder einmal eindrucksvoll bewiesen dass es wohl das flexibelste E-Commerce Framework auf dem Markt darstellt. So viel Flexibilit\u00e4t erfordert nat\u00fcrlich auch ein wenig Know How um sie einzusetzen, sich dieses anzueignen zahlt sich aber aus. Und die\u00a0Roadmap von Commerce 2.0<\/a>\u00a0l\u00e4sst zusammen mit\u00a0Drupal 8<\/a>\u00a0auf wirklich Gro\u00dfes hoffen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Vor gut zwei Jahren habe ich schon \u00fcber unsere ersten Erfahrungen mit Drupal Commerce berichtet, und schon damals hat sich das E-Commerce Framework f\u00fcr Drupal 7 als unglaublich m\u00e4chtiges Werkzeug erwiesen. Doch mit der Zeit kommen neue Projekte und Herausforderungen, die bestehende Werkzeuge auf die Probe stellen. Jetzt kann ich mit Gewissheit sagen dass ich […]<\/p>\n","protected":false},"author":12,"featured_media":1386,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[78,82,87],"tags":[],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts\/1385"}],"collection":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/users\/12"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/comments?post=1385"}],"version-history":[{"count":1,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts\/1385\/revisions"}],"predecessor-version":[{"id":1387,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/posts\/1385\/revisions\/1387"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/media\/1386"}],"wp:attachment":[{"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/media?parent=1385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/categories?post=1385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zensations.at\/wp-json\/wp\/v2\/tags?post=1385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}