Drupal 8 is now ready for production use, with RC1 released just recently. This also means that work on D8 contrib is accelerating, and everyone is curious about when they can start their first eCommerce sites.

A production ready Commerce 2.x beta won’t happen for another two months. However, we’re ready to start releasing related modules, tag Commerce alphas, write documentation, and track our progress more publicly. Starting from today we’ll do weekly blog posts showing the current state of Commerce 2.x. And for the people who want to build the future instead of just anticipating it, we’re holding IRC meetings every wednesday at 3PM GMT+2 on #drupal-commerce.

So, what have we been up to?

The libraries

We started the Commerce 2.x effort by building 4 stand-alone PHP eCommerce libraries and blogging about them:

• Commerce 2.x Stories: Internationalization (commerceguys/intl)
• Commerce 2.x Stories: Addressing (commerceguys/addressing)
• Commerce 2.x Stories: Taxes (commerceguys/zone and commerceguys/tax)

We then worked on achieving full test coverage, adding features, and resolving edge cases. In total, the libraries saw almost 400 commits, as well as several rounds of releases.

The libraries got us attention from other projects and contributors. With contributors came contributions, fixing edge cases and improving our datasets (number and address formats, tax rates, etc). Such an example is FoxyCart, an eCommerce SaaS that discovered commerceguys/tax while looking for a solution for the EU 2015 tax changes ("VOES"). Here's what Brett Florio, co-founder of FoxyCart had to say:

We've been moving towards embracing the PIE (Proudly Invented Elsewhere) mindset, and using the Commerce Guys tax extension is another step in that direction for us. It's great to avoid reinventing the wheel, particularly when it comes to data like "What countries are part of the EU?" and "What are the standard VAT rates of those countries on a given date?" We can maintain our focus, and contribute back to the community as our own use cases lead to updates.

And thanks to FoxyCart, commerceguys/tax got bug reports, API feedback, and updated tax rates for Austria, Romania, Poland, Greece. The beginning of a wonderful friendship.

The library effort took over 6 months in total, twice the amount it would have taken us to do the same thing only inside Commerce. This time investment will pay off thanks to increased contributions around an area that’s traditionally unattractive to contributors.

DrupalCon Barcelona

We had a very successful session talking about our libraries and the general approach of decoupling Drupal modules into PHP libraries. Check out the recording here.

We also had a three day Commerce 2.x sprint that resulted in 20 commits to Address, Profile, Commerce. Big thanks to our sprint heroes: Pedro Cambra (pcambra), Mikael Kundert (iMiksu), Jared Smith (jaredsmith) and Jeffrey Bertoen (jbertoen).

Composer

Depending on PHP libraries requires an easy way of installing them together with the related Drupal modules. Modern PHP libraries can’t be downloaded manually, but must be installed with Composer instead, which meant improving Drupal’s Composer support.

We took over the Composer Manager project, rewrote the module 3 times, and made 6 releases, from 8.x-1.0-alpha8 to the latest 8.x-1.0-rc1.
In parallel, we worked with the core community to improve the situation from inside. Many meetings and several core patches from a dozen contributors later, Drupal core has better Composer support than ever, and Composer Manager is getting smaller with each release.

Our final goal is for downloading Commerce with all dependencies to be as simple as typing composer require drupal/commerce 8.1.*, and we’re almost there.

Check out my earlier blog post for more details around Drupal 8 and Composer.

Next steps: Commerce and Composer checklist

Address

Address is the D8 heir to Address field, built from scratch to take advantage of the commerceguys/addressing and commerceguys/zone libraries.

The library address formats are imported into config entities, giving us a UI that allows all aspects of country-specific address formatting and validation to be customized. The numerous (> 12 000) subdivisions (administrative areas, municipalities, etc) are loaded from the library on demand and cached inside Drupal. Finally, Drupal's country list is replaced with the one provided by commerceguys/intl, which is not only more up to date, but has translations for over 200 languages.

Then there are zones, territorial groupings (of countries, states, postal codes) that can be used for many purposes. The Address module provides the zone plugin type and relevant UI. This can then be used by Commerce (shipping, tax) and other modules.

Last week we released 8.x-1.0-beta1, "the world's most complete beta release", and pronounced it ready for production. It has seen over 115 commits, 10 contributors, and has 100% test coverage for the formatter, widget, validator, as well as the Address Format UI.

The test coverage was sponsored by Vox Teneo and done by their developers, Dimitar Bolinovski and Martin Taleski. Vox Teneo is our first corporate contributor to Commerce 2.x, which is great news, and a topic for another blog post.

Next steps: RC1 blockers

Inline Entity Form

Inline Entity Form was built during the Commerce Kickstart v2 effort, to allow product entities to be managed from a node form. Since then, it has become a very popular and useful Drupal contrib, with over 60 thousand installations.

The initial Drupal 8 port of Inline Entity Form was done by webflo. It was then taken over by slashrsm and the Media team, after deciding to use IEF for Media on D8. This previously unseen level of community cooperation has allowed me and other Commerce contributors to spend less time on IEF and focus more on other modules.

We released Inline Entity Form 8.x-1.0-alpha2 last week. Commerce 2.x uses it for managing line items (from the order form), product variations (from the product form) and soon, tax rate amounts (from the tax rate form).

Next steps: Beta blockers.

Profile

Commerce 1.x implemented its own customer profiles in the commerce_customer submodule. People then used the Commerce Addressbook and Commerce Single Address to improve UX and add missing functionality. At the same time, people also used the Profile2 module for non-Commerce specific profile use cases.

For Commerce 2.x we have decided to join forces with the Profile2 maintainers, and create a new module called Profile. The code started as the profile2 D8 port by sun and akalata, and has seen many commits from Commerce contributors such as pcambra, joshtau, vasike.

We'll try to get Profile into Drupal core for 8.1.0, but for now we're focused on making it awesome in contrib. Our goal is to make sure the UX is complete enough that we don't need Addressbook or Single Address, and to use revisions as a way to avoid having to duplicate profile entities on change.

Next steps: Beta blockers.

To be continued

Every blog must end at one point. Even though I've yet to tell you about currencies, prices, stores, products and other things we're currently polishing. Oh, well. Until next week.