The Major Thing Missing In Drupal Commerce

Documentation, hands down.

Honestly, I applaud the efforts of the Commerce Guys.

When I started working with Drupal Commerce last year, I was so excited by the prospect of a scalable e-commerce solution that could be tailored to my web development needs... after all, it had the power of Rules, right?

Only, building Commerce on Rules would be kind of like building Drupal Core on Views. Though very powerful, Views would actually be quite limited when handed the task to meet Drupal's demands. And so it is with Rules and Commerce. Things which should be simple to implement have now become quite complex and only achievable in a limited scope because Rules is limited.

And so the modules pile on and on as Drupalians find solutions and work-arounds, which is great for the originators of the code... but what about everybody else? We need documentation--sure, screencasts would be stellar, but a manual would import relief of biblical proportions.

And after tweeting this in frustration, I received a reply that full documentation is on the way. All Hail the Kings of Commerce? I certainly hope so.

Short-term request for the manual... define terms. I can't tell you how long it took me to discern the difference between a field, a line item and a component.

In the long term, it would be nice if Commerce came with a few more out-of-the box features, especially support for virtual product types like downloads, subscriptions, and the sell of user roles. And less dependence on Rules... or maybe user friendly Rules wizards that save time and sanity :P


Posted: Jun 18, 2012


Ryan Ryan Szrama on June 20, 2012

I can add some further context here, too, especially as it pertains to your related issue in the queue. All of the Rules events we define for Commerce have corresponding hooks of the same name that take the same parameters... except for one. You guessed it - the event to Calculate the sell price of a product. It wasn't an oversight, though, but an intentional decision to have people process all of their price calculations through Rules so we could do two things:

  1. Ensure that price modifications were handled properly through the various Commerce Line Item actions; it's not enough to just change the "amount" of a price field value, because you have to create a corresponding price component in the field value's data array to track the change.
  2. More importantly, we wanted to be able to pre-calculate all possible prices for every product on the site and store these in the database keyed by which Rules ultimately resulted in them being called. This would let you do things like sort and filter Views of products based on calculated prices instead of just the base price of the product stored in the DB by default.

It may surprise you to learn that feature is actually in core, but it probably won't surprise you to learn that it never really panned out. What we thought at first would be an essential feature for high-performance sites simply hasn't come up enough to even push through the patch to integrate the pre-calculated price table with Views.

I think a quick fix for the problem will be to change the code so that we invoke the corresponding hook for the sell price calculation event unless pre-calculation is actually in use. It's an optional thing, so there's no reason to force 99.99% of sites that don't use it to not be able to update prices via straight hooks.

However, I'll add that even if you're stuck on Commerce 1.3 and won't be able to update, it's fairly simple to write a custom Rules action. You could simply right an action that calls your pricing engine and do the exact same thing until the hook goes in. The main thing to remember is that you're responsible for updating the price components array when you alter a price amount. Look to the actions in commerce_line_item.rules.inc for examples.

In short: we want to privilege Views and Rules by default to assist non-developer users, but we definitely don't want to require them. In the sites I've built, I use less Rules and more custom hooks, and I encourage other developers to do the exact same thing.

As for documentation, that's another one of those things I basically expected to just happen by demand. The docs here have always been a wiki, and we assumed the community would up and pitch in. That's simply been proven false, and it's due to a variety of factors including lack of expertise, time, willingness, understanding, etc. So last month I brought joshmiller on board at Commerce Guys to help fix this, and I'm currently reviewing a complete user's guide to replace the stubs / skeleton pages we have in here now.

If you want to take a peak, you can find them in GitHub at https://github.com/joshmiller83/dc_docs.

Hope that background info helps! There's always more to do. : )