Ubercart vs Commerce Comparison
Drupal 7 comes with two primary options for e-commerce websites: Ubercart and Commerce. Ubercart was the standard for Drupal 6 and has been ported to Drupal 7. It still has many great features for creating a web shop, but it lacks proper support for solid product management. Commerce is new for Drupal 7 and redefines the way Drupal handles e-commerce. Choosing the right e-commerce module suite for your webshop is an essential starting point. It is important to invest the time comparing each solution before selecting one. You do not want to find yourself a few days from launch and decide it’s just not working the way you want.
The main differences between the two e-commerce solutions revolve around user preference and product management. Each e-commerce solution attacks the same problem - the ability to create a flexible, yet powerful web store - in different ways. Commerce is much more modular; it does not come with a shipping module or any payment gateways. You will need additional modules for these functionalities. Ubercart, on the other hand, includes both shipping and payment options in its suite. But you will have to decide which of those options to install.
The most important difference between Commerce and Ubercart is the way each handles products. Ubercart is easier to manage for simple singular products, like a novel. Commerce, on the other hand, provides greater flexibility for products with several variations, such as t-shirts. It is much more powerful when it comes to handling multiple product variations. Commerce is also more challenging to learn and understand.
Ubercart and Commerce do also have many similarities. They have comparable installation and setup requirements, administration sections that resemble one another, and use a lot of the same terminology to describe their suites and functions. Commerce was actually started by developers who left Ubercart to take Drupal e-commerce in another direction.
The installation process for Commerce and Ubercart is very similar. Each e-commerce solution is actually a suite of modules. Commerce has chosen to strip down to the most basic functions and allow other modules to handle the extra functions. You won’t find a payment gateway or shipping module in Commerce. Ubercart, instead, combines the most common payment and shipping options into its main suite of modules.
Both are basic installs which require several other modules to function. Commerce requires the following modules: Address Field, CTools, Entity API, Rules and Views. On the modules page, all of the modules in the Commerce fieldset are almost always going to be installed, except Tax and Tax UI (if you don’t charge tax).
Ubercart requires the following modules: CTools, Entity API, Rules, and Views. Ubercart chooses to split its modules into several fieldsets, but you will need to install all of the modules in the Ubercart - core fieldset. You will find shipping and taxes in core (optional). Many of the other modules are turned on by preference. Although, you may find yourself a bit confused by the bloat as to which modules are truly needed.
Both e-commerce suites do enable you to completely customize your store. Their methods are also very similar. Once installed, Commerce has a lot of configuration options (which are located here: /admin/commerce/config). From checkout settings to payment methods and pricing rules, a host of customization abilities are included. For the majority of configurations, leaving the default settings will work fine. You will want to update the currency if you’re not using US dollars.
Ubertcart also provides many ways to configure your store located in the following path - /admin/store/settings. Most of the defaults are probably fine for your store, but you can choose to enter your address and contact information. Do change the currency as needed. In either case, the store will function just fine without making any changes to the store configuration settings.
The most significant difference between the two modules is how they handle products. Ubercart handles products in an all-in-one fashion, treating each product as a content node. The administrator adds all of the options and attributes to the product node. This aspect turns out to be a major pitfall of Ubercart, as it can lead to errors with shipping, billing, and product stock. It is also impossible to say Ubercart’s system of attributes is truly uncomplicated.
Commerce has chosen to handle products in a different manner: each variation is its own entity. Products are not displayed on their own; on the other hand, a display node must be created to display a product or a set of products via a relationship field. This system may be a bit more difficult to understand at first, but in the end actually functions in a way closer to how tangible products function.
Let’s look at adding two t-shirts, one blue and one green. Assume each t-shirt comes in small, medium, and large sizes (that’s six variations of the same shirt). In Ubercart, you would add one product node called t-shirts and then add the color and size attributes. Since the products are all attached to the node, it’s easy to see all the variations. It’s also simple to understand and input data, at least once you’ve set up the global attributes. But when you start filling orders, tracking stock levels, or updating individual variations, it becomes increasingly difficult to track the variations of shirts or to understand which shirt has what SKU.
The process of adding product variations begins with creating global attributes. Then you must add the options for each attribute. The attribute is then added to the product node, in a similar fashion as fields are added to a regular node, but you must edit them in an additional tab page. This system can be very challenging when you’ve got to track the stock levels in Ubercart.
Commerce has a slightly different process, requiring you to create a product entity for each color/size combination. So in this example, you would have to enter six different products instead of six attributes. Then you would need to create one node for display, and reference the six products within the display node. Commerce splits the product from the display node, so that other modules will always work correctly with the products. Special shipping or stock options will always calculate properly. It is also easy to make adjustments to a single product entity.
In one sense it seems you are entering a product twice - first to hold the data and second to show the data to the shopper. A smart move is to break down the data for your products. Anything that will not change with size or color, such as fabric contents, should be entered on the display node; and not the product entity. For those wanting the best of both worlds, you can try out Commerce Kickstart.
Commerce Kickstart is a Drupal distribution that can be used to simplify usage of Commerce. The goal is to make using Commerce easier. It sets up all the basic modules and changes the administration sections. It automatically creates display nodes for products and makes adding variations more like Ubercart’s way of adding attributes.
In my opinion, Commerce Kickstart makes using Commerce more difficult. The reason is because the rest of the Drupal administration area becomes nearly impossible for users used to Drupal. But it may be the perfect bridge to fill the gap for those used to Ubercart, while keeping the power of Commerce. If you’re confused by Commerce, it may be worthwhile to give Kickstart a try.
Submodules and Missing Submodules
You will most likely need to install more extra modules for Commerce than Ubercart. The reason is because Ubercart comes with additional functionality loaded into the main module, with the hope that you won’t need any add-on modules. Commerce, on the other hand, forces you to choose the add-on modules needed for your configuration. That said, you still have the option to add more into Ubercart.
The primary downside to Commerce is the lack of support for shipping and payment gateways. Currently, there is no module to ship via FedEx. Also, no module exists to accept payments through Google Merchant. Frequently, new modules are added to handle the vast array of options. But without the ability to ship or accept payments, you’re stuck on which module suite to choose.
Commerce Should Win
In the end, there is no simple way to decide which Drupal e-commerce module to choose for your web shop. Personally, I always choose Commerce assuming I can find the submodules to handle the required payment gateway and shipping options. But for some users, the complexity of Commerce’s new product system will simply not work. If you have a small store with a few options per product, Ubercart will work just fine. On the other hand, if you’re a clothing retailer offering multiple colors and sizes for each product, Commerce may be the only way for you to manage inventory and keep the products straight. Currently, if you want to ship with FedEx or use Google Merchant, you’ll need to either create your own modules, or use Ubercart.