It is well known that Drupal 7 easily meets the requirements of almost any web-based project, from simple presentation pages to more complex information systems and full-fledged communities. But what about e-commerce solutions? Is the blue drop also suitable for online shops? A brief user report aims to provide clarity here.
For a long time, Übercart was considered the standard if you wanted to sell something on a Drupal site. Alternatives were practically non-existent and, to be honest, not necessary. However, the situation changed with the release of Drupal 7, which brought with it a wealth of new and better technologies such as entities and fields. Übercart, however, was very strongly tied to Drupal 6 APIs and modules like CCK, which significantly complicated a straightforward porting process. Instead, the Drupal Commerce project was launched. The stated goal from the outset was to provide a Drupal 7 based e-commerce solution that would also make the best possible use of the new APIs. We had the pleasure of putting it to the test with better b. good. And the results are impressive.
Fair without bragging
A small digression is necessary at this point. Better b. good is the company of two charming Upper Austrian women, Christine Schlögl and Pamela Glück, who firmly believe that every woman should be able to buy everyday fashion from socially and ecologically sound sources with a clear conscience, without immediately being branded with esoteric colour combinations and "hippie chic". The circumstances led to the following requirements that the online shop had to meet:
- A small product catalogue initially required an unusual navigation approach...
- ...but unique presentation to adequately convey the philosophy and ideology.
- Configurable products with different additional information for all permutations.
- Shipping at various tiered prices to a total of 22 EU member states.
- Integration of two different external payment providers.
User Guidance and Design
A menu system proved unnecessary, so the approach was to completely forgo it and instead integrate all core functions directly onto the landing page in a playful way, brought to life with hand-drawn figures in a storytelling manner. In this step, the internal Drupal 7 Ajax mechanisms and the stylesheet framework Compass provided invaluable services.
Product Types
When first encountering Drupal Commerce, one design decision by the developers often causes headaches: products are not simply individual entities or even nodes. Instead, they were divided into the products themselves and the so-called Product Displays. A product actually represents a single physical item with a unique item number, for example, a white T-shirt with a crew neck in size Medium. Product Displays, on the other hand, are simply nodes with a field of type Product Reference, to which any number of products can be attached. This allows different versions of an item to be managed separately in inventory and accounting, but very easily bundled for presentation and, for example, made available via an intuitive configurator.
Both products and displays are fieldable entities and can be equipped with fields for additional information or, for example, images. This results in a flexibility that is sorely missed in highly specialised systems like Magento. For instance, no adjustment of the programming logic in PHP was necessary for the product view and configuration functions on better b. good. They could be provided through simple configuration of the existing mechanisms.
However, the external module Commerce Bulk Product Creation is worth mentioning, as it helps to quickly and automatically create all permutations of a product category (for example, black and white shirts in five sizes and two sleeve lengths). Knowing that this module exists can save a lot of time.
Shipping and Taxes
Initially, the module Commerce Shipping primarily offers the option to request separate billing and delivery addresses during the checkout process. However, that is not all. With the help of Rules (which are used in various areas of Commerce), it is possible to configure arbitrarily complex rules for shipping costs. Although this is done purely via the administration interface, due due to the inherent complexity of the matter, a not insignificant technical understanding is required.
Taxes in Drupal Commerce work on the same principle as shipping costs and leave nothing to be desired in terms of flexibility.
The Bill, please!
The final, but probably most important, step was the integration of payment options. Modules for Drupal Commerce are already available for many of the larger payment providers. In the case of better b. good, the choice fell on Novalnet and Sofortüberweisung.de, where unfortunately no existing modules could be used. Fortunately, if you already have experience in Drupal module development, implementing your own solution is remarkably straightforward. Since a separate PCI certification was not an option for better b. good for the time being, the PCI compliant redirect solutions of both providers had to be used. Commerce integrates ready-made mechanisms for both on-site and off-site payment processes, whose application is strongly modelled on the Forms API, with which every Drupal developer should already have an intimate relationship. A good starting point is to study the Commerce Paypal module, where all options are cleanly implemented and well documented.
Conclusion
Overall, Drupal Commerce is highly recommended as a shop system. It is more generic, more flexible, and follows the Drupal Way more closely than Übercart, making it easier for developers already familiar with other Drupal subsystems to get started. Compared to pure e-commerce systems like Magento or osCommerce, less functionality is initially apparent and more configuration is required, but the gain in flexibility is so immense that a serious comparison is simply not possible.
Despite all the advantages, the occasional drawbacks should not be forgotten. The range of supported payment providers is still significantly smaller than with other systems, but time will undoubtedly rectify this. A bigger problem is the reuse of billing and shipping addresses, as well as seamless login during the checkout process. Both are critical points that would greatly improve user-friendliness. While there are already efforts to address the problem in the form of Commerce Addressbook and Commerce Checkout Login, these modules have not yet reached production readiness.
The continuation of this blog post can be found here: Drupal commerce advanced
