Getting to work on a stronger Drupal Commerce 2.x

I don't like being sandy but I love building sand castles. The potential is high but the stakes are low. You have unlimited raw material to build whatever you can imagine, and if you screw up you can just knock it over (to the delight of your children) and start again.

When your constant is impermanence, you adjust your expectations accordingly. If the sands shift or the tide rises, you shrug it off and start again or go back to bocce. However, if you were somehow bound by the fruit of your labor, you'd think twice about the when, where, and how of your building.

Lyle and I started developing Ubercart when Drupal 5 was still in beta, and we put up with the impermanence because we were just two dudes learning a lot and working from a clean slate.

Moving that forward to Drupal 6 took even longer because our codebase grew unwieldy, so I decided at Commerce Guys to trim the fat and start over. We didn't learn every lesson moving to Drupal 7, though, as it was still unstable when we began developing Drupal Commerce. With an unstable Views module. And an unstable Rules module. And an incomplete Entity API. Tongue

I don't think we would've done any differently, as the flip side of the instability is the opportunity to positively impact the development of the projects you depend on. For Drupal 8 we ended up contributing to core in other ways while tackling a full Drupal Commerce rewrite more slowly than we hoped. Even the code that we did develop against Drupal 8 is now outdated, as we had to juggle managing our existing ecosystem, writing new code, and rewriting that code to track changes in Drupal 8 itself.

However, we've recently been given the opportunity to host a variety of developers / documenters in Paris from June 30 - July 4 to re-evaluate our Commerce 2.x roadmap with the direct help and guidance of key members of the Symfony project. Specifically, we'll be looking to both move our code "upstream" from our Drupal modules into generalized libraries and take advantage of existing Symfony projects where possible.

Our target is an even leaner codebase with connections to the broader world of PHP based eCommerce. If you have any insights in this direction, please comment or contact me directly and consider joining us in Paris to learn and contribute.

Photo credit: j.s. clark


I was actually going to ask you about some of this at Austin. I think its a great idea to participate more in the Symfony ecosystem, I'm even curious to see if there is a possibility of having "drupal commerce" without the Drupal part (unsure if there is any crazy project that might want that though) .

(p.s. you need to expose the email field or disable comment notifications on the new blog)

Hah, too funny - totally missed the anonymous comment settings when I relaunched. Thanks for letting me know. Tongue

And yeah, I'm not sure how much we can really manage without Views and Rules, but I think we can at least begin by identifying third party payment bundles / components that we can use and perhaps moving our price and address systems upstreams into general components (as the projects I've evaluated, Sonatra / Sylius, don't really appear to accommodate all that we currently do). Let's chat more in Austin!

Given that the larger PHP world is moving towards the building of discrete and pluggable modules with a framework-level event system, the idea of building Commerce like is not a new idea. The release of ZF2 saw the birth of SpeckCommerce. However, it seems to have moved very little, being more of a response to the lag-behind of Magento. However, given the existing weight behind Drupal & Drupal Commerce, it is far more likely to succeed in the long haul.

High hopes for Drupal 8 and Commerce -- truly moving to the next generation.