Commerce 2.x roadmap

I think it is worth adding a note about Commerce Recurring getting to at least an alpha

Thank you for all the efforts Bojan, Matt.

We went a long way to build our new version of the site. We implemented some custom functionality mainly for address management, tax calculations, promotions, price formatters and checkout steps. We would be happy to share our experience about this with anyone interested in another medium. We saw that for the current state of Commerce, those issues were the most important for us, in priority from top to bottom.

#2897190: Tax calculations do not take discounts (promotions) into account
#2903716: Implement the ability to add fees to an order
#2805549: Expand the "Calculated price" formatter with the ability to show prices with promotions/taxes/fees
#2910193: Allow reusing profile values from another inline form ("Billing same as shipping")
#2831952: Create an entity_print renderer for orders (to allow order PDF output)
#2898215: [meta] Handle deletion of Commerce entities that are in use
#2902882: Allow for bulk creation of coupons

We also had an issue with calculating tax needing address. Many shops serve to one country only and tax doesnt change by location. We modified the tax code in a custom module, tax calculations to be made before address selection without taking the location into account. Maybe there can be an option for this somewhere.

My priority list:

1. Extra address fields: additional name, house number, house number additive
   Currently solved by extending a bunch of address classes and replacing the default address field on the commerce customer profile with a custom one. May cause issues if we would add a credit card payment option on a later stage. Alternative solution would be to add extra fields on the customer profile, then show these fields between the other address fields by using a form alter.
2. Integrate the RNG module with Drupal Commerce
3. #2897190: Tax calculations do not take discounts (promotions) into account
4. #2857157: Implement registration after guest checkout
5. #2844920: Allow customer profiles to be reused
6. Ability to use a checkout pane more than once (with different settings)
   Currently solved by extending the checkout pane in a custom module. Specifically the checkout panes that I want to reuse are the Review checkout pane and the Order Summary checkout Pane. Use case: the Review pane should be shown on top on each step after the first step and until the "Review" step. The Order Summary pane should be shown on the sidebar, except on the "Review" step where it should be shown on the main section of the checkout form. Remains custom
7. Split the payment information pane into two panes: one for billing address, one for payment
   Currently solved by extending the billing information pane from the Commerce Checkout module and the payment information pane from the Commerce Payment module in a custom module. Remains custom
8. #2910193: Allow reusing profile values from another inline form ("Billing same as shipping")
   Currently solved by extending the billing information pane and the shipping information pane in a custom module.
9. Commerce Feeds
   This should be doable for me, as I'm the current maintainer of Feeds.
10. iDEAL payment method
11. Commerce Popup Cart
    Commerce add to cart confirmation

We would also like to see this issue in the future:
#2915432: Fieldable Promotion and Coupon entities (and UI)

Currently we are using a custom module for this.

11. Commerce Popup Cart

How is this different from the cart block that ships with 2.x?

Oops, I selected the wrong one. I meant Commerce add to cart confirmation. Apparently, I had forgotten the module name and figured it was called something like "popup".

7. Split the payment information pane into two panes: one for billing address, one for payment

#7 doesn't make sense when allowing payment methods to be saved and reused (ala cardonfile), so it's a contrib that would only make sense on sites that use a single offsite gateway.

In my use case I ask for the user's contact information (name, mail address, function, company, address) on the first step. On the second step, conference information is asked (which can influence the total price). The contact information needs to be asked earlier because these provided details have influence on what is being asked during the second step. And at the third step a payment method is asked (the total price is then final). In this scenario it does make sense to have separate panes for billing address and payment method. If you ask for address information on the first step, it doesn't make sense to ask for it again later in the process.
But I'm fine with keeping this custom. I just saw this request a couple of times in the issue queue, so I guess more people want a checkout workflow similar to the one described above.

+1 for paperwork

#2831952: Create an entity_print renderer for orders (to allow order PDF output)

As for contrib. A start on commerce_pricelist would be good to see too.

Also, in october:

Commerce Migrate: 8.x-alpha3
Commerce POS: 8.x-alpha1

Migrate alpha 4 and Commerce POS alpha 2 will both land on Nov 8th

#14: I love those kinds of no-nonsense, information-dense status updates! 👍

It makes sense to include Shipping as part of the Commerce.
Commerce without Shipping is an incomplete system. Almost about 90% commerce sites are for tangible products, and Shipping is a must.

@Londova We've heard "Commerce without X is incomplete (or worse, worthless)" for years, but the reality is our small core has proven itself wise. Less than 50% of Commerce 1.x sites used the Commerce Shipping module - Drupal is unique in this regards vs. most other platforms in that we're widely used by events, non-profits, etc. that don't ship things.

That said, we've also always maintained Commerce Shipping along with Commerce core. https://www.drupal.org/project/commerce_shipping is more capable than ever for Commerce 2.x and has not had its progress hindered for being in a separate project than core. Keeping it up to date is part of our maintenance plan. : )

Hello,

We are willing to use Drupal 8 and Commerce 2 to make our own marketplace. Is Commerce 2 mature enought ?

We noticed that : when you order several products from several shops, you have to check out for each shop. Which can be relunctant for customers... Have you planned a way to display the order for each shop but have ONE button to checkout wich will call a script that process all the orders at once and use a system of paiement specialised in marketplace.

Sorry for my english.

For your information I'm totally new to Drupal.

@bojanz : Thank you for your quick answer.

@Gilles - I have a marketplace using Braintree's API set up in a fashion similar to what you are considering. Feel free to e-mail me or ping on Slack. It's based on https://www.drupal.org/project/commerce_braintree_marketplace

Removing #2723691: Add Panels integration for variation fields. It doesn't seem possible in Panelizer's current state. There will also field layouts in core and there hasn't been too much chatter about it.

@bradjones1
Hello
I am working with Gilles and interested with informations regarding your Braintree setup.
I have a look at Braintree Marketplace but it seems to be only available in $ and US. But we are in Europe...
Can you confirm this is the features your are using ?
Thanks in advance
Gildart

@Gildart, I don't think anything in the Braintree Marketplace module should preclude you from using a non-USD currency, and the marketing indicates it's available in all countries they are present in, so if you need specific support on that please reach out to me directly.

Happy new year to everyone!

This is a nice list, most of the issues I needed to patch while setting up commerce are already on it! I would like to add #2770731: Add a display name to promotions

Also, since this is the 2nd Wednesday of January, I was wondering if this part of the summary still stands:

There will be a Commerce 2.x release every first Wednesday of the month.

Keep up the good work! :)

#21 rszrama
Commerce couldn't be considered ready without Shipping (even if it is a separate module). And the turnover of tangible products is still much higher. I do not want to be in the role of a critic but something is going wrong.

It may be a good idea to setup a marketplace for paid modules and to move on. From the point of view of the Project Manager, this is much better than to develop custom modules.

Hi ,
i reposted stuff here ,
Only one thing trouble me , i didn't see any " customer rating / reviews product " feature ,
i dont understand it seams to be a basic feature and very important today . Did i miss it ?
I saw ' the fivestar ' module but this is not the same .
We need to allow customers who only purchased this product to rate / review this product .
I don't see how to code that and it is a very important basic ecommerce feature don't you think ?

@guidrup

It's a feature that interests me a lot. I had a problem with this for Drupal 7. Right now "Fivestar" is not usable and is not about to be used because of "Voting API". I have not found any voting solution for Drupal 8.

Maybe the solution could be the "Webform" module.

Thanks for great work
One comment - support partial payments better eg for 'offline' payment methods https://www.drupal.org/project/commerce/issues/2935337

im sorry to admit that im switched (for the moment) into woocommerce for reasons i mentionned (lack review/rating for purshased customer),
i guess this is normal in beta but since the pb still here even in drupal commerce premious version ..
Im develloper and even i found the hard learning curve too hard .. I mean this is so a basic feature in ecommerce , very strange to me ..

@@bradjones1
Thanks for your reply.
I presume it can be a legal issue with Euro zone. In this article (https://articles.braintreepayments.com/guides/braintree-marketplace/over...) they said :
Compatibility :
Both the master merchant and sub-merchants must be domiciled in the US and receive funding in USD
May be also this text is not updated ?
Do you know if there is a sandbox for marketplace tests in Braintree ?
Gildart

@bojanz

Super thanks for your work.
Currently if I disable product variations, the price, reference, and name of the variation will disappear.

Will there be soon, a way to replace the button "Add to cart" by a button "Not available" that is not clickable ?

@zenimagine This is not the right issue for this.

I guess you are looking for this issue: #2710107: Finalize the availability manager service

@Lukas von Blarer

yes that's it, thank you

re 'Commerce Stripe (getting an RC1 out once the community does more testing)' there is a pending patch for honouring proxy settings (https://www.drupal.org/project/commerce_stripe/issues/2906131) that it would be good to pull in.

Great work.

Any chance that issue/2923799 could receive some consideration?

bojanz Any update with regular releases or I miss some important information about pause? I found out that for https://www.drupal.org/project/commerce_shipping (dev - with Shipping Admin UI) I also need dev version of DC2 which I want to avoid in production. Thank you for great work.

Added links to contrib modules in issue summary to make navigating to them easy.

# bojanz
As published before, the deadline for Version 2.12 was February 1st.
Any information about the new deadline?

As there has not yet been a release in May yet and the Addressbook part 1 has been committed, are you planning on a May release? We have a pretty urgent need for this one and are trying to figure out the best way to get it into our code base.

Thank you for all your work on Commerce!

Any updates on the billing same as shipping functionality? Thanks for all your work!

Edit: Can someone explain how I can utilize the work around "#2910193: [Addressbook part 2] Allow reusing profile values from another inline form ("Billing same as shipping")
Currently solved by extending the billing information pane and the shipping information pane in a custom module." Or is there a way I can apply the patches early?

@christiahall For commerce Drupal Answers is the best place to get support; it's best to keep this Roadmap issue focused.

Any updates on the next release? Last one was in April, with a promised one in May.

@joshmiller
I read in an other issue that the next release is delayed because @bojanz would like feedback on the changes for addresses on checkout. I hope to take a look at these changes at the end of this week, if all my client work for this week is done.

@joshmiller
From #3053165-29: [Addressbook part 2] Complete the UI by allowing choice between multiple addressbook profiles:

Okay, since the initial reviews were positive, I'm going ahead and committing #13
(...)
Let's continue testing -dev. I won't tag 2.14 for another week. Thanks, everyone!

Immediate next focus: Finishing #3059633: Provide a better addressbook UI for the user pages

From #2910193-5: Allow reusing profile values from another inline form ("Billing same as shipping"):

We're finishing and committing #3053165: [Addressbook part 2] Complete the UI by allowing choice between multiple addressbook profiles first, which ended up taking significantly more time than planned. We might need to tag 2.14 before finishing this issue. Will post current code progress soon.

I think that I read that address book needs more testing from the issues above, but it could also be that @bojanz had mentioned it in Slack.

Adding admin order payments issue to the admin order UI section since I think it's getting close to done and is related to the stated goals.

Hi all! And thanks for the huge work during last months!

I am writing to ask if this issue #2852207 Billing same as shipping can be included in the roadmap here, as I understand this one #2910193: Allow reusing profile values from another inline form ("Billing same as shipping") is not intented to work with actual version of Address Book.

Thanks again :)

The main issue i come across every time working with Commerce is that the admin checkout flow and customer checkout flow are completely different paths with completely different code. As a result, many pieces are missing from an admin checkout flow (i.e. a staff member taking payment over the phone, accepting a cheque, etc). I am not sure if the intent is to leave these to the developer as possibly they are assumed to be quite different from application to application; or more likely, focus has always been on customer flow (std cart checkout).

As i feel this is a mandatory part of any feature being worked on (Fees is a good example); i am rarely sure if my comments posted to work in those areas is required to always be split off to a separate case to cover the admin use case. Some of these include:

payment methods are not available (recent patch for this), payment methods are not available unless also available to users, orders are not "placed" after payment is made, fees are not added to orders paid for by staff, manually editing an order and adding a Fee has no knowledge of the new Fee entities and i am sure there are many other examples of this.

So my hopeful addition to this roadmap is more of an architecture thing (so unlikely to get much love): but would be great if there was a tighter coupling between customer checkout and admin checkout so that use of the many feature additions are available to the admin checkout flow as well.

@liquidcms There is certainly a fundamental difference in expectations between the interfaces: there are things an end user can do that an administrator just can't do on their behalf or that don't work on a single page edit form (e.g. many payment methods). The order edit interface was never meant to be a like-for-like equivalent to the checkout flow, and I'm honestly not familiar with any other systems treating it as such.

For more complex use cases, is there something preventing CSRs from just using the checkout form? For example, I implemented Commerce in the past for a friend who wanted his CSRs to use a similar checkout flow as end customers, so we just made it so someone with appropriate permissions could choose to checkout a cart using someone else's email address. That was much simpler than trying to make the back-end interface as feature rich as their checkout form.

Would a general feature like that satisfy most of your use case(s)? I'm imagining something that could easily start as a contributed module that lets privileged users choose a checkout flow and user to checkout on behalf of but that doesn't try to recreate the whole checkout experience on the backend.

Adding related per above comments.

@rszrama, yes, that can be an alternative path to handle some of these issues. We have in the past considered simply masquerading as the client and going through the cart/checkout flow. Certain things wouldn't apply though as certain payment types (pay by cheque for example) won't apply for the customer.

Certainly a cart/checkout based on email address (but still within an admin's session) would be an improvement on the masquerade idea.

Best solution of course would still be that things worked for an admin as one would expect them to. "I'm honestly not familiar with any other systems treating it as such" - sorry, i doubt that is true as this is a pretty basic requirement for many/most ecom sites. I am pretty sure Ubercart in D6 (and likely D7) handled this correctly.

@liquidcms I'm more than happy to be corrected on that last point if you can point me toward documentation. For what it's worth, I led Ubercart development on D5/6 (think that's what you meant; ZenCart is a standalone offshoot of osCommerce) and can confirm that we definitely never supported back-end transactions to any degree equivalent to what the checkout form offered.

Consider, for example, 3rd party payment methods that require a username and password or 3DSecure and its equivalents that require a password. There's no scenario in which a CSR should be asking for a user's password for the sake of processing a payment over the phone, but supporting the same purchase flows on order edit as you do in checkout would open that door (or else hit that roadblock).

This is an interesting discussion, I think backend checkout flows would be very handy.

Consider, for example, 3rd party payment methods that require a username and password or 3DSecure and its equivalents that require a password.

CSRs can take CC payments over the phone and in person. They may also be able to accept cash and other payments in person. To support these cases, different payment options could be presented depending on who using the system.

One such option could be "external payment" within Commerce, while the CSR creates the payment directly within their payment gateway's interface.

@rszrama, yes, my bad.. i meant Ubercart. I have one client that has used Ubercart since D6. They definitely handle mailed in cheque payments; but I'd have to check on how they are doing that.

My current D8 client has a reasonable size of their business taking CC payments over the phone or mailed in cheques. So i am not talking about "3rd party payment methods that require a username and password"; i am talking about the extremely common practice of taking CC payments over the phone. To suggest this is not a common business practice seems a bit short-sighted to me (as i type this, an infomercial with those common words "Call Now!!") just came on the TV..lol

See also Commerce admin checkout.

@liquidcms Yeah, I agree, it should be possible to use the admin UI to process a CC payment that doesn't require 3DS or other security features. I've been reviewing the back end quite a bit lately, and there are a variety of things you can't do in Commerce 2.x from a site builder / CSR standpoint that you could in Commerce 1.x. The way you phrased it above (i.e. admin checkout flow) made me think you had something more robust in mind, but I'd love to see an admin payment terminal similar to Commerce 1.x in 2.x. There may already be a feature request for it - if not, feel free to open one. : )

Hi, any chance of adding support to the Payment Request API in the future?
Thanks

@eldrupalista the roadmap isn't the best place to discuss individual features, I suggest opening. a specific issue for that.

Commerce 2.21 is now out: https://www.drupal.org/project/commerce/releases/8.x-2.21

Release contains multiple new features and bug fixes, including:

• #2952529 - Layout Builder + Product support
• #2831952 - Entity Print for orders
• #3155132 - Checkout complete customizeable from UI, not just Twig
• #2908196 - Backoffice order comments
• #3153381 - Payments support AVS code logging
• #3134493 #3128322 - JSON:API fixes: order access, variations filtering

Roadmap is updated accordingly.

It's very usefull to create another commerce 3.x roadmap.