Drupal Commerce Blog

What's happening in the world of Drupal Commerce.

Drupal Commerce 2.0 Enters Beta

During the Commerce 2.x session at DrupalCon Dublin we officially tagged Drupal Commerce 2.0-beta1, our first production ready release. This does not mean it is feature complete or bug-free, but it does mean that from this point on, we support updating between 2.x releases - a key requirement for production usage. Start a Drupal 8 eCommerce site today, and you will be able to update your way to the full 2.0 release and beyond.

Matt and Ryan at DupalCon Dublin
Photo credit Will Jackson during the "Launching online stores with Commerce 2.x on Drupal 8" session.

For a quick overview of our project philosophy and the improvements we've included in Commerce 2.x, watch our session from DrupalCon Dublin.

The session heavily features the Sport Obermeyer case study, one of the first major eCommerce projects built on Drupal 8 by Bluespark and Commerce Guys. Their project influenced and shaped Commerce 2.x development in a big way, validating our ideas and providing solid use cases for features like fancy attributes, promotions, coupons, and more.

Additionally, we helped build the project as a single site serving three unique customer personas with a different purchasing workflow for each one. That drove development on our add to cart and checkout flow APIs, ensuring they have the needed flexibility to allow parallel implementations from day one. In addition to the case study linked above, check out Matt Glaman's interview with Bluespark for more information.

So... what has changed since alpha4?

Read on to find out...

Bojan Zivanovic's picture
Posted: October 6, 2016

Commerce 2.x: Unit, Kernel, and Functional Tests Oh My!

At the end of May, I made an initiative to move all of the Drupal Commerce tests away from Simpletest and to use the available test classes built off of PHPUnit. Why? Simpletest is a test framework within Drupal and not used by the PHP community at large.

With the KernelTestBaseTNG™ issue, Drupal core officially moved to being based on top of PHPUnit for Kernel and Unit tests. Soon more test types were to follow, such as browser tests and JavaScript testing.

Death to Simpletest, Long Live PHPUnit, Mink, and PhantomJS

We now have PHPUnit as our test framework, the choice of the greater PHP community. The browser tests use the Mink browser emulator, which anyone working with Behat should be somewhat familiar. Testing JavaScript is done by pointing PhantomJS configuration to Mink. No longer are we limited to the functionalities of Simpletest and our community to develop it.

Matt Glaman's picture
Posted: June 21, 2016

Enabling Fancy Attributes in Commerce 2.x

In Drupal Commerce 1.x, we used the Commerce Fancy Attributes and Field Extractor modules to render attributes more dynamically than just using simple select lists. This let you do things like show a color swatch instead of just a color name for a customer to select.

Fancy Attributes on a product display in Commerce Kickstart 2.x.

In Commerce 2.0-alpha4, we introduced specific product attribute related entity types. Building on top of them and other contributed modules, we can now provide fancy attributes out of the box! When presenting the attribute dropdown, we show the labels of attribute values. But since attribute values are fieldable, we can just as easily use a different field to represent it, such as an image or a color field. To accomplish this, we provide a new element type that renders the attribute value entities as a radio button option.

Read more to see an example configuration.

Matt Glaman's picture
Posted: May 3, 2016

Commerce 2.0-alpha4 released

Almost two months and seven thousand lines of code later, here's Commerce 2.0-alpha4. This release brings checkout and revamped product attributes. We've also added upgrade path APIs in preparation for beta1. Meanwhile, we helped push Drupal 8.1 out the door and fixed many Inline Entity Form bugs.

The new checkout flow configuration form.

Reminder: Commerce 2.x alphas are NOT production ready. No upgrade path is provided between alphas. A full reinstall is needed each time.

Read on to find out what's new...

Bojan Zivanovic's picture
Posted: April 28, 2016

Upgrade paths between Drupal 8 module versions

Over time, modules update their shipped configuration such as rules, views, node types. Users expect to get these updates when they update the modules. For example, Drupal Commerce 1.x provides over eleven default views and rules. From release to release, these Views and Rules were enhanced with new features or bug fixes reported by the community.

Take the order management view. In a future release of Drupal Commerce, we may add a newly exposed filter to the view. In Drupal 7 the view would automatically be updated unless it was overridden. That is not the case in Drupal 8.

Drupal 8 introduces the Configuration Management system. While robust, it changes how we work with the configuration in comparison to Drupal 7. Instead of a module owning configuration, configuration is now owned by the site. When a module is installed, its configuration is imported. On module update, no configuration updates are performed. Instead, the module must write an update hook to perform one of the following updates:

Matt Glaman's picture
Posted: April 22, 2016

Commerce 2.0 alpha3 released

It's time show you what's kept us busy in February. Say hello to alpha3! Aside from the many bug fixes, the focus is on improving cart functionality. We've also been busy stabilizing Inline Entity Form, with dozens of commits and two new releases.

Reminder: Commerce 2.x alphas are NOT production ready. No upgrade path is provided between alphas. A full reinstall is needed each time.

Read on to find out what's new...

Bojan Zivanovic's picture
Posted: March 2, 2016

Commerce 2.0 alpha2 released

The holidays are a distant memory, and Drupal 8 contrib work is happening in full force. Time for another 2.x alpha. The past three weeks have seen bug fixes, test work, and many internal cleanups. But let's focus on the bigger changes.

Reminder: Commerce 2.x alphas are NOT production ready. No upgrade path is provided between alphas, a full reinstall is needed each time.

Read on to find out what's new...

Bojan Zivanovic's picture
Posted: January 22, 2016

Commerce 2.0 alpha1 released

2016 will be the year of Drupal 8 and Commerce 2.x projects.
In order to start tracking our progress towards our first productive ready release (which will be beta1), we're releasing alpha1 of Commerce 2.0.
Behind the scenes we've also created new releases of several dependencies: inline_entity_form 1.0-alpha3, profile 1.0-alpha1, and state_machine 1.0-beta1.

Download alpha1 here, then follow the installation instructions in our documentation.


Bojan Zivanovic's picture
Posted: December 25, 2015

Contributor Spotlight: Josh Taylor

Say hi. (who are you and what do you do in the Commerce ecosystem)

Hello! I'm Josh Taylor, a PHP Developer living in Melbourne, Australia who focuses on Drupal 7/8 and Symfony2 projects. I've been involved with helping Commerce 2.x in my spare time (not as much lately due to time constraints) to help make it the go-to eCommerce platform for users.

How did you get involved with contributing to Drupal Commerce?

benjy (Ben Dougherty) mentioned that Drupal Commerce was in the planning phase. I got really excited and checked it out, and started to contribute back small fixes with the help of bojanz (Bojan Zivanovic). Then I just kept going - I hope to contribute more back in 2016 when I have more time, especially as clients start to move onto Drupal 8.

Stephen Weinberg's picture
Posted: December 14, 2015

Commerce 2.x Stories: Workflows

Now that we’ve covered products, it’s time to jump into orders. We are improving many aspects of orders based on previous feedback. One such aspect is the concept of order statuses and states.

In Commerce 1.x orders have a status. The status indicates the current checkout page, whether the order is a cart, whether it has been paid and fulfilled (shipped), or maybe cancelled/refunded. Statuses are sequential, one goes after another. They are grouped by states, e.g. all checkout statuses belong to the “checkout state“.

The problem with this model is that one list of statuses indicates multiple concepts (checkout state, payment state, fulfillment state, etc). These concepts are parallel and trying to handle them sequentially creates bugs and confusion. For example, an order might be paid before or after checkout completes due to the async nature of certain payment gateways, or because the business is invoicing clients at the end of the month. Furthermore, there is no requirement for the status to change sequentially, it can be set to any other status at any point. There is no way to express rules such as “only completed orders can be refunded“ or “completed orders can’t be sent back to checkout”.

Read on to find out how we're fixing it...
Bojan Zivanovic's picture
Posted: December 10, 2015


Subscribe to Blog