Launching Commerce on 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.
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.
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...
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.
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:
- 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.
- 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.
- 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.
A price is now an object that knows how to apply a tax rate, discount, fee to itself:
$price = $product->getPrice();
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.
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
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.
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.
Kindly add some captions to the picture.
Thanks for the update.
Good suggestion! Took some time, but we have captions with names now :)
This is great news. Do you plan on changing/improving the architecture for stock management and shipping? I work on the product fulfillment side of many eCommerce stores on many platforms, and this is an area of weakness for Commerce currently. Overall I absolutely love using Drupal Commerce over almost every other platform, due to its flexibility and customization. If you ever want some input from the user side of the back-end I would love to be involved in your discussions.
Stock and shipping are not a
Stock and shipping are not a part of Commerce core, so they are community directed. You can provide feedback and patches in the issue queues of the perspective modules.
That said, for D7 we've recently launched the commerce_shipment module that provides shipment functionality (and thus, per line item shipping).
We think this functionality should be a part of commerce_shipping 8.x-2.x from the start and we'll be helping the community implement it properly.
Commerce Stock would really benefit from being transactional (in both D7 and D8), and the issue to follow is https://www.drupal.org/node/1166600.
Great news! Developing a
Great news! Developing a Crowdfunding project with Drupal Commerce was great, but some dependencies on Rules made my life harder, as i needed to make a lot of things programmatically, so it's really great to see the improvements that will happen on the way we handle products on code.
Maybe i'll wait a little more with https://drupal.org/project/crowdfunding(that born from the project i said), to start it on D8.