 All right, we would like to welcome you to the future of commerce on Drupal 8 Thanks for being here Is anybody here building e-commerce projects right now a few of us? Okay. Oh, just everyone. Yeah What about and most of us are still using uber cart for a lot of that stuff? Some of us are I don't think we support any uber cart sites anymore. Do we know there was only I found one in Greenville, South Carolina Selling used upscale baby goods through an uber cart marketplace. That was interesting But we are here to talk about Drupal commerce Once upon a time, we were both uber cart maintainer contributors But have of course moved on and we'll tell that story in brief As for introductions, I'm Ryan Sarama. This is boy on Zavanovich And we like to stand on platforms and peers in San Francisco looking fabulous for the camera And we are both co-workers at commerce guys which is a Drupal shop based in Paris with an office in London in Ann Arbor, Michigan and a handful of people here and there such as in Panchevo, Serbia in Greenville, South Carolina And we would primarily operate in R&D capacity with boy on leading Drupal commerce 2.x development Me still maintaining commerce 1.x And then also rescuing projects that need to be rescued amongst our US team myself and providing random wisdom on hip-chat Yes, random wisdom and hip-chat and occasionally showing up in IRC and ignoring everybody But we are the company also behind platform.sh Which is a Drupal platform as a service that we use to build and launch our e-commerce projects and our non e-commerce projects and our non Drupal projects such as custom symphony applications and other things But of course our first love and our primary focus for boy on and myself is Drupal commerce Which is an e-commerce framework built on Drupal 7? that was sort of created with the vision to Become the number one open source e-commerce framework in the world and we really wanted to power truly flexible e-commerce So this is the point in the presentation where boy and we'll show us on the table if you could bend yourself backwards or do the pretzel thing Maybe some other time. Okay, none. We're still working on that flexibility It's a bit embarrassed Let's talk about Drupal commerce as it is today And then we will talk about the future of Drupal commerce and just to clarify the future of Drupal commerce is on Drupal 8 Not on Drupal 7 So commerce 2.x whenever you see that is the Drupal 8 version of Drupal commerce And you may have heard that it doesn't strictly involve Drupal and Drupal modules But that's still its primary focus and we'll clarify what all that means during the course of this presentation I'm so so Drupal commerce today is a core Set of modules in one project called Drupal commerce or at Drupal.org slash project slash commerce and these modules Were built from scratch on Drupal 7 to make use of the Fieldable entity system that was brand new in Drupal 7 in fact when we started developing Drupal commerce It wasn't finished and I actually it's still not really finished on Drupal 7. Well, it's much better than before. Okay We we we got to be the guinea pigs to see what it would look like to build a complex set of modules Or like a complex application on this this new fieldable entity system that previously was just limited to nodes So just just the domain of nodes the fact that you could take any type of content type on your Drupal 6 site I had fields to it mix and match things that was brand new in Drupal 7 to be applied to any type of data including in Drupal commerce your Products line items orders customer profiles and payment transactions So we built this from scratch on Drupal 7 and we we stuck with just those five new entity types And I think three or four field types price fields line item reference field customer profile reference And a product reference field and we said that these were enough pieces To build any kind of e-commerce application you would need to build which was a bit optimistic But we kept the core minimalistic and flexible so that we could you know put out point releases whenever we wanted to Instead of having to wait for 30 different modules to be updated and bug free Before putting out a new minor release And so we were able to keep it Keep our code footprint a little bit smaller than we were with uber cart Because we were able to depend on views for all of our listings on the front end and the back end And was it did you work on views form stuff or was it Andre as well? And yeah, so what we did was make it possible for views to be used as forms And then we made our shopping cart to view as well So each of our listings from our shopping cars to our admin interfaces uses the exact same Method of building and seeing and this functionality made its way into the core views project And of course now it's part of Drupal 8 which is fun to see your code sort of swim up the stream there And the same happened for other things such as the entity reference field that came out of some commerce projects We did and a few other bits and pieces We also made the decision not to hard code business logic Such that you know we made assumptions for you about the kind of product you were selling Or the the kind of payment model you had or how you expected the checkout form to work And and we were able to achieve flexibility by standardizing on the rules module, which I'm sure is familiar to most of us So that instead of shipping with hard-coded bits of logic that you had to overriding code somehow You can just disable or enable a different rule or change the conditions and actions that That that are triggered when so you know a classic example is what happens on checkout completion Should a user account be created or not and if it's created should the user be emailed all that stuff was made part of rules So that you literally can have a truly anonymous checkout experience in Drupal commerce or one that requires Customer to register before even getting to the checkout form and all of that's managed through rules primarily and then a few contributed modules That are extending the feature set So we have what we sort of identified as essential contributed modules And these are things like the shipping module the address book module Discounts and coupons That we all sort of we looked for ways to incorporate their development into client projects So we could then develop the solutions generically release them and then let other people build into them and expand upon them And of course, you know a classic example as we created the shipping framework and our need for my actually it was my need I think I did it for my cheese website. I saw sell cheese online and I wanted flat rate shipping But other people needed UPS integration FedEx integration DHL, whatever And so all that stuff just happened on top of these essential contributed modules and then we also We decided that we really needed a distribution approach to complete the user experience Otherwise like people just get all of these modules and don't really know what to do with them don't know what they can do with them and If you've ever tried to put a salesperson in front of a customer and just give them a blank installation of Drupal to try and sell the Idea that we can build them a robust, you know websites or e-commerce application You can understand why we might have had to bring a little bit more to the table But at the core, you know, it was lean and mean and ultimately ended up doing something right because we're now up to about 57,000 sites reporting in the Drupal org as using Drupal commerce to power their e-commerce Which is the current record for e-commerce on Drupal in general. Yeah, finally. I finally beat my previous speedrun And overtook uber carts sometime a year ago or something. I don't know And so when we looked to improve the user experience, like I said the first thing we looked to do was Sort of imagine what would Drupal commerce look like as in out-of-the-box application So in other words picture Magento or Shopify or some other off-the-shelf e-commerce solution And that's what people expected when they came to evaluate Drupal for its e-commerce capabilities And if they didn't see something that looked like a store They kind of walked because they just assumed that there was no serious e-commerce functionality kind of like Virtuum art or WordPress shop not serious e-commerce functionality and yet, you know, it looks pretty pretty light and not You know not polished or complete so commerce kickstart Was our solution to create a distribution of Drupal that function as a Good marketing tool a good recipe book and also like a decent enough foundation for launching a new e-commerce project I mean and it turned out to do all of those things very well So boy on you were intimately involved in the development of commerce.exe while that you You know run through the slides of the main areas of functionality at off. Yeah, sure So our main goal for a kickstart was actually fixing the admin UI Commerce at the time had the reputation of being a bit difficult to use On the merchant side, so we hired designers and recreated our admin screens to create something that's optimized for the kickstart use case Which is an e-commerce site that does shipable products So we created completely new product and order listings with capabilities such as exchanging messages with the customers the ability to view an order at a glance and And especially the creation of inline entity form which allowed you to create the product and all of its variations on the same screen Previously that was a process that took multiple steps and we managed to design and implement a Solution that allowed you to do the same on just one screen and since then inline entity form has become One of the most popular Drupal modules and it's seeing even more usage in Drupal 8 For example, Yannis is using it for media in Drupal 8, so that's cool But Yannis is so hot We built a responsive front-end theme the kind that was cool in 2012 Omega 3 base Simply to show how such a thing should look it looks good on a mobile phone It looks good regardless of the resolution nothing really special there from from today's perspective But it looked good and it still does We built all of the product marketing tools that a user evaluating commerce expected to see at the time So being able to see color switches and better image zoom slide shows blogs All of the usual tools that people use for marketing products and presenting them in a user-friendly way And of course we created our crown jewel, which is the the faceted search Which automatically adapts to your product model So we use the search API module, which I consider simply one of the best Modules as Drupal has to offer to create this automatic faceted search no matter what products types you have We automatically create facets for you and allow users to search through the products collection to browse through it And it works just as you would expect it to work on a really big e-commerce site And of course since it's search API you can have multiple backends and Use Apache solar or even your database if you're on weaker hosting and have less visitors And to finance all of that we decided to connect ourselves With the leading payment gateways and third-party tools help them Create modules for Drupal commerce and then ship the most popular ones inside kickstart So the moment you install kickstart you can simply enable paypal or authorized net and start selling And that's that's kind of an interesting footnote I guess in terms of general Drupal development is that this is a distribution that actually finances itself now With the you know the revenues coming from these partnerships more than paying for The costs of the company to invest in the future of Drupal commerce So kind of makes this self-sustaining ecosystem So kickstart was and still is the most popular Drupal distribution It has 30,000 installs which when you think about it is a small percentage of those will Drupal installations But it's still an impressive number Yeah, and so all of this this practice of improving the user experience So What all this Showed us was the things that we left out of Drupal commerce core That people really resonated with in commerce kickstart and in contrib and really didn't want to have to reinvent and reapply on every You know site they built that kind of were able to take that information to then plan for a stronger Drupal commerce 2.x And also, you know once again, we decided to kind of get out in front of a trend In core and contribute Drupal Whereas on Drupal 7 we kind of got in front of the trend of adopting Fieldable entities as the the root of your architecture for your custom project this time around we're looking at ways to incorporate third-party PHP libraries into our module since Drupal 8 itself is now standardizing on symphony and using composer to build up this library of Library of libraries that Drupal then is powered by and so here we'll talk a bit about What planning Drupal commerce 2.x has looked like and then also what's been developed so far? So we started with a sprint in Paris. I guess last July And we brought together a handful of folks from different European agencies and e-commerce projects and also Fabian potentiary from since co labs and others who You one have e-commerce experience to had directed Drupal commerce experience like the guys from icos who built lush along with us and then Other just you know independent contributors in the Drupal community who Understand how to you know work with Drupal 8 so basically augments some of my weakness As Drupal 8 was still new to me and still is obviously going on has a lot more experience in it now But what we decided was we were going to adopt an architectural model Where we created first standalone libraries and these standalone libraries encapsulate sort of immutable logic Things that don't change from e-commerce projects to e-commerce project They aren't unique to Drupal commerce or uberkart or magento or Shopify or anybody So these are things that will cover like currencies and address related things And then we had to then take these libraries and somehow put them into Drupal in some sort of an entity Relationship model that made sense for e-commerce that was a bit more robust than what we have in commerce 1.x So instead of just the five core entity types We'll now have many more and part of that is due to the fact that Drupal 8 has two different sort of super classes of entities Some that store the configuration of your website and then some that store the actual content that you create And so we have to define all of this stuff and it was it's very class heavy From a module development standpoint, but that's now a work in progress And then the final thing is the whole like user interaction layer So what will a product page look like the shopping cart form the checkout form all of that stuff is yet to Be developed actually That's nice So once again, we're starting from scratch as anybody here. I actually written a Drupal 8 module a few folks Yeah, we write a few yeah, actually more than I expected that's more than me and I assume that most people are You know was shoot we can't really pass the mic around but basically you're either going to take a Drupal 7 module and try To forward port it or just rewrite it from scratch and and honestly with something is as large and complex and all-encompassing as Drupal commerce We opted just to start from scratch and not try to Forward ports and then retrofit the changes because there's just too much different Yeah, and and simply Drupal commerce owes its success to the fact that it was a native Drupal 7 application So if you wanted to repeat that success We needed to rethink our approach and rebuild from scratch Entry plate using all of these great new technologies and to once again appear native to a new generation of developers. Yeah And so to visualize like how the core framework itself will change then we'll come back to what the libraries are all about Like I said, we have you know five entity types four field types in Drupal commerce one and then a whole bunch of other entity types and field types and Forms and an additional user interface is defined and contribute in commerce 2.x You know, we're looking at at least like nine or ten or so different entity types and this is a bit outdated So I need to update this slide but but the basic idea is that You know, we need to actually be able to do things like organize all of the products and orders and line items on your website by What store they were purchased through that's not just to To support multi-seller stores or multi-vendor stores, but even just a single vendor website Currently doesn't really have a great way to store this sort of like global configuration around You know what currencies you're using your default languages or default whatever is you know It's all just kind of configuration in different parts of Drupal and here We're saying we want to have a store entity that can kind of contain a lot of that Configuration but then also do things like support that Etsy style marketplace or something I'm so that's one example of what we expect to change But but really it's as we aren't closed yet on how many entity types will have So feel free to propose your favorite one and let us shoot it down But we have a pretty good idea That we're going to need things like the store entity type which was already defined Payment allocations that assign parts of a payment transaction to specific line items on an order that sort of thing to address some of the deficiencies in our 1.x data model And so one of one of the major changes that we'll have and this is still a work in progress Is that in Jubal commerce 1.x? I think I will mostly be familiar with the fact that you define all of your product skews And then you use typically a node with a product reference field to group these things together And so you have a bunch of sibling product entities that are grouped together for the person You know for the point of display for the sake of purchasing it and the add to cart form is really this this controller that determines Okay, given all of these different products and the fields they have in common and which ones you've referenced I can then create these select list that let you select a size and a color and a day of the week or whatever it is What we call product attributes and so all of that is really derived from the configuration of these products in a group Whereas in commerce 2.x. We want to be a bit more intelligent and say that it's actually possible to construct a more Hierarchical data model that doesn't require you to define Individually all of the different variations But but could could scaffold a lot of that out for you buy at a product type level Letting you specify the hierarchy and then create them all at once Which in commerce 1.x is similar to the way that the bulk product creation module works But so like we think a bit more intelligent And additionally What we want to do is get away from the requirement that you're using nodes to display products to the end user So products at any level of the hierarchy could have a public-facing URL And then you know from the top of the pyramid down Whatever products are in this group for the URL you're looking at would become part of the add to cart form So so theoretically this is what we're researching right now Theoretically I could have just one page that was the whole t-shirt style a Where I would then select a color and then select a size from the available options Or I could also choose to have separate pages for the red shirt and the blue shirt And then have the add to cart form sort of build itself around whatever products fall underneath that in the tree So that that's a work in progress So is Considering how to to improve the checkout user experience and support multiple checkout workflows and optional checkout panes and all of that I had this bright idea that may not be so bright That we might be able to take advantage of form modes in Drupal 8 so much like in Drupal 7 you have different view modes Where I can say that product looks different in a teaser versus the full page versus the search listing in the RSS feed In this case, maybe I could say the checkout form has you know different field sets or widgets, you know for different types of Products that are being sold or something like that The thought was we could take advantage of this core mechanism to support multiple checkout workflows for sites For example that accept donations, but also sell physical products But they want a direct donation form that doesn't involve multiple steps or confirmations But then for somebody buying a physical product They still have to go through you know entering their shipping information and selecting a shipping service and all that but even if even if we aren't able to take advantage of The form mode concept in Drupal 8 and we do have ideas for how to improve this over the implementation on Drupal Commerce 1 Where you it was an improvement over uberkart in the sense that we could now alter the checkout form and and even Alter the way that it appeared by adding fields to customer profiles and so on It still has drawbacks in the way that we validated and submitted the entire checkout form You know in the the actual form validate handler and it's a bit it's a bit tricky anyways So if there's one outtake from this, it's that we are no longer making the checkout UX optional We want to offer a good UX out of the box Even of course still allowing you to change it and at the same time allowing you to implement Completely different checkout flows if you want to swap out the checkout form and implement something It's completely custom. We want to offer you better tools to do that Even being able to select those at random for a B testing or whatever else crosses your mind Additionally similar to improving checkout workflows. We wanted to improve our core support for the order workflow So if you if you've built a complex Drupal Commerce site that involved lots of like automated steps in order fulfillment Or or refunds or whatever it is you know that you've had to to automate state transitions or You know inner interfaces with third-party API's or whatever you've probably hit some limitations With the with the I guess with the fact that the order status is literally just like a text field that you're You're able to move into and out of any any status at all From any other status. There's there's no hardened Workflow requirements. There's no prerequisites for entering or leaving certain statuses all this stuff makes it a bit a bit difficult to manage what actually happens to orders on the site and you know a lot of people get bit by the fact that I think right now if you go to PayPal and You submit a payment using PayPal payment standard on their website The payment notification will get back to the Drupal Commerce site before the customer returns to this site But a lot of folks take advantage of that payment notification to do like a state transition and move the order into any status That actually prevents the customer from successfully returning from PayPal back to their checkout URL And and it's just you know kind of a thing you just have to know about and manage is that like just because you can monkey with The status anytime you want to It actually can break the user experience And it also can make it difficult to have like one status transition Automatically triggering the next because you hit limitations and like the entity cash and other things that just kind of make it Pretty difficult to manage So does anybody use JIRA for project management? Yeah, yeah, that's great I really like JIRA We kind of just adopted it last year and I really like it for the fact that I can create any number of you know types of issues Per project that I'm managing and then I can create any number of types of workflows that these issues must progress through To be considered complete or delivered to the customer and then I can basically apply prerequisites and even You know things like forms that you have to submit whenever you're doing the state transition And so so we're looking right now and maybe you'll have to speak to this We were looking at using the workflow module What's that which we won't we won't so yeah, so we were looking at using an existing solution To I think it was maybe built around like managing node You know editing workflows like a generic solution for just any kind of entity type But but ultimately we want to be able to say that in order can move from this status to this status only if these conditions are met and You know begin to just manage this a bit more aggressively so that orders aren't just going all over the place and yeah getting lost and And you know what what's what's the the current thinking on? You know how we're going to manage workflows in 2.x Well, the current thinking is that we're basically going to put the state field module in core So the order will have multiple workflows one that represents the payment workflow one that represents the checkout workflow and one that represents The main order workflow these states can be configured on the actual state field attached to the entity And then we fire events which are the Drupal 8th version of hooks to ask the rest of the system Am I allowed to make that this transition yet or not? Am I able to enter checkout if I have less than a hundred dollars of products? Am I able to go into fulfillment before I've collected payment is fulfillment done before I've actually sent the packages decisions like that? And and it also is worth noting that we're not going to require rules, you know for managing this in fact most of this would be Probably hard-coded in managing your repository. I guess through YAML configuration files that Like use configuration entities that are then well most of it will still be in events and rules will respond to these events So it means you don't need to use rules You don't need to even install rules But if you're using rules the previous level of functionality is still available So it's your choice, but we give a bit more power to developers Yeah, and that's a bit of a defense mechanism just as far as like having an independent release schedule Whereas in Drupal 7 you know Drupal commerce is being developed before views and rules and the entity API and Drupal itself had stable releases This time around we decided to be slightly less, you know masochistic and then, you know Yeah, make these things optional. Yeah, not dependent rules which doesn't exist. Yes. Yeah So they've made good progress recently and in in Drupal commerce 1.x the only hard requirement that we had for rules was for product price calculation And and honestly it was it was for it was it was over engineered The idea was if we forced all of the product pricing to happen through rules We could then actually Determine how many variations? Any particular product might have in terms of prices and then pre calculate these prices and store them in the database So that you could actually sort and filter product catalogs based on these calculated prices Depending on what conditions or medicine blah blah blah nobody ever used it So we forced a requirement on rules for a feature that never actually got used in production So we're trying to avoid that mistake this time around We also know that You know the the fact that the rules user interface is the only user interface that we offer in core for Managing discounts and coupons and taxes and all that stuff was really a limiting factor for Drupal commerce 1 So we did build the discounts module as part of the commerce kickstart initiative The discount module has issues with handling discounts applies to prices with taxes included which is European use case that no we commerce solution does well So we inherited some of those problems and we are finally solving them for to the tax and there are a few Performance issues that we are still working through and and even just like user interface issues that I think will will be addressing in 2.x but the the basic idea is that You know if you picture like a simplified user interface built on top of rules that was the goal the idea that the sort of underlying configuration is still transparent not baked into sort of like You know opaque entities like we use a discount entity for discounts the current discounts module But but make that a bit more transparent and you know Give a simplified user interface that a merchant could understand to set up all of their different specials and you know Seasonal prices and all that stuff So that's I think probably the most Undefined part of the current commerce 2.x like well We actually have a good idea on what we want to do We are just not sure how it should look like so I'm hoping that some great UX people will help me on that. Oh, yeah I already mentioned, you know the fact that we're having a store entity lets us support multi store multi vendor sites It's not a huge use case, but it's it's good to know that we can do it But really where the most exciting part of commerce 2.x development comes in in my opinion is is what we're doing with our PHP libraries So I mentioned we have three main areas of functionality. It's the standalone libraries It's the the sort of entity relationship model and then the whole user interface layer Right now our PHP libraries are the furthest along. They're at a beta phase. They're being used by other projects They're being used in production And they're even being used to influence the development of symphony itself and we'll talk about, you know How each one has sort of played out But then the you know We're currently in the process of defining all of our entity types and our field types And then the last thing to really be worked on is the user interface layer So there is no like add the card form or check out form right now But the PHP libraries We're started with research Which is what what are the things that that we did? Poorly in commerce 1.x and not necessarily poorly because we were stupid or made bad decisions But because we didn't necessarily understand the problem space and the fool like complexity that we needed to manage We looked into existing solutions for things like managing currencies in an abstract fashion or managing Prices and discounts in an abstract fashion. We looked even into other e-commerce bundles on symphony We looked into non PHP e-commerce projects to see if there are any solutions there And ultimately, you know boy on leading much of this research led us to the conclusion that we needed to introduce our own libraries To address a handful of use cases that that we were not doing well So the age-old weaknesses in our in our tax management and calculation The fact that in Drupal commerce 1.x. You don't have a price API So if you're if you're manipulating prices in commerce 1.x right now, you're still responsible For updating a data array and just you have you have to know this that that even though the price field has an amount column You still have to manipulate this this random PHP array So that so that it adds up to the total of the amount column Otherwise whenever you do in order total calculation the order total is different from what you expected it to be So so we had an incomplete like price management API of course with each new release of Drupal commerce We added more currency support because our approach to that was just wait until somebody said hey You don't support my currency whatever it is and then we'd roll a new release to include their specific formatting But then even then we never really supported like the same currency being formatted in differently in different countries or locales I mean so Really we wanted to identify and address these weaknesses with a handful of PHP libraries and and right now I believe it's actually we've added a sixth. I don't have enum up here But we've created five standalone solutions one for internationalization Especially dealing with local specific currency formatting another for address format management, which is Not just how should this be how should the form for entering an address be formatted and presented to the user But also how should the address data be validated and how should it be printed out in different languages? All that kind of stuff needed to be managed in a standalone library And these things are easy to abstract because they literally don't change I mean there are standards. There are international standards for these things so we also proposed libraries for grouping territories together for the sake of simplifying some tax calculation and shipping calculation and then also Helping developers work better with the tax API and price API in general So all that boy on kind of run us through The development of these and I guess it's important to point out that what we were what we were reaching for was not just a Yet another set of abstract like interfaces because I think there are a few projects that that really just kind of define a set of interfaces That you're then still left to fully implement But we also wanted to provide actual You know actual classes and then an actual data so not forcing everyone to find and supply their own address data or Currency data We wanted to have minimal dependencies create simple APIs with clear documentation and of course create libraries that had the ability even to be fully covered by Automated tests and so that led us to the creation of a handful of libraries that boy on will run us through Yeah, so as Ryan said one of the initial problems that we had is that our currency list that we shipped with commerce was never truly up to date We had currencies missing and even if we created we added them They would quickly become out of date why because inflation happens killing your minor units or Simply some currency stop being used and you get added So we needed a source of currency information that was always up to date So we could regenerate the list from time to time and we actually find found that in the cldr project, which? has completely open locale data in Jason format released twice a year and maintained by big companies such as Apple and Microsoft and others for example Drupal core is using cldr for the country list instead of using the official ISO one, which has weird country names So by using the cldr data We got a currency list that was always up to date and that had Translated names and symbols for all languages So you no longer needs to translate the currency list you get all the translations out of the box And if you ever used booking.com, you know that they offer that huge currency list with symbols and names in the currently selected language Where well we now offer that out of the box We also implemented a really advanced Formatter that formats prices according to the current locale So that means that the fact that the euro price you looks differently in France and Germany is no longer a problem because we take into account the rules for the given locale and we by Implementing that in the library we managed to skip depending on the intl php extension Which actually which is usually used for that but isn't present by default on many servers So the symphony team liked that and they actually started following our lead doing the same thing They committed the cldr data set into their own symphony until library So if you're using symphony today, you actually get the same currency in country lists that we Championed and pioneered and we are actually working with them to merge the number four matter as well and merge the rest of this library so on our first try we managed to significantly influence symphony as well as Fix something that was a long time problem for us Yeah, all the nice things I mentioned Example here of a euro amount that looks differently in great Britain in France and in Germany or an example of a price For an Arabic market, which uses different numbers, of course So that was one of the use cases that we also needed to support I'm good. Thanks. All right cuz command s is not the right So the next major one we created was addressing you might have used address field in in Drupal 7 The problem that address field has was that every single country has different rules for postal addressing Countries mandate which fields should be present on the address form in which order how they should be labeled and how they should be Validated so address field tried to implement a bunch of form alters that added country specific rules Like here's what UK does and here's what France does, but of course that wasn't sustainable So no two developers ever agree. Yeah So this time around we actually developed this concept of an address format Which holds all of those country specific requirements and then we use the address format to Actually render an address for display or validate it or create and present an address form and we Took all of this logic and put it inside the addressing library Of course, all of this is not as useful if you don't have the actual address format information So for a while it looked like we would need to do that on our own But then we found out that Google created such a data set for Android so they Gathered the address formats for 200 countries as well as the lists of administrative divisions and their translations for over 40 countries and then when we mail them They allowed us to take their data set and release it under the MIT license in our library And by doing that we created a library that was never before seen in the PHP world which made us trending developer and github for a while and is now being Actually adopted by Cilius the symphony to e-commerce solution along with our zone and text libraries We still need to give them a little bit of help on that, but I'm optimistic that the full integration will happen soon and of course Yeah, and then we take this library and we depend on it from our new address module Which is how we're calling the successor to yet to address field and we pull in the library using composer Yeah, well nice slides Yeah, one one awesome example for the strength of the address data that we've got is that we never would have known that if you're formatting an address form for a Chinese customer That you actually have to reverse the field order if the form is being presented in English versus in Chinese And so like all of that detail has already been discovered and gathered And I think we've actually been able to submit several pull requests to the actual core data set Yeah, we we submitted over 15 clarifications to Google that are now going to land in the next Android release or something So that's pretty cool Yeah, and we actually managed to take large parts of that data set and backport that into address field for Drupal 7 You see if you're using address field 1.1 It has at least 30 to 40 percent of these improvements are actually there and by doing so we actually closed more than a hundred issues In the address field issue queue which shows that a good approach can take you a long way Yeah, so and and this is this is part of what I mentioned earlier how with Drupal commerce now We're able to get out of out in front of like a new trend and contribute a module development It was the whole idea that we could get off the Drupal island and and oftentimes that that idea was we could get Off the island by using other libraries in our project, but now we're also saying we have we have something valuable to export to other communities and other applications And that also, you know, has led Bojan and others to contribute significantly to the way that Drupal core and then contribute works with composer To be able to pull in these libraries and data sets and so it has a broad influence I think and for those who don't know composer is the drush of the PHP world and actually one that will partially be replacing our own drush To be used for installing modules and installing libraries and keeping your site up to date So basically as a replacement for drush tl and drush make So back to the libraries the next one we created is called commerce guys zone So we are introducing the concept of a zone into triple commerce, which is a geographical grouping So a list of countries or a list of states with included or excluded postal codes that you can use for shipping or tax purposes Let's see if we have an example here. Yeah Uh, that's as far as it goes So for example, you can say that you have one set of shipping rates for california nevada and one set of shipping rates for the european union Or you can say these tax rates are used for this zip code Or these tax rates are used for this country and these zip codes because for example in europe There are some edge cases that say for example the german vat is using germany and parts of austria So to be able to actually encapsulate those edge cases We created this entity called zone that has a list of states and zip codes and everything And it can be used to significantly simplify your events and your rules that you're writing And then there's our crown jewel, which is the tax library so In the past three and a half years the way the world does taxes changed dramatically previously you would Install an e-commerce solution. You would look up your tax rate on wikipedia. You would input that and you would be ready to go But since january 1st 2015 Europe requires you to apply the customers tax rates if you're selling them digital products So ebooks or videos or trainings or access to a site Which means if you have a german customer, you're charging german vat If you have a spanish customer, you're charging spanish vat And of course europe is a big market But this is not limited to europe because there is a very clear trend Of countries trying to impose their own tax rates for the for purchase of digital products So this meant that we needed to create first a data set of known tax rates So that when you installed commerce and selected your country We knew which tax rates are used in your country and we would import them And of course in europe importing all of the tax rates for europe So we would know which ones to select It would be bad if I told you that you needed to look up the tax rates of 28 countries in europe and then input that manually And additionally you have you know the ability to track when tax rates change Yeah, so that if you're having to recalculate a historical tax And this is you know, maybe less applicable to the united states where there are just thousands and thousands of tax rates But at least internationally, you know being able to recalculate what the tax was on an order three months ago versus today is very important Yeah, generally It's not uncommon for a tax rate to change at least once a year Especially in europe So if it changes on january 1st, you really don't want to spend your new year's eve Waiting with your finger on the submit button so you can change the tax rate on your site So that new orders in case someone decides to order on january 1st or 2nd Have the correct tax rate applied instead our tax rates now have a start and an end date Which means that they will automatically switch to the next one and if you're doing historic calculations They still know which percent to apply and our tax types actually now reference the zones that I mentioned so that We can more we can better select the appropriate tax rates because as you know in the u.s The tax rates are per zip code So you needed a way to specify that and in europe They might apply not just to a country but to postal codes of another country or to just a specific group of islands All of the edge cases that gave our clients headaches and which we wanted to solve from day one this time And we already have a Is it uh Kong That's contributing tax information or is that uh, yeah, so our tax our tax library became immediately popular and Aside from cilius deciding they want to use it. We also had great success with sass solutions adopting us So for example foxy cards, which is an american sass decided to use our tax library to handle their Their tax therefore solving the problems that europe introduced with their new tax laws and kong a british sass Did the same because what we also did was not leave the selection of the tax types and And uh rates to rules Instead we have this system of resolvers Which are actually classes that hold all of the logic specific to a one market So we ship with logic for the european union for canada and we are going to expand that over time And those class classes can account for whether you're selling b2b or b2c Whether you're selling physical or digital products or events And all of the other variables that we know about that can be used to influence the selection of a tax type and a rate Inside one market and this logic can then be easily unit testable go Yes, yes, so we have the concept of compound taxes, which is important for canada get taxed on your tax Yeah, and and and i know it's not only canada. There are there examples in europe as well They don't need to be compound, but yes, you can apply more than one tax rate. There is no limitation to one And you can choose how their calculators So as I said, it brought us a lot of popularity and We are getting more and more contributors Which is great because it means that parts of commerce are being used in production today Commerce 2.0 won't be released in beta form until october for sure But today people are using our addressing in our tax code in production So I get pull requests every day that say your postal code validation is not precise enough in china for taiwan and these few provinces I said sorry and I merged that or Foxy card contacts me and says well What about a u.s company that's registers to collect european vat? And I'm like that's weird. Sure. Let's fix that So we have already managed to Fix many of the edge cases that we never even cared about before But now when we release on day one, we will have a truly battle tested solution And this is one of the benefits to creating the libraries aside from the Knowledge sharing and establishing the authority of Drupal commerce and our experience in all of these other markets And really that's that's the story, you know boyan has been leading a lot of that effort and attracting good Contributions from you know Drupal community members and building bridges with the symphony team and foxy car team and so on I'm really excited. I'm about everything that's happening in these libraries and boyan. I think you've done a fantastic job So we can give him a round of applause and then take questions And if you would please use the microphone So we can get them on the recording go ahead. Yeah, so could you guys speak to the us? Can you get a little closer to you? Can you hear all right? almost Just rock it. Okay. Can you guys speak to the? us state sales tax Problem, you know the nine thousand different past taxing. Yeah, so there's a there's a company downstairs called avalanche that has a tax management solution That's what you should do Go a little further. I mean we've actually used avalanche. Okay, they're good. They're expensive Yeah, it's an expensive problem. Yeah Yeah, is there any is there any alternative? Yeah, so what I can say is that if you're selling from just one state and don't have nexus in other states Then you only have one potential tax rate and you can apply that If you have nexus in other states, there are some states that say if you have nexus with us You can still apply your own tax rate in that case You're also fine if they use destination based sales tax Which means that they always apply their own tax rates which vary by postal code There's no way to solve that because you would need to collect the tax rates of every single municipality and city in every single State where you have nexus and in that case There is just no way to do that inside commerce unless we want to do the data gathering ourselves But the data would soon be outdated. So It also depends on the state you're in. I mean california, florida, washington state, colorado Your tax rate varies not even by zip code even by like street address at times You know by by the municipality or that and so it's just impossible to manage all of that in house The simplest case would be like south carolina where i'm from you have a six percent statewide sales tax Okay, well, you still have to know about tax holidays that you know that there's a week in the year Where you don't have to charge where you aren't supposed to get sales tax charged Or you know certain products for certain types of income brackets may not be taxed Whereas they would for other income. Yeah, it's like it's a complicated problem And you know ultimately like I I would only trust somebody who dedicated their life to managing that to manage it for me Yeah, basically david kitchen. Yes. He's our resident tax expert who spent like a month teaching us how to do european taxes But in any case, I like to say that the only good solution for these kind of problems is revolution But we did manage to do everything code as well I just point out one more one more problem in a domain is anybody who has An affiliate marketing program and a lot of people do Is encountering nexus problem. Yeah, all of your affiliates are next. Yeah Defined nexus. That's why amazon pulls their affiliate program out of states and yeah so Well, as always thanks for your great presentation today and your hard work on the commerce project my question goes back to Earlier you were talking about changes to the Product api and the structure around those and I was wondering if you could provide a little bit more color On your change of direction with that architecture You you know alluded to a smarter products and so forth and if you could just describe that a little bit more And where that is and it's a maturity in the cycle at this point. Yes So Initially, I mean today We are still going with the old data model of products plus product variations created through inline entity form Because this is the model that's always worked for us and it is well understood And as ryan described we have this great idea for a hierarchical product model which would allow us More granularity being able to choose which data to share and which data not to share and to make unique And we are still exploring the complete ux and the questions there and we're looking forward to actually having More to share about that at the end of this summer at least with a blog post in july or something But we still need to have many discussions about that if you're interested in that We will be sprinting on commerce on friday so we can at least talk about the problem space I can show you our mockups and our full plan. Yeah and and the Yeah, the problem whenever we were developing commerce on dribble seven was that nodes were still kind of like a requirement For displaying stuff on the front end comments are you know tied to nodes So if we wanted to support comments on products, which people use for reviews Well, then we had to have a node involved somehow that just wasn't abstract enough But now with droop late we feel that the abstraction is sufficient That we don't have to require everyone to go out and create this this relationship between nodes and products to do the display So that that's where like some of the oh, we can do something different now came from cool First of all, thanks. Appreciate you guys's leadership in this area in Drupal I must have missed it because i'm working on a commerce site right now But i'd love a progress report on the one x the two x migration module that you guys are working on Yeah, so Drup late has decided that they will not support any kind of Manually scripted migration instead. They are using the migrate module Which basically allows you to define the source of the data and then how that data is mapped in the new system And then it does that transformation This is the approach that we actually championed for a long time for commerce 1.0 text as well If you've used commerce migrate or commerce migrate uber cards to move data from uber cards That's the same approach that core decided to use for Drupal 8. So We are going to continue doing that once Drupal 8 is released People will be able to write migration classes that move data from Drupal 7 and import it in Drupal 8 Whether that will be us doing the initial work or someone else who has a pressing client project remains to be seen The good news is that commerce 1.0 text has a well defined data model compares to uber cards Which was like anything goes which means that the actual migration classes should be much easier to write than the ones We had to do for commerce migrate uber cards for example. I'm very very excited about migrate being in core Yes You need to get really close to it. I'm sorry I did not hear anything Does Drupal commerce supports Oracle integration or SAP SAP integration something like that Did we ever do SAP integrations? Pretty much all of those integrations are one-off integrations something that's done for a specific client site I don't know of any solution that anyone shared with the wider community because what they're basically doing is Using the commerce extension points taking the data at those points and then sending that to the external system or doing the reverse So there's maybe there's not much to be shared But as I said, I haven't actually seen that code. It's usually ties to client sites And one issue that you'll have with those is because those tools are so customizable I mean there's not like a standard implementation that we could even really like benchmark against But we do favor the idea of your Drupal site as a conduit of data You know taking transaction data in as a point of sale system might and then putting it back into Oracle or SAP or market live whatever it is that you're using But a lot of that would just be like standard Drupal integration stuff not like a Can module I think Basically our clients are using magento for commerce application. How can I force them to use Drupal commerce? Well, that's a hard sell to make because the strength of magento is that you have A million pre-built features that you can use But then if you decide that you want to do something your way or do any kind of extensibility You have a problem commerce is the reverse you can do anything But the the the amount of pre-built features is much smaller mostly due to the fact that we never had 15 or more full-time developers like magento had They're hoping to use that and we'd be happy to talk about it afterwards if you're interested Yeah So for any longer questions or anything that you think of later We have a booth in the exhibition area so you can find us anytime and and just chat But we I mean we lose to magento and we went against magento. So it's really really depends on the situation Yeah, we had the luck of having grind which codes like five Normal developers so that was at least something and we would buy him coffee so that he's worth seven But it's still not 15 It's not 15. Sorry. You'll need to practice some more, right? Oh, that's nice guy who's definitely not a commerce guy. No I I am a commerce. Okay We've talked about having things other than products being purchased for example, maybe yannis having a File being purchased for a stock photography site or something like that Is it possible that all entities could be purchasable? Are we gonna focus in on products? Well, I think it's a bad idea, but I'm not The court is divided. What we're certainly doing is Allowing you to have different product architectures and actually having the ability to create an order and line items without having a product entity So that means you can implement your own entity types But whether you should be using an existing entity remains to be seen. I'm thinking that it will be possible, but still a bad idea All right, let's wrap up We do have regular office hours and irc if you like that More boy on it's typically they're answering questions and coordinating contributors and developers Also development is happening on github and those various commerce guys repositories So if you're on github and want to contribute to any one of those feel free And since we're here we'll be sprinting on friday. We're at the booth today and tomorrow So definitely would love to hear from you and incorporate you into commerce 2.x development. Thank you very much