I'm trying to make a decision between Drupal 6 + Ubercart and Drupal7 + Drupal Commerce... I'd much rather develop in 7 and am excited about Drupal Commerce but, as it is relatively young, have some concerns about its security and stability.

Does anyone have any relevant experience they would be willing to share?

  • You may want to look at the list of launched Drupal Commerce sites at drupalcommerce.org/showcase; a couple of them have blog posts detailing their experience.
    – rfay
    Jul 18 '11 at 14:04

The payment gateway is the key. If your chosen payment gateway is available for Drupal Commerce, I would say yes, go ahead and use it.

Even if not, there are compelling reasons to develop or help to develop the payment gateway.

Drupal 7 is much more advanced, and will continue to be relevant for much longer. Drupal 6 will not be supported when Drupal 8 is released. Suppose Drupal 8 is released in 2 years (nobody knows at this stage but it's a reasonable estimate) and your site takes 6 months to launch. A Drupal 6 site would only have a viable life of 18 months. It's something worth considering!

We're building a reasonably complicated Drupal Commerce site right now and the elements like the order system, cart, checkout and things like entity types are all fairly concrete. It's also slick to use, and offers numerous advantages over Ubercart (products do not HAVE to be nodes, opening up new ways of selling things).

  • 1
    What Chris said - the important thing is contributed module availability. With regards to security, Commerce is smarter at least about handling CC data during checkout. I'm not sure what other concerns you might have. With regards to stability, the major issues being reported revolve around installation from drush and interrupted installations missing required fields on entities. I'm working on fallback solutions for those problems today, but if you start out with Commerce Kickstart you should be fine. Just update from the version of Address Field it gives you to dev before installation. Jul 7 '11 at 15:09
  • I'm definitely looking at the site's lifespan and would much rather build in Drupal 7 for that reason and many others. Thanks for the advice! Jul 7 '11 at 22:47
  • @chris cohen @Ryan Szrama - the question then becomes: is a contributed module available for Paypal Pro? And secondly, how difficult is it to build a pipeline for such? I have some skills with PHP but also some misgivings about writing code that will be handling very sensitive information. I suppose everything will be handled via https/ssl but still am not familiar enough with the territory to feel comfortable with it. The idea of cutting my teeth on a high profile project is tempting but I'm concerned about liability. Jul 12 '11 at 13:20
  • It's not really difficult at all, and there's already code in Commerce Authorize.Net it can be modeled after. Jul 13 '11 at 20:32
  • 1
    @john bit of a delayed response, sorry. How about if you want to programatically create a product on the fly, or your "product" is actually a donation, or a custom ticket for an event, or actually consists of multiple "things" all rolled into one product? This is hard to do with nodes, but easy to do using custom entities. May 22 '12 at 15:56

We're running a project with Drupal Commerce and it a great base for a store, but I'd say the key decision whether to use it is how comfortable you are with development. Commerce is a well designed e-commerce framework done the "drupal way", but unless you're comfortable with writing some custom modules to fill the in the gaps it's a lot slower getting up and running then UC. If UC has what you need out of the box it's likely the way to go from a time-cost of development point of view. If you're looking for long term longevity and future upgradeable of the project and you're ready to do some custom work then consider commerce.

For our project the store we're making is very customized (you order prints online) so commerce is an excellent framework to build on. But if you need something more simple like a say a clothing store, the current way you make a product in commerce is cumbersome. To create a basic product you need to create all the commerce "products" (EG product variations or SKUs) one at a time, in a commerce product type, and then you relate them to a "product view node". When a shopper sees a single product they see the product node view, which bundles up all the (commerce product) variations. There's logical reasons to do this but its slow to enter the data.

This is a lot more work - make all the variations, and then link them to the product. There's some contrib modules out there to help this but commerce is a fast moving target so you'll see commerce updates break these modules - so that's where your ability to modify / write modules becomes important in deciding what system to use. Commerce will be likely be more challenging to develop in right now - as it's got it's own learning curve, but its nice that basically everything is there is now drupal core stuff : views, fields, etc. So if you need flexible expandability in the long run commerce is great, but if your store is not likely to require future functionality enhancements and UC does what you need out of the box then I'd suggest going that direction

  • This is an excellent analysis - thanks. I'm inclined to learn it because it seems like the direction things are moving in and I'd rather just get up the learning curve and then be able to deploy this for people. The truth is, the project I'm on has 3,000+ unique product types, none having sub-types (S/M/L etc) so I'm definitely looking for a way to streamline data entry. I am comfortable throwing some PHP around. I understand that there is a setting to creates a view-node by default when the product is created, which would probably be ideal for this use case. If it isn't there, I can make it. Jul 19 '11 at 1:42

Commerce Kickstart 2 hit its 2nd release candidate yesterday so I would consider it stable to start working with. It is also very actively maintained so I guess there will be lots more bugfixes rolling out over the coming weeks as you start building your site.

I have used it for an upcoming project and it was a major help in boosting development time. It allows as much modification as you like but does include many dependent modules that are difficult to remove as they are part of the core features of kickstart.

Basically, yes, use it but dont install the demo content as you will be stuck trying to remove it.


I have been using Drupal Commerce for several months now. I have not have found many troubles so far. You should take a look of the videos and the documentation commerce guys has and find out if this module will be a good fit for your situation. I love Drupal Commerce. It really helped us to do our solution with the time constrains. I have never tryed ubercart though. I would have loved to have the time to try Ubercart and make a comparison. For my needs, it looked like Drupal Commerce had everything I needed. So, I never give a try to Ubercart.

Here I leave you with some information that helped me out with Drupal Commerce.

  1. Drupal Commerce Official Site
  2. Commerce Guys video in vimeo
  3. developing with Drupal Commerce

I love the integration that it has with Views and there are also modules that help you to extend their features as commerce cart ajax, commerce cart expiration and Commerce Stock. You can customize commerce but don't do it in the core use the best practice of Drupal. I did several customization for my project. I even had to do my own expiration cart because they did not have at that time a cart expiration. I love the way you can also integrate it with Rules. I love the flexibility that this module has given me.

  • thanks. Will give it a try. It does seem a bit slow. I ran up the demo site. The response time seems not what I expected.
    – syde
    Oct 24 '12 at 9:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.