Ubercart 3 Vs. Drupal Commerce: The Choices for Drupal 7 Shopping Carts Get More Complicated

Developers looking for a Drupal-native shopping carts now have two choices for e-commerce: Long-time leader Ubercart (now ported to Drupal 7); and Drupal Commerce, a new system written from the ground up by some of the former members of the Ubercart team. With two options to choose from, which project gets it right?

Drupal Commerce v Ubercart 3
Drupal Commerce and Ubercart offer two choices for Drupal-7 Shopping Carts

When I first started working on e-commerce sites, choices for Drupal-native carts were limited to two packages: the e-Commerce project and Ubercart. Based on the development activity and large number of supporting modules, I became an enthusiastic supporter of Ubercart. In fact, it's was my first choice for ecommerce systems in general, since it brought so much to the table: Here's a scalable e-commerce solution using Drupal's same node-based architecture, theming system, and user management routines while offering a cart with a barrel full of sophisticated customization options. If you needed both a CMS and an ecommerce solution, you'd be hard-pressed to find a better combination than Drupal 6 and Ubercart.

Over the years, though, I've tempered my enthusiasm for Ubercart: While it's still good at handling the most common ecommerce demands, the project is not without its flaws. Its documentation can be thin, responses from the community sometimes slow, and chunks of more advanced features are sometimes left frustratingly unaddressed.  None of this is helped by the project's home site which can be difficult to navigate if you're looking for quick answers to common questions. 

But Ubercart is still the best game in town for Drupal 6, and it continues marching on — Ubercart 3 is a port of the project to Drupal 7, and there is a committed developer base currently at work. Lately though, the choices for Drupal 7-native shopping carts has gotten bigger, with the introduction of Drupal Commerce. 

Commerce is an exciting entry to the Drupal shopping cart category written by some of the same developers who previously managed Ubercart. (It's lead developer, Ryan Szrama, was the former Ubercart lead.) Unlike Ubercart, Commerce is a Drupal-7 only module. While it's technically been in development since 2009,  it wasn't entirely ready for production and it's only been wIthin the last few months that package downloads have gained momentum. Meanwhile additional support modules are rounding out the project's offerings, making it a serious option for new installations. So how do the two compare?

First, keep in mind that few carts satisfy everyone. Carts are tricky pieces of software to develop since they're expected to do so much — from customer management to shipping calculations to inventory control. At the same time, carts are often maintained by non-technical users who demand that systems are both easy to maintain, but endlessly configurable.  While one might have a great interface, it may be horrible at calculating shipping. Another might handle thousands of SKUs, but be completely inscrutable to the inexperienced user. And don't forget, they have to be bullet-proof: There's real money riding on every page of a shopping cart so mistakes can be costly. 

These wide ranging requirements would appear to give any Drupal-based cart a leg up on competing systems since flexibility is Drupal's bread and butter: Its modular architecture makes it flexible enough to handle almost any situation, and you'd expect a native cart would offer the same advantages. 

Core Differences Between Ubercart and Drupal Commerce

Like Drupal core, both Ubercart and Drupal Commerce attack complexity through user-contributed modules. In fact, when you download either cart, you're actually downloading a suite of modules that work together to provide basic functionality. Exactly what's included in the core, though, is the biggest difference between the two packages.

While Ubercart delivers a lot of power in its out-of-the-box installation, Commerce aggressively strips its features down to the barest of bare bones. For example, new Commerce users might be surprised to find that it doesn't include a shipping module in its core, or even a basic payment gateway. To do either, you'll need to download additional modules. 

(Lullabot posted an interesting podcast with lead developer Ryan Szrama (Sept. 9, 2011) where he explains this minimalistic approach: Create a stable core for the big functions, then let site builders add and configure as needed. It's the divide and conquer mentality applied to shopping cart development, and Drupal Commerce takes this much further than Ubercart.) Szrama writes more about this approach at the project's home site.

But this is just the start of the differences: While Commerce may be developed by members of the former Ubercart team, if you're expecting Ubercart, you might find the transition to Drupal Commerce jarring. While Commerce offers many of same structural elements as Ubercart (the store administration navigation structure looks familiar), Commerce changes the whole product data structure, creating huge differences in how products are both entered and displayed. 

Products as Entities

Users who have already use Ubercart understand that it follows a more typical Drupal 6 data structure. Basically, products are nodes.  That means entering a products in Ubercart is a  little like entering a story, only there are more fields for product-related values like price and weight. Meanwhile, product variations (ie color, size, etc.) are treated as "attributes" of the main product, so if a product is green or blue, large or small, any option added to the product still references a single product node.

For end users this architecture is easy to understand: A product is entered once, and any additional options refer to the main product node. When you publish a product, it shows up on your website.

Commerce, though, uses Drupal 7's entity system and treats any options as a new, distinct products. So, if a merchant is selling a T-shirt in red or blue, these exist as two separate products even though they might be exactly the same in every other respect. This approach is a lot closer to how retailers who use traditional unique SKUs  — Stock Keeping Units  —  operate. (It also better fits a database developer's perspective too, since technically this is a more abstracted approach to data structures.)

In fact, this single change might solve one of Ubercart's biggest weaknesses. 

In that system, product variations (like color or size) were added as an "attributes" of the main product's node. Under that architecture, no matter how many variations a product had, these always referred to one single node in the system. 

Unfortunately, this meant that many operations relating to custom options (like special tax or shipping calculations) were sometimes prone to errors. For example, inventory control was always an Ubercart weakness. You'd expect that preventing customers from adding items to their carts when there isn't enough inventory would be a core feature, but that issue was addressed through a patchwork of competing modules. (Can it be done? Yes. But most of the contributed modules addressing this issue were either limited or buggy, since they usually used client-side javascript that was inconsistent throughout the checkout process.) The point is, the architecture was far from perfect for merchants who have a lot of SKUs and need a rock-solid cart.

Commerce's system of unique products for every variation handles this scenario with much more sophistication. Using this structure, it's possible to create complex pricing changes, shipping conditions and inventory control for every product variation. But here's the catch: It also introduces a new level of complexity to the system that many users may find baffling.

Products in Commerce aren't traditional nodes. Instead, they're really just data units that store the unique information about each SKU. By default, these units aren't displayed on the site on their own. Instead, users have to create separate display nodes tying product variations together for display on the site. (A product display node handles the Title and Body text. It also collects information about product variations and displays them to the visitor.)

What all this means is that creating a product is actually a three-part process. Imagine a retailer selling t-shirts. The sizes are small, medium and large and the colors are blue and red. To achieve this in Drupal Commerce, a user follow theses steps: First, the retailer creates a 'tshirt' product type. (Fields for any variation are created at this step, so size and color options are added here.). Next, individual SKUs are entered for each possible combination of size and color. Finally, a new product "display" is created, which includes the title and body text.  The separate SKUs you entered earlier are added here through an auto-complete field, much as you'd add taxonomy terms to a Drupal node. (Ryan Szmara writes about the process in the Drupal Watchdog.)

This is not going to be easy for non-technical users to grasp, at least not at first. Imagine a scenario where a retailer just wants to add a new color to one of their existing Tshirt offerings. To do this, they'll add a new option in the Tshirt product type color field. Then they'll add new SKUs for each additional size variant. (That's more work than they'd probably expect, but OK so far.) But consider this: If they then return to the public side of the site expecting to see the new option show up, they'll be disappointed. That's because before a product option can be displayed, it has to be manually added to the product display node. So before the product shows up, the user will have to return to the product display node and add the new SKUs through the auto-complete field in the node edit form.

Yikes, that's complicated.

In fairness, Ubercart's attribute system isn't especially easy either. In fact, while evaluating the newly posted Ubercart 3, I had to jog my memory while going through the steps of entering product options. This includes creating global attributes, then adding options to each global attribute, then adding the global attribute to the product. There are also extra steps needed to manage SKUs and stock levels, and if you're a merchant and forget to enter a new SKU number or inventory amount, you've traded complexity for the very real possibility that you'll be selling products you don't have in stock.

End-user Documentation

Both of these carts are big, complex projects that demand solid documentation for end users. To meet this demand, each maintains its own website for user forums, support and documentation. This isn't unique: A lot of projects have their own home pages. But shopping carts are special cases. There's real money on the line here, so its extremely important that when questions arise, both developers — and end users — are able to find the most current documentation, modules and patches as quickly and easily as possible.

That's why both of these sites need more work.

As a developer who's sometimes called to help maintain several Ubercart 2 stores, I dread visiting Ubercart.org, because it's just too difficult to find what I need. Technical documentation can be fragmented across multiple forums, support topics sometimes abruptly switch between versions, and the contributed module listings are poorly organized. At the moment, there isn't even the stub of a user guide for Ubercart 3. (As I write this, the "demo" link goes to White Screen.)

Unfortunately, it appears the Drupal Commerce team is using some of the same tactics. Forums still play too big a role in technical support, and the user manual needs to be re-engineered before it spins out of control. (Here's a great example: If you install Commerce through the recommended Commerce Kickstart profile, you'll be able to add test products to your shopping cart from the home page, but you won't be able to adjust the quantity until checkout. Why? Because no quantity field is displayed in teasers by default. This is easily done,  but searching the Commerce site for an explanation for the exact steps to take is excruciating. Do we really need to scroll through user-contributed comments to understand basic configuration?) 

All that said, Commerce does get a few things right: Team member Randy Fay has produced a library of instructional videos clarifying use for the ordinary user which is a very welcome addition. 

Search results at DC.orgBig projects need really good search engines (like Solr), otherwise you end up with results like this. Two suggestions would help each one right away: First, they both need to install a facetted search engine like Solr, or even Lucene as quickly as possible. While Drupal has a reputation for delivering decent search results compared to other open source projects, it simply isn't as good.  In my book this isn't something for the "would be nice to have" column. It's an absolute requirement for these projects.

Next, they both need to completely re-architect the way they display documentation: When it comes to configuration, the last thing I want to see is a discussion. Instead, I want specific answers presented as concisely as possible. In short, what's needed is a user manual that's as easy to understand as an airplane emergency card. 

I should point out that as I was writting this post, I exchanged emails with Ryan Szrama, and he mentioned that efforts are underway to redesign and update the Commerce home site. Ultimately, he said, the revisions may provide a documentation model looking more like StackExchange's for the most common support issues. This would be a very welcomed addition.

And the Winner Is...

So which solution is best? Drupal Commerce's advanced architecture and forward-looking integration with Drupal 7 make it a strong candidate for new merchants and more technically sophisticated users. It's core design offers an amazing amount of power for handling tax, shipping and inventory control, and it's backed by a strong team of developers who have years of experience writing Drupal carts.

But keep in mind that Commerce is a new package. So while it offers real promise, there's still a lot of work to be done. Payment gateways and shipping options are still very limited (At the moment there's is no integration of FedEx and USPS, although it's hard to imagine that these additions wont be offered soon.) Keep in mind, too that system management is currently far more complicated than Ubercart's, although the trade off in overall capabilities may be worth it. Finally, multiple modules are in development that aim to streamline the usability issues that may bother some users. 

Meanwhile, for merchants with successful Ubercart stores who just want to migrate up to Drupal 7, Ubercart 3 may offer the path of least resistance, especially for those who don't want to learn a new product system, or cant spend the time (or development money) on a major cart migration. It's important to point out though that while Ubercart 3 does work with Drupal 7, some of the support modules available in earlier versions may not be ported to Drupal 7 yet. And while the overall system is somewhat easier to understand for casual users, merchants who've struggled with SKUs and inventory control may not find a solution in Ubercart 3.