{"id":1431,"date":"2012-01-09T17:38:20","date_gmt":"2012-01-09T17:38:20","guid":{"rendered":"https:\/\/www.zensations.at\/?p=1431"},"modified":"2023-08-09T01:31:35","modified_gmt":"2023-08-09T01:31:35","slug":"drupal-commerce-ein-erfahrungsbericht","status":"publish","type":"post","link":"https:\/\/www.zensations.at\/blog\/drupal-commerce-ein-erfahrungsbericht\/","title":{"rendered":"Drupal Commerce – ein Erfahrungsbericht"},"content":{"rendered":"
Dass\u00a0Drupal 7<\/a>\u00a0mit Leichtigkeit die Anforderungen von fast jedem webbasierten Projekt, von der einfachen Pr\u00e4sentationsseite \u00fcber komplexere Informationssysteme, bis hin zu ausgewachsenen Communities, erf\u00fcllt ist hinl\u00e4nglich bekannt. Aber wie steht es mit E-Commerce L\u00f6sungen? Ist der blaue Tropfen auch f\u00fcr Webshops geeignet? Ein kleiner Erfahrungsbericht soll hier Klarheit schaffen.<\/p>\n Lange Zeit galt\u00a0\u00dcbercart<\/a>\u00a0als Standard, wenn man auf einer Drupal Seite etwas verkaufen wollte. Alternativen waren praktisch nicht vorhanden und um ehrlich zu sein auch nicht notwendig. Die Lage \u00e4nderte sich aber mit dem Release von Drupal 7, welches eine F\u00fclle neuer und besserer Technologien wie Entities und Fields mit sich brachte. \u00dcbercart jedoch war sehr stark mit den Drupal 6 API’s und Modulen wie CCK verbunden, was eine einfache Portierung erheblich erschwerte. Stattdessen wurde das\u00a0Drupal Commerce<\/a>\u00a0Projekt ins Leben gerufen. Erkl\u00e4rtes Ziel war von Anfang an eine Drupal 7 basierte E-Commerce L\u00f6sung zur Verf\u00fcgung zu stellen, die auch die Vorteile der neuen API’s so gut wie m\u00f6glich nutzen sollte. Wir hatten das Vergn\u00fcgen anhand von\u00a0better b. good<\/a>\u00a0die Probe aufs Exempel zu machen. Und das Ergebnis kann sich sehen lassen.<\/p>\n An dieser Stelle ist ein kleiner Exkurs notwendig. Bei\u00a0better b. good<\/a>\u00a0handelt es sich um das Unternehmen der beiden bezaubernden Ober\u00f6sterreicherinnen Christine Schl\u00f6gl und Pamela Gl\u00fcck, die fest der Meinung sind, dass es jeder Frau m\u00f6glich sein sollte, Alltagsmode mit reinem Gewissen aus sozial und \u00f6kologisch vertretbaren Quellen zu beziehen, ohne sich gleich mit esoterischen Farbkombinationen und\u00a0„Hippie Chic“<\/em>\u00a0zu brandmarken. Aus den Begleitumst\u00e4nden ergaben sich folgende Anforderungen, denen der Webshop gerecht werden musste:<\/p>\n Eine Men\u00fcf\u00fchrung erwies sich nicht als notwendig, von daher wurde der Ansatz verfolgt, g\u00e4nzlich darauf zu verzichten und stattdessen alle Kernfunktionen direkt auf der Landingpage auf spielerische Weise integriert und mit handgezeichneten Figuren in Storytelling-Manier zum Leben erweckt. In diesem Schritt leisteten die Drupal 7 internen Ajax-Mechanismen und das Stylesheet-Framwork\u00a0Compass<\/a>\u00a0unsch\u00e4tzbare Dienste.<\/p>\n Beim ersten Kontakt mit Drupal Commerce bereitet vor allem eine Designentscheidung der Entwickler Kopfzerbrechen: Produkte sind nicht einfach nur einzelne Entities oder gar Nodes. Stattdessen wurden sie in die Produkte selbst und die sogenannten Product Displays aufgeteilt. Ein\u00a0Produkt<\/strong>\u00a0repr\u00e4sentiert tats\u00e4chlich einen einzelnen physischen Artikel mit eindeutiger Artikelnummer, zum Beispiel ein wei\u00dfes T-Shirt mit Rundhalsausschnitt in der gr\u00f6\u00dfe Medium.\u00a0Product Displays<\/strong>\u00a0hingegen sind einfach Nodes mit einen Feld vom Typ\u00a0Product Reference<\/em>, an welches beliebig viele Produkte angeh\u00e4ngt werden k\u00f6nnen. So k\u00f6nnen verschiedene Ausformungen eines Artikels seperat in Lager- und Buchhaltung gef\u00fchrt, aber f\u00fcr die Pr\u00e4sentation sehr einfach geb\u00fcndelt und zum Beispiel \u00fcber einen intuitiven Konfigurator zur Verf\u00fcgung gestellt werden.<\/p>\n Sowohl Produkte als auch Displays sind\u00a0fieldable Entities<\/em>\u00a0und k\u00f6nnen beliebig mit Feldern f\u00fcr Zusatzinformationen oder zum Beispiel Bilder versehen werden. Dadurch ergibt sich eine Flexibilit\u00e4t, die bei hochgradig spezialisierten Systemen wie\u00a0Magento<\/a>\u00a0schmerzlich vermisst wird. F\u00fcr die Funktionen zur Produktansicht- und Konfiguration auf\u00a0better b. good<\/a>\u00a0war beispielsweise keinerlei Anpassung der Programmlogik in PHP notwendig. Sie konnten durch simple Konfiguration der vorhandenen Mechanismen bereitgestellt werden.<\/p>\n Erw\u00e4hnenswert ist jedoch das externe Modul\u00a0Commerce Bulk Product Creation<\/a>, welches dabei hilft schnell und automatisiert alle Permutationen einer Produktkategorie (zum Beispiel schwarze und wei\u00dfe Shirts in f\u00fcnf Gr\u00f6\u00dfen und zwei Arml\u00e4ngen) zu erstellen. Gleich zu wissen, dass das Modul existiert, kann sehr viel Zeit ersparen.<\/p>\n Im ersten Schritt bietet das Modul\u00a0Commerce Shipping<\/a>\u00a0vor allem die M\u00f6glichkeit, im Bezahlprozess separate Rechnungs- und Lieferadressen abzufragen. Damit ist es aber noch nicht getan. Mithilfe von Rules (welche in verschiedensten Bereichen von Commerce Verwendung finden) ist es m\u00f6glich, beliebig komplexe Regeln f\u00fcr Versandkosten zu konfigurieren. Zwar geschieht dies rein \u00fcber das Administrationsinterface, aufgrund der Komplexit\u00e4t der Sache an sich ist aber ein nicht unerhebliches technisches Verst\u00e4ndnis notwendig.<\/p>\n Steuern funktionieren in Drupal Commerce nach dem gleichen Prinzip wie Versandkosten und lassen in Sachen Flexibilit\u00e4t keinerlei W\u00fcnsche offen.<\/p>\n Den letzten, aber vermutlich wichtigsten, Schritt stellte, die Integration der Bezahloptionen dar. F\u00fcr viele der gr\u00f6\u00dferen Payment-Provider sind bereits Module f\u00fcr Drupal Commerce verf\u00fcgbar. Im Falle von\u00a0better b. good<\/a>\u00a0fiel die Wahl auf\u00a0Novalnet<\/a>\u00a0und\u00a0Sofort\u00fcberweisung.de<\/a>, wo leider auf keine vorhandenen Module zur\u00fcckgegriffen werden konnte. Wenn man bereits Erfahrung in Drupal Modulentwicklung mitbringt, gestaltet sich eine Eigenimplementierung gl\u00fccklicherweise als denkbar einfach. Da f\u00fcr\u00a0better b. good<\/a>\u00a0vorerst keine eigene PCI-Zertifizierung in Frage kam musste auf die PCI konformen Redirect-L\u00f6sungen der beiden Anbieter zur\u00fcckgegriffen werden. Commerce integriert fertige Mechanismen f\u00fcr sowohl On-Site als auch Off-Site Bezahlprozesse, deren Anwendung stark der Forms API nachempfunden ist, mit der jeder Drupal Entwickler ohnehin ein inniges Verh\u00e4ltnis haben sollte. Ein guter Ausgangspunkt ist das Studium des\u00a0Commerce Paypal<\/a>\u00a0Moduls, in dem alle Optionen sauber implementiert und gut dokumentiert ersichtlich sind.<\/p>\n Insgesamt ist Drupal Commerce als Shopsystem sehr empfehlenswert. Es ist generischer, flexibler und geht st\u00e4rker den\u00a0Drupal Way<\/em>\u00a0als \u00dcbercart, was den Einstieg f\u00fcr Entwickler die bereits mit anderen Subsystemen von Drupal vertraut sind einfacher macht. Im Vergleich mit reinen E-Commerce Systemen wie Magento oder osCommerce ist zwar Anfangs weniger Funktionalit\u00e4t ersichtlich und mehr Konfiguration notwendigt, der Gewinn an Flexibilit\u00e4t ist aber so gewaltig, dass ein seri\u00f6ser Vergleich gar nicht m\u00f6glich ist.<\/p>\n Bei all den Vorteilen d\u00fcrfen jedoch die vereinzelten Wermutstropfen nicht vergessen werden. Die Bandbreite an unterst\u00fctzten Payment-Providern ist noch deutlich geringer als bei anderen Systemen, was aber zweifellos die Zeit regeln wird. Ein gr\u00f6\u00dferes Problem stellen das Wiederverwenden von Rechnungs- und Versandadressen sowie das reibungslose Anmelden w\u00e4hrend des Bezahlprozesses dar. Beides kritische Punkte, die die Nutzerfreundlichkeit stark heben w\u00fcrden. Zwar gibt es in Form von\u00a0Commerce Addressbook<\/a>\u00a0und\u00a0Commerce Checkout Login<\/a>\u00a0schon Bestrebungen das Problem zu beheben, Produktionsreife haben diese Module jedoch noch nicht erreicht.<\/p>\nFair ohne damit anzugeben<\/h2>\n
\n
Benutzerf\u00fchrung und Design<\/h2>\n
Produkttypen<\/h2>\n
Versand und Steuern<\/h2>\n
Die Rechnung bitte!<\/h2>\n
Fazit<\/h2>\n