Next Steps for Drupal Commerce

It was my pleasure to demo Commerce Kickstart 2.x at DrupalCon Munich as I presented Next Steps for Drupal Commerce. The relaunched distribution has been a long time coming, and I couldn't be happier with the release our Kickstart team at Commerce Guys has produced. They've proven the idea that we could keep the core of Drupal Commerce a slim eCommerce framework and wrap it in a usability layer that makes it both attractive and easier to administer.

Beyond the sheer amount of polish that has gone into the UI from the installer to the "Shiny" administration theme, its two most exciting features for me are the Inline Entity Form and Views Megarow functionality.


An inline entity form on a product display node with multiple variations.

Inline Entity Form allows us to embed product details forms inside node forms, simplifying the product vs. product display architecture that has made Drupal Commerce notorious (and truly flexible). I could write a whole post about just how we've implemented it, but I'll save the gory details for a later time.

I will at least point out that if this were a single value product reference field, instead of the drag-and-drop table pictured here, the module would simply embed the product related form elements directly into the node form.


A Views Megarow in action after clicking the "Quick Edit" link.

An equally impressive technical implementation, Views Megarow makes it simple to edit groups of products and orders inline in a View through some fancy AJAX row expansion. It gives you easy access to bulk product edit forms and order summaries complete with order activity streams and administrator comments.

Both of these features have been meticulously planned, designed, user tested, and revised to provide a very streamlined user experience for store administrators. With my time mostly focused on other development, I happily applaud our team for putting out such high quality work.

However, even with this release under our belts, we're hardly ready to sit back and relax. We have plenty more to do in the development of Drupal Commerce distributions, contributed modules, and the core framework itself. I spent the final part of my session at DrupalCon proposing the topics and timeline under consideration for a Drupal Commerce 2.x roadmap targeting Drupal 8.

To make sure we're meeting these challenges head on, I proposed a Commerce 2.x planning and development sprint at our offices in Paris in mid-October. The primary goal of the sprint is to research and plan development on Drupal 8, including how to best utilize and work with the various core initiatives, what new modules to add as dependencies or bring into core as new features, and what core code needs refactoring.

This sprint is on the calendar for October 15-19, and while we likely won't be laying down a lot of code, we're still looking for collaborators. We're particularly interested in folks with experience developing for Drupal Commerce on Drupal 7, bonus points awarded to those who have had to work around its limitations.

I'll post more on the topic in the near future, including specific items we intend to address in 2.x development. In the meantime, it's about time for a Commerce 1.4.

Comments

I have been working with Commerce since it's initial release. I have sent out a number of commerce sites out into the wild. Commerce core works like a hot damn, but the problem is in contrib. There are tons of half-baked concepts/modules and hacky workarounds to address the issues below. It seems that because almost everything can be solved using rules/views in Commerce, so is no attention given to actually making a solid universal approach to any of these issues. There needs to be some serious attention paid to these if Commerce is going to make it. Smile

1. Recurring Payments
2. Site Subscriptions/Roles
3. Coupons and Discounts
4. Invoicing/Partial Payments
5. Sales Reports

Good feedback, much obliged. Smile

I don't suppose you've had a chance to review the 3.x branch of Commerce Reports since the Google Summer of Code ended? Christophe put quite a bit of work into it, and I'm sure he'd appreciate your feedback. I recently put it on my cheese site and will be pitching in where I can.

Thanks Ryan, I will check out the 3.x version of Reports. I know you and your team (and the rest of the community) have been putting a tremendous amount of wok into commerce. I think it's time to start tying some nice bows around commerce contrib. A good example of what I mean is in Invoices/Receipts. There are literally 5 or 6 half-baked solutions to this.

http://drupal.org/project/commerce_invoice
http://drupal.org/project/commerce_pdf_invoice
http://drupal.org/project/commerce_email
http://drupal.org/project/commerce_invoice_receipt
http://drupal.org/project/commerce_invoices

All taking their own approach, addressing only a portion of the problem with little or no collaboration between them. The community has always looked to you Ryan for direction in Ubercart/Commerce and I think we need you again on the gaping holes in contrib. Smile

I could not agree more. I have spent more time fiddling with invoice display, emailing and printing than I have on the entire commerce core, contribs and setup combined.

If I had any idea that this important step was virtually left in the cold on Commerce I would have certainly looked elsewhere for my shopping cart solutions. I had such a good experience with Ubercart that I held the impression Commerce would have been much more complete.

I am still searching for a nice invoicing solution. A nudge in the right direction would be helpful.

Hi,
I too am looking for a good invoicing solution and have tried Drupal Commerce with the Commerce Invoices module which I thought was the best of the 'half-baked' solutions mentioned, lol. But the module does not produce invoices that can then be seen and paid by clients after the client logs in. I wanted to ask garyg if Ubercart does create invoices that clients can login and see and pay online.

Thank you, Hank

Nope, and in fact, that's a bit of disconnect between the language used in eCommerce and in the real world. I'm with you - an invoice is something I draft and send to a client to pay. It seems in eCommerce, or at least in the Drupal community, an invoice is more of a receipt for a completed order.

However, because of the way Drupal Commerce works, you actually can create an order as an administrator, assign it to a user, and send it to them as their invoice. They can then access the checkout URL for that order to pay the invoice. In this sense, Commerce does enable actual invoicing. In this scenario, you just wouldn't use the Cart module.

¿Did you have in mind to explain how to use the new features of kickstart in a old drupal 7 web?

Yep, we'll be documenting it and developing a training curriculum around it. Fortunately, most of the modules are existing contrib modules, and those that are just a part of Kickstart 2 itself will now begin to be released as separate projects when possible.