This article is the second of a four part series. It was born out of the DrupalCon San Francisco session by the same name and has been fleshed out through internal interviews with Ryan at Commerce Guys. We use the material to help the whole team understand how Drupal Commerce will improve the way we build sites on Drupal 7, and we hope it whets your appetite, too!
Check out part one first if you missed it for points covering our API and UI development principles.
Packaged distributions of Drupal aren't the future of "Drupal as a product", they're the present. Our community home now helpfully packages Drupal distributions based on installation profiles (with more features in the works), and Moshe et al. and Development Seed continue to rock drush and a collection of contributed modules that power distributions like Open Atrium. Acquia is aggressively targeting its social enterprise competitors with their Drupal Commons distribution and provides a software publishing program that enables their partners to develop distributions to compete in their own markets. To cap it all off, Boris Mann, erstwhile champion of the Drupal installation profile, has come back on the scene to keep the discussion moving forward for the sake of an improved user experience.
The bottom line is developers and companies are actively pushing Drupal forward as a platform for building and marketing complete, targeted distributions of Drupal. This makes it essential for modules like Drupal Commerce to be developed in such a way that packaging them into distributions is as smooth as possible. Drupal and e-commerce are individually two very complex things to learn, and the adoption of a project like Drupal Commerce will be spurred in large part by its ease of use for newcomers. We believe Drupal Commerce distributions will be the starting point for many new users who know how to install, use, and customize software but don't have the experience or knowledge to build an e-commerce website from scratch.
The following two points about this focus for Drupal Commerce come from our experience with UberDrupal and internal projects where developing and deploying distributions based on Ubercart were painful:
1. Strict separation of the core systems from plugin modules.
We built Ubercart on Drupal for its modularity and were quickly rewarded. Contributed module developers produced dozens of modules that provide new features and third party service integration. However, we also baked into the core module set a number of modules that were plugins to core systems. For example, the core Ubercart payment module exposed an API for modules to define new payment methods and interact with payment gateways. We then included modules that could be easily installed for PayPal, Authorize.Net, and a handful of other services. Unfortunately, this produced a maintenance problem that we didn't foresee: it slowed down our development cycles to the point of near stagnation.
Because you can't roll a new release of your project until bugs are worked out in all the modules, we had to introduce core system changes and update all the plugin modules at the same time. Furthermore, if a bug was found in one of the plugin modules, it had to be fixed and released as soon as possible, but this wasn't always easy if the core systems were in flux. With Drupal Commerce, we're keeping the core project as slim as possible so the development cycle isn't artificially prolonged. This means our core systems will be free to mature much faster while the plugin modules will also be free to add new features and interact with other modules at their own pace. Again, this may not seem like a huge deal to non-developers, but one look at the release cycle history of Ubercart should be reason enough to applaud this shift.
2. Focus on packaged distributions of Drupal Commerce.
The reason we included plugin modules in the core Ubercart package is because we needed them to achieve a good user experience out of the box. The community architecture for Drupal distributions wasn't in place at the time, and we wanted an easy way to ensure someone could simply install Ubercart and start selling. This means we needed some basic plugins (like for the popular payment and shipping quote services) and some installation configuration code (like automatic product image configuration). However, the new distribution consensus serves this purpose in a much better fashion.
What we're doing with Drupal Commerce is developing with Drupal distributions and Features modules in mind. We won't solve specific use cases with the core modules, but we will encourage people to create Installation Profiles on drupal.org that can be packaged into full Drupal Commerce distributions that do so. Installation profiles can inject steps into the installation form to speed up the store setup process and can specify any number of contributed modules to include and configure automatically. This will be a huge win for development shops who routinely build a lot of a specific type of site.
Our vision is to see a whole buffet of Drupal Commerce distributions that store builders can use as starting points for t-shirt sales, event registration, donation collection, etc. Additionally, by making the various configurable entities and systems of the modules exportable (i.e. product types, checkout configurations, etc.), individual Features modules can be created to meet the needs of users already running sites who don’t have the capacity to build the features from scratch themselves.
Part three will cover our use of Drupal 7's entities and fields APIs and how they will enable a sharper focus on the e-commerce site as a conduit of information, not just a container. To follow along with development, start by visiting the project page at http://drupal.org/project/commerce.
To experience our internal training firsthand, join us in our Drupal Powered E-commerce training at DrupalCon Copenhagen.
Add new comment