After the tremendous effort of a diverse group of contributors, I excitedly packaged up Drupal Commerce 1.0-beta1 in the wee hours of Thursday morning. A day and a half later, I'm still prancing around on cloud nine, gushing about Drupal 7 to my wife and showing the demo site to my friends who haven't a clue about Drupal (much less building websites at all). Needless to say, I couldn't be happier, nor could I be more bullish about the prospects for e-commerce on Drupal 7. Here's why.
I just spent a day in IRC talking to beta testers about how to solve particular e-commerce needs, and we just haven't been stumped yet. With the entire Commerce system setup on fieldable entities, Rules, and Views, it's hard to find an impossible or even particularly puzzling problem. For example, in a few short minutes, I was able to spec out a system for selling custom nodes (e.g. classified ads) that works much better than my UC Node Checkout ever did using just the tools provided out of the box and a custom Rules action.
What's more, traditional challenges for users familiar with Ubercart on Drupal 6 pertaining to checkout and payment turn out now to be a simple matter of module and Rules configuration. These include bypassing the payment step on free orders, switching from multi-step to a single page checkout form, and disabling the shopping cart entirely in favor of manual invoice creation and direct checkout form access. I'll be explaining these scenarios and more on the blog and in the developer forums over the couple of weeks.
New tax support (incl. VAT) in Beta 1
Those features and many more are baked into Drupal Commerce, but the beta release brings with it some important features that are new since the last alpha. You can read the full list of changes in the release notes, but the pièce de résistance is the inclusion of tax support working through our Rules based pricing system. Indeed, upon announcing VAT support through tax inclusive price display (and optionally price entry), I was awarded with European tweets of affirmation and at least one #brofist.
The way it works is fairly straightforward. The core now includes Tax and Tax UI modules that are used to define the tax system and a user interface for creating tax types and rates. The actual application of a particular tax to a product or other line item on an order is governed primarily through Rules, though this can be disabled in lieu of a hardcoded solution in a module implementing the tax hooks. When enabled, the Tax UI provides two "template" tax types for taxes that are just displayed in the order totals and for those that are displayed inclusively with product prices.
You then must define a tax rate for each tax you collect from your customers, whether it be for different tax jurisdictions or types of products / services.
The default configuration will apply these taxes every time a product's sell price is calculated. When added to the cart, the product line item's unit price will contain the base price of the product and the amount of tax required for each tax rate. To restrict which taxes apply to different products, you configure each tax's Rules component to include appropriate conditions determining its applicability. Additionally, if any of your taxes display inclusively with product prices, you can opt to enter prices including the tax.
If a price is entered including tax, it will be saved divided into its component prices for later totaling on the checkout and order view pages. A custom display formatter for price fields will list out the various components of the price, and we use this to format the order total field which is itself an aggregate of all the component information from line items on the order.
It's worth noting that even for taxes that only appear summed in the order total, tax is still calculated and stored on a per line item basis. As of right now there is no core tax reporting feature, but contrib should make short work of such a module and will be able to respond much more quickly to the various reporting needs of different users.
Additional Beta news and the "Great Git Migration"
The beta brings with it various API improvements, more standardization with core patterns for structure definition (yes, arrays... le sigh), and pattern based namespacing of module-defined fields (e.g. commerce_order_total instead of order_total). Additionally, customer profile management has been greatly improved over previous releases, and product line items now maintain a link to the display context from which the product was or should be added to the cart.
Thanks in large part to pcambra, one of our newest Commerce Guys, and the contribution of recidive, one of our favorite Brazilians, most of the major core systems are covered by SimpleTests. Work on tests is ongoing as we strive for our stated goal of full functional test coverage with the 1.0 release. Contributions are still certainly welcome there.
Thanks also to fago's continued work on the Entity API and Rules modules, account creation during anonymous checkout is now powered entirely by Rules. Each site can now determine for itself how exactly to implement anonymous checkout, with the default behavior being the creation of accounts for new customers and the assignment of existing accounts to repeat customers who simply didn't login before checkout.
And last but not least, thanks to the HUGE efforts of everyone on the Great Git Migration team, our main project repository is now comfortably at home on drupal.org. Until now, I have maintained a repository on GitHub from which I exported commits to CVS on d.o, but I will be discontinuing that repository. Contributors are still welcome to maintain their forks on GitHub, but I ask that you create a new project that clones the d.o repository instead of my previous repository on GitHub. If you have any questions about existing work that I haven't pulled yet, please find me in #drupalcommerce on irc.freenode.net. The easiest thing to do will be to make a good ol' patch.
DrupalCon Chicago and Beyond
So, now Drupal Commerce is all ready for DrupalCon Chicago. We have a stable release, a fresh demo site, and plans to zip through it all in my session. Last I heard, we still have several seats available in my Drupal Powered E-commerce training session where I'll be teaching attendees how to duplicate my demo site and use existing tools to build on the core systems. If there's a slight possibility you'll be implementing Drupal Commerce in the coming months, I encourage you to attend. The Commerce modules are powerful and more flexible than Daniel Browning Smith, but it's still a complex set of tools to wrap your head around.
Additionally, you can read about setting up custom product displays in the first issue of Drupal Watchdog, found in your tote bag at DrupalCon Chicago. I've also contributed a chapter providing a broad overview of the Commerce systems, including its various entities and fields, to the Definitive Guide to Drupal 7 to be published by Apress later this year. I'll also be attending other events this year to present the project and connect with contributors, including DrupalCamp Colorado, DrupalCon London, and Do It With Drupal in NYC.
If you have any inclination to contribute to Drupal Commerce, whether it be a payment integration module, a feature module such as coupons, stock, or shipping, or documentation, please find me in person at an event or online in IRC, the issue tracker, or the Drupal Commerce homepage. I'll be posting a developer guide to help you quickly integrate your payment system of choice, and you can use any of my existing payment modules as guides in the meantime: Authorize.Net, CyberSource, and PayPal (currently supporting WPS as an example for redirected payment services).
I will also happily accept #brofists in person.