Damien, Yohan, Andrei, Jonathon Kuma. Talking through the changes in Drupal 8.

With the entity API maturing in Drupal 8 as it approaches its first beta, Commerce Guys gathered a variety of Drupal Commerce contributors and maintainers in its Paris office to begin active development on Drupal Commerce 2.x. The week long sprint began with architectural debate and validation incorporating the collective experience of our professional services teams and delivery partners.

Bojan going over entity architecture.

Drupal Commerce 2.x will ultimately be a complete rewrite, reflecting the drastic changes in Drupal 8 itself. We’re excited to announce that long-time community contributor and Commerce Guy par excellence Bojan Zivanovic has been added as a co-maintainer to help us make it happen.

Pizza for lunch! Left to Right: Maciej Zgadzaj, Jonathan Sacksick, Bojan Zivanovic, Yohan Tillier, Julien Dubreuil, Fabien Gasser, Franck Stauffer, Fred Marand, Richard Jones, Dan Polant, Ryan Szrama.

The Commerce 2.x kick-off sprint marks the first time Commerce Guys has brought together the Drupal Commerce development team with its office technical leads, key members of local delivery partners, and members of the wider Drupal community in Paris. We were honored to have special guests offer their feedback and advice, including Fabien Potencier of Symfony, Thomas Rabaix of Sonata, and Franck Stauffer of RBS Change.

One of our key goals for Commerce 2.x is to create and use a few generic PHP libraries that can be used by other eCommerce projects or as standalone pieces in custom PHP applications. Plans thus far include a pricing library (prices, taxes, discounts, fees) and an address library, both of which provide functionality currently missing in the PHP ecosystem.

Initial impressions and ideas from the sprint include...

Stores

Commerce 2.x includes a new store entity type, already committed to the 8.x branch on drupal.org. There are many potential use cases for such an entity type (multi-domain stores, multi-seller scenarios, fulfillment centers, etc.), and contrib has the opportunity to unlock them all.

Product architecture

Node based product displays are no more. Products can now be displayed on their own, with product hierarchies being managed via parent-child relationships within the product entities themselves. A product can now be viewed on its own or selected from its hierarchy group such as this one:

When you configure the architecture of a product type, you determine which “levels” of the hierarchy can be displayed at unique URLs, which should redirect to the parent URL, and which define actual purchasable SKUs.

This brings us many things:

1. Simpler Add to Cart form generation. We no longer need to load and process every product variation to recreate its attribute field hierarchy when the form is rendered. This information will be contained in the product type definition.
2. Field inheritance. Add an image for "Blue" at the second level and automatically use it for all sizes. Field inheritance will be configurable per field.
3. Faster product creation. This allows us to do bulk creation by reading the hierarchy information and creating the full set of variations as the Commerce Bulk Product Creation module supports today.

Discussing entity storage requirements with Yves Chedemois.

Prices

A price is now an object that knows how to apply a tax rate, discount, fee to itself:

The price object will handle the interactions between discounts and taxes, different rounding rules, cumulative taxes, and other complexities.

All this will be a part of a powerful pricing library (taxes, discounts, fees) that will be shared with the wider PHP community.

Coding time, Fabien Potencier and Jonathon Sacksick discussing interaction between Symfony and Drupal.

Taxes

With the guidance of David Kitchen, we're rewriting our tax handling to better support VAT and changing tax rates (19.6% until 2014, 20% from 2014) out of the box.

This means that european merchants won't need commerce_vat and commerce_eu_vat
anymore.

Payments

In Commerce 1.x the API for payment gateways is light in order to allow maximum flexibility, but it also provides room for bugs and duplicated effort for each new implementation. We're brainstorming a more structured API that would allow for lighter implementations. We're not yet sure where this API belongs (in commerce_payment, a library built on top of omnipay, parts of it in omnipay itself, etc).

We're also exploring the idea of integrating Omnipay, a light PHP payments library. This would give us access to a wide base of existing integrations, and allow us to co-operate more closely with the wider PHP community.

Long days, but great work. Fabien Potencier (Sensio Labs), Fabien Gasser (Smile), Thomas Rabiax (Ekino, Sonata lead), Jonathon Sacksick, Fred Marand (OSInet), Chris Merritt, Dan Polant, Bojan Zivanovic, Ryan Szrama, and Josh Miller (taking picture).

To be continued...

This is just a snapshot of some of our discussions, plans, and current development. We have a few long days of coding ahead of us, after which we will provide more in-depth presentations of the new product architecture, pricing and taxes, checkout form management, payments, and other hot topics.

During early development as we create dozens of new classes and affect a variety of files with each patch, we’re taking advantage of GitHub to improve the code review and contribution process. To follow along, watch or star the commerceguys/commerce repository or fork it to prepare your finest contributions.