# Summary

Provides a full-featured e-commerce module suite for Drupal!

# Project URL


# Where is the code?


# Estimated completion date

Q1 2017

Main progress issue: #2845500: Release 2.0-RC1.

# Dependencies


# Who's doing the port?

The Drupal Commerce community, lead by bojanz and mglaman from Commerce Guys.

# What help do they need?

Contributions to various back-end development tasks is always welcome. Commerce 2.x office hours are held in the #drupal-commerce IRC channel weekly at 1400 UTC on Wednesdays.

# D8 roadmap / Status updates


# Kanban board


# Background and reference information



Kazanir created an issue. See original summary.

webchick’s picture

Priority: Normal » Major

This module's kind of a big deal. :)

mglaman’s picture

Issue summary: View changes

Linking to the Commerce 2.x ContribKanban board.

webchick’s picture

Issue summary: View changes

Maybe a better link to 8.x roadmap.

Berdir’s picture

Issue summary: View changes

Added a link to a new fancy blog post from @bojanz

subhojit777’s picture

Issue summary: View changes

Just talked to Bojan on IRC, the office hours is at 1400 UTC

bojanz’s picture

Issue summary: View changes

Updated the list of blog posts. We're aiming for an alpha by the end of the year.

webchick’s picture

Noting that this comment https://drupalcommerce.org/comment/11915#comment-11915 more specifically suggests alpha1 for end of december and a production ready beta1 for end of february.

bojanz’s picture

Issue summary: View changes

Added latest blog post.

bojanz’s picture

Issue summary: View changes

Alpha1 has been released on Christmas: https://drupalcommerce.org/blog/43496/commerce-20-alpha1-released
Alpha2 in two weeks.

webchick’s picture

Status: Needs work » Needs review

Awesome! :D

bojanz’s picture

Alpha2 has been released: https://drupalcommerce.org/blog/43978/commerce-20-alpha2-released
Onwards to alpha3.

The way our workload looks right now, I doubt we'll be production ready before end of March. We'll see when alpha3 happens.

Londova’s picture

Is there any option to set-up exchange rates from Commerce Currencies?
We need such facility as we may have products imported in different currencies.
I tried to install CURRENCY module (not sure if it has any link to the Commerce Currencies), however it required module PLUGIN pre-installed. There is actually a conflict between PLUGIN and STATE MACHINE modules.

I did report the issue to the developers of PLUGIN module, however no any replay so far. Hope you can help to find the solution for setting the exchange rates.

bojanz’s picture

This is not an issue for bug reports of any kind. You can open a bug report for that in the state_machine issue queue.

Currency has no relation to the Commerce project, we have our own matching functionality (though no exchange rates, since you usually want to specify a precise amount for each currency, automatic conversions are more of an edge case).

bojanz’s picture

prjcarr’s picture

Awesome work so far! Any estimates on when Commerce will be production ready? Is end of March still possible?

doncheks’s picture

Good Work guys.The progress is impressive.Can't wait for a production ready beta.Cheers.

bojanz’s picture

We're going to tag a last alpha next week, and target beta1 for when Drupal 8.1 RC1 is released. That's scheduled for April 9th, so it doesn't deviate much from our "end of march" schedule.

Londova’s picture

In this comment https://www.drupal.org/node/2689577#comment-11006815 is stated:
"Entity API and Commerce can't be used on Drupal 8.1."
Why not public such information in a visible place, so people who want to use Drupal Commerce don't upgrade to Drupal 8.1 ?
I do appreciate your efforts as developer however the communication need to be more efficient to avoid spending unnecessary time.

agoradesign’s picture


You should not forget, that Commerce is still in alpha stage, releasing its first beta in about two weeks. The features already existing have a great test coverage and working well, but they aren't complete. Thus, you will never want to run an alpha release of Commerce 2.x in production, as it is still lacking some functionality.

Next, Commerce depends on Entity API. Due to several improvements in core's entity api, the contrib module Entity API will have its own branch for 8.1.x, which will be much more lightweight, as many features are in core then. But currently, this branch in Entity API is not ready yet. There is an existing pull request on its Github repository, that may be used as patch to get Entity API working for 8.1.x.

Commerce uses several parts of Entity API, implements their interfaces, etc. Some of these parts have to be rewritten, as some of the used classes or interfaces they are based on, will no longer exist in Entity API for 8.1.x (as core features these features now). This fact implies that Commerce cannot be 8.1.x compatible at the moment, as Entity API isn't at the moment. At max, a pull request could be made for preparing Commerce for the upcoming changes.

However, starting at the first beta release, where all this stuff will be done, Commerce will DEPEND ON 8.1.x, and it will no longer be possible to install on 8.0.x.

So, regarding core compatibitliy, we're stuck at the moment in some kind of egg & chicken problem. That's the risk of early adopters. From my perspective I can tell you: well, of course not every feature is implemented yet, and yes, sometimes you find some problems and/or have to find some workaround for unfinished parts, but on the other hand, you can rely pretty well on the things, that are already implemented. This is really high-quality stuff with a very high test coverage. Especially bojanz is making an incredible job here. I highly respect his work. Additionally, I really love the concepts and ideas behind 2.x. And everything is based on the great new Drupal 8 - that are all reasons, why I took big risks and started a Commerce 2.x project shortly, instead of playing safe and use D7...

Londova’s picture

I don't dispute the way you decide to develop and implement the projects. I am sure you and your colleagues are doing all the best.
I am not happy with the communication - the way you inform the users about your plans (for example that Entity API and Commerce can't be used on Drupal 8.1). The lack of information leads to a lot of time spending, making users unhappy and thus leaving the Drupal in favor of other CMS.
You can consider this information as a feed-back and as an opportunity for improvement.

bojanz’s picture

When it comes to alpha software, there are no users, only contributors :)

That said, it's a fair point. Communication has suffered as I've been working hard to implement Checkout. I'll try to do better.

Thank you for your support.

Drupa1ish’s picture

@British-Link, you're missing the whole point of Drupal community spirit...
Instead of just making a note about it and link it to other relevant issues, you put the blame on @bojanz. It's a developer ( a brilliant one), not Batman. You're ready to use an enterprise free software, but I don't see no contributions on your profile... Wouldn't be nice to warn other users about your experience, in an elegant manner, instead of big words, like leaving Drupal?

Londova’s picture

I am NOT a coding developer, but I do manage several projects. All my projects were previously on different platforms and I decide to move to a single platform - Drupal. So my contribution could be as an implementer/tester and feed-back. That exactly I did until now. My mistake is that I used "dev" and "alpha" version of modules, what probably I shouldn't. However in Drupal-8.1.0-beta2, I did not find any information about incompatibility with Drupal Commerce.
I did NOT blame anyone, this is not my task. I just mention there are some week points in communication, which may need improvements. This is the lack of the system, not of the person. But people can improve the system...

agoradesign’s picture

It's not a mistake per se to use dev and alpha versions. Sometimes this is even necessary. Some modules stay long in alpha or beta state, event if they are working already fine and have thousands of active users. When I do this (using an dev/alpha version), I always have a look at the issue tracker first, and for every incremental update of theses modules, I also look at both issue tracker and last commit messages. And I recommend this to everyone, who also does this.

In case of Commerce, Bojan already excused that the current compatiblity state wasn't clearly defined on the project page - it was hidden on one or two issues in the Commerce issue tracker.

You will for sure never find on the release info of a Core release, that module X is incompatible. That belongs to the module, like Commerce and Entity API here. However, you will always receive very detailled information on every Core release, especially when it comes to new features and API changes (plus there is a list of change records, where API changes/additions/removals are documented).

If you're not a coding developer (or aren't having one in your team), I wouldn't recommend Commerce 2.x at all at the moment. I would say, not before Q3 - or what do you think @bojanz?

In this case, it would be better to use D7 with Commerce 1.x, where you'll also find a huge list of contrib extensions, which of course also are more than currently for Commerce 2.x - maybe another aspect, which will be for interest for you...

Londova’s picture

I'll give an example:
With Drupal-8.1 beta1, the Commerce was working, but when I updated the core to Drupal-8.1 beta2 it doesn't (incompatibility issue due to big changes in the core). I am lucky, I was able to reverse to Drupal-8.1 beta1 to use Commerce.

How to avoid situations, when updating the core (or a module), to keep other parts fictional? How would I know which parts of my site will be affected? Is there any guaranty that this wouldn't happen while updating the core from Drupal 7.43 to Drupal 7.45?

mglaman’s picture

British-Link, you are correct about visibility in compatibility between contrib and Drupal core. Drupal 8 introduces semantic versioning and a new development life cycle. So not only are we in a growing pain of developing, but also uncovering the issues with constant core development and contrib development.

For instance, the Entity issue. Entity is developed against 8.0.x (because it's technically the stable Core release.) However, 8.1.x saw part of it ported to core, breaking it due to a conflicting procedural function name for a theme hook.

We're seeing this issue for tests run on Drupal.org - Profile module's tests can run until Entity issue resolved, and even the Examples modules. We currently do not have a way to specify "This module has been tested and developed against version 8.X.x"

So please, bear with us in this technical difficulty of a situation. Also, as a non-technical person, providing feedback in proper channels to give maintainers better visibility and communication of changes would be a big help.

As a co-maintainer of Drupal Commerce and working on 2.x, I was even thrown for a loop. However, it's not something we can really control. As I said before, even though it's rapid development, it would be much easier if we could identify a project works against X minor release.

EDIT: Useful link #2663018: Useful core branch defaults for contrib CI

bojanz’s picture

As you can see, we didn't meet our march deadline for the production ready beta.

We spent more than half of last month on the following things:
1) Merging Entity API classes into Drupal core (and debugging them in the process)
2) Developing a solution for updating config in Drupal core (that we'll use in our upgrade path)
3) Chasing Composer issues
4) Fixing various Inline Entity Form bugs (which block our product UI from working properly)
All of this took significant time from Commerce, which has only me as a full time contributor.

Our new estimate is end of April, if we're lucky.
We'll be releasing a new alpha with initial Checkout functionality soon, as well as posting the payment architecture plan that will be executed right after.

If we're to get to a beta faster, we need contributors willing to spend long periods of time on Commerce or blocking issues (in Drupal core, Entity API, Inline Entity Form, Profile, etc). The reason why I said "long periods of time" is because it takes time for contributors to ramp up on D8, that can't be done one friday a week.

Thanks to everyone who has been reporting bugs and providing feedback for the current code.

bojanz’s picture

Issue summary: View changes

Released alpha4: https://drupalcommerce.org/blog/44305/commerce-20-alpha4-released

Closed the commerce_checkout_redirect porting issue since we now ship with that functionality: #2627006: [commerce_checkout_redirect] Commerce Checkout Redirect.
Also closed the commerce_checkout_progress porting issue since -dev (post-alpha4) contains a checkout progress block.

DrupalGideon’s picture

Great work. The installation is so much better! Well done all involved. I look forward to trying this out some more on the weekend.

jmoruzi’s picture

Where are you at on this guys? Do you have a target date for beta release yet?

silkogelman’s picture

More info about the beta1 plan can be found at #2733869: Tag 2.0-beta1

webchick’s picture

Issue summary: View changes
Londova’s picture

Do you plan to include in Commerce Development the Domain Access for Products?
I addressed this question to Domain Access developer and here is his reply: "I don't intend to support in the core module. Drupal core doesn't provide a native access control API for all entities, just for nodes."
If this is true, is there any chance to extend the Drupal core API functionality to Commerce Products?

bojanz’s picture

There is no plan for that. We will review patches if someone else decides to do it, of course.

bojanz’s picture

Issue summary: View changes

There's now a beta1 and beta2, an upgrade path from this point on is guaranteed. Read the blog post at https://drupalcommerce.org/blog/45961/drupal-commerce-20-enters-beta

navi85sin’s picture

Anyone got any idea when will the D8 commerce version will get released?

bojanz’s picture

The current release is beta3.
Beta4 is scheduled for November 30th: #2823925: Tag 2.0-beta4.
RC1 could be around new years, depending on contributions.

We've also been busy on shipping: #2761041: [META] Commerce Shipping 8.x.

bojanz’s picture

Issue summary: View changes

Updating information, linking to the beta4 release notes.

Beta5 is next, on Monday the 26th: #2838042: Tag 2.0-beta5.

Londova’s picture

Do you plan any option to setup exchange rates in Commerce?

alisaeedi’s picture

Assigned: Unassigned » alisaeedi
Category: Plan » Feature request

Please add options for selling files in the core of module.
The module "commerce file" support only drupal7 up until now!
do you have any plan to embed that in the core or distribute as the separate module for selling digital goods with version 8?

mglaman’s picture

Assigned: alisaeedi » Unassigned
Category: Feature request » Plan
bojanz’s picture

That stays in contrib (commerce_license & commerce_file), just like the Shipping module.

bojanz’s picture

Issue summary: View changes

Added a link for the RC1 roadmap: #2845500: Release 2.0-RC1.
We'll also do a beta6 on Jan 31st: #2845495: Release 2.0-beta6.

The RC1 roadmap also contains a list of the most popular Commerce 1.x contribs, and their status:

Numbers for the lazy:
Out of 60 Commerce 1.x contribs, over 20 are no longer needed for 2.x
Meanwhile, the 2.x tarball is still smaller than 1.x :)
in addition to that, Shipping 8.x ate 5 modules (flat rate, physical products, box, shipment, fulfillment)

philsward’s picture

Sorry if I'm hijacking, but I'm curious what the plans are for composer and Commerce? I tried beta5 a while back and I was never able to get through errors presented by "zone". In a perfect Drupal world, composer should be an optional component for developers and unnecessary for site developers. This is mostly the mindset with core, however it doesn't extend to contribs. I'm not a developer and over the last year of playing with Drupal 8, composer has been nothing but a PITA in regards to even being able to play around with Commerce or other modules that now require composer to download external libraries. I realize this is a bad attitude to take, however I don't care to know how to use composer. At this point in time, my perception does not include it helping my current workflow. I just need composer to update stuff quietly in the background so I can focus on the task at hand. In various areas of social Drupal circles, I have found others to have the same mindset as me (so I know I'm not alone) however core has not taken a front seat approach to fixing this problem at the macro level so it is taken care of at the micro level. Maybe because the current list of modules that use composer for external libraries is small to worry about it? I guess that's why I'm asking here. Commerce is at the forefront of using required external libraries.

So, what is the roadmap to getting the 3rd party dependencies required by Commerce, to play nice with composer where the average site builder won't ever need to mess with it? I'd love to test and watch the progress, however I struggle to install Commerce, every time I try. (I'll try beta6 when I get a chance)

bojanz’s picture

Our docs present a single command to get a full D8 site with Commerce ("composer create-project drupalcommerce/project-base mystore --stability dev").
There are no known issues around it, I'd be happy to chat on IRC to find out what your problems were.

The same page documents the two needed commands to add Commerce to an existing site. Once Drupal 8.3.0 is released, that too will be a single "composer require" command (cause core will ship with the d.o repository already added).

Composer not only gives us a single unified documented way to keep a site up to date & apply patches, but it also gives us the opportunity to use any available library, downloaded for us automatically, which matters a lot in the world of payment gateways and shipping methods.
If it was possible to make Composer optional, we would have already done it. I realize that requiring Composer (or any kind of tooling) will alienate a part of our user base, but that's a price we must pay.

mglaman’s picture

Also, if you do not want to have to work with Composer in the command line I would love users to try my Composer GUI and open feedback tickets https://github.com/mglaman/conductor. There is a Windows executable. It ships with Composer. It just needs testing and requirement feedbacks from users (as I don't use it.)

philsward’s picture

Thanks @bojanz. I do like the initial thoughts on #2538090: Allow the Update Manager to automatically resolve Composer dependencies. I'll keep an eye on it. I imagine the end goal is to have Drupal handle the dependencies of contribs like Commerce.

One question... Is this geared towards a local -> live workflow only? Or will it work with a "live only" workflow? If it's designed for a local -> live workflow, it won't help out because I don't work local :/

webchick’s picture

From https://www.drupal.org/node/2845500#comment-11992651, 5 days ago:

We have a beta6 now (with support for multiple payment gateways at checkout), and we have a Shipping beta2.

A new target for RC1 is DrupalCon Baltimore, with a beta7 that contains the final payment/promotion work at least.

zenimagine’s picture

Hello, is the commerce module usable in production on drupal 8? thank you

Lukas von Blarer’s picture

There are sites running it in production, but it is still in beta. There will be an upgrade path, but some things might still change. Taxes are not done at all and some stuff regarding payments is also not done yet.

zenimagine’s picture

thank you for your reply. I want to create a marketplace and I see that "commerce 2" allows to do this.

This avoids using the module "group" with drupal 7.

It is written on the page of "commerce" that it is necessary to install "composer".
I do not understand what it serves, the installation of "commerce 2" seems complicated.

1) In the final version, will it also install "composer" ?

2) If I install Commerce on drupal 8, will it have to be reinstalled at the next update? Or just update the Commerce module.

bojanz’s picture

We have released our last beta: https://www.drupal.org/project/commerce/releases/8.x-2.0-beta7
Now includes a very powerful tax module, and many improvements to promotions.

Next stop, RC1.

zenimagine’s picture

bojanz’s picture

Issues in the contrib_tracker issue queue are for tracking the porting status of modules.
They are not for bug reports, feature requests, or support requests.
Please post your comment as an issue in the Commerce issue queue, and remove this one.

bojanz’s picture

Status: Needs review » Reviewed & tested by the community


It can be installed without Composer.
It has a bunch of new features.
And it requires you to read the release notes if you're updating from a beta, because we broke payment gateways.

Refer to the list of payment gateways to track us updating the 30 known 2.x payment gateways for RC1.

zenimagine’s picture

In the context of a marketplace, do you think it is possible to link several payment accounts with the shops?

For example I have a maketplace site and I rent shops to merchants.
I would like each merchant to open a PayPal account and link it to his shop.

bojanz’s picture