 I am Ryan, this is Matt and Boyan from CommerceGuys, and we are here to talk about creating online stores with Commerce2.x, which is the Drupal 8 version of Drupal Commerce. CommerceGuys is actually a much smaller company now. It is the three of us with a plus one, wherever Doug is, there's Doug. We had a chance to reboot the company at the beginning of February. I guess basically we spun out of platform.sh, which was the Drupal optimized platform as a service that CommerceGuys had previously incubated. And we found a way to separate the companies so that they could each kind of grow at their own pace, unencumbered by the other. And it's given us a chance to kind of reimagine both what our company does, how we make money, and I guess also what our philosophy is for Drupal Commerce. Excuse me, I'm trying not to let the allergies get the better of me. It's just allergies. So in so doing, in starting over, we kind of took a step back to think about what is our mission and what is our purpose with the work that we're doing, both with Drupal Commerce and with our client services and other things that we're up to, as we kind of settled on this idea that we are collectively engineering simpler solutions to the hardest parts of selling online. So that's gonna change the way that we address core improvements in Drupal Commerce, the contributed modules that we're developing, the recommendations that we're making to our users and to developers, and also just the partnerships that we're able to form. And so we've kind of begun to rethink about Drupal Commerce as not just a truly flexible platform for building anything, but rather a platform that helps developers solve more problems, not less, whereas before we were very un-opinionated and just really focused on flexibility, now we're thinking more about how can we solve more problems than we're creating with our flexibility. We also changed the way that we deliver services and the way that we partner with other Drupal agencies and developers to develop the modules. So we actually have our friends from Acromedia here in force, I think there's more of them than there are of us in the room. And probably more Drupal Commerce contributors from their team than ours in the room now too. And with Acromedia we deliver all of our client projects in the US and Canada and we get to take advantage of their team's UX and design experience and their rich history of developing enterprise e-commerce sites. So that we're able to surface some of the hardest parts of selling online, not just for ourselves and our end users, but also their users and their customers and create better solutions together. So that's what we're up to, generally speaking, but more broadly speaking too, Drupal Commerce 2.x has a chance for us to take part in the Drupal movement off the island. So we've heard that for years, that Drupal needed to get off the island both in the core and contrib space and find projects that already exist that solve the problems that we're addressing and take advantage of them. But it wasn't really that easy to do before Drupal 8 unless you were willing to work without namespaces and with the library's module and so on. But with Drupal 8 now and Composer, it's a lot easier to get off the island. But what we found is that we just need to import onto the island, we actually have a lot to give as well. So it's not just about finding new dependencies for our projects like Left Pad or other dependencies to break our code in the future. It's also about thinking through what are the things that we are doing in the Drupal space with Drupal Commerce and the other modules that we're writing to support it that would be more generally useful in the broader PHP world. So that was actually the starting point for Drupal Commerce 2.x development. I think we've been active on it for a year and a half before we opened the branch on Drupal.org. And that was really about finding mindshare with a handful of libraries that actually did address some of the hardest parts of selling online such as locale-specific currency formatting. How do you format the Euro for Germany versus France versus in the US? Here we just don't yet. But also, how do you create address forms that are locale-specific that have validation rules where possible, that have formats for every country in the world, for every language that they support in their country? That all that stuff is really difficult to get right, but we found solutions to encode that knowledge into a handful of libraries that we've released on GitHub. And then before we ever even turned them into Drupal modules, found other projects that would be interested in making these a part of their stack. So Symphony is adopting parts of the IMTL library that Boyan was able to create based on the CLDR data set. Foxy Cardi's using the tax library. I'm not sure who's using addressing, but we're trying really hard to get some big competitors to use our addressing library. And they're actually really interested in doing so, which is really neat. So we got the libraries going and then once those were up and once we had actually achieved some market share and production usage of those libraries, we got to step back and think, well, what are the lessons that we learned from commerce1.x that we can use to redesign the actual implementation of Drupal commerce on Drupal 8? And I already mentioned one, and one of the biggest challenges that we faced with commerce1.x was that we essentially expected everybody using it to become an e-commerce expert. So it's nice as a framework to really focus on flexibility and interoperability with other systems and other sub-modules. But at the end of the day, they required each one of you building a commerce site to know how to create an optimal checkout workflow, to know how to customize the backend for your end-users fulfillment workflow, to know what analytics service to find, how to calculate sales tax properly, what payment systems are the best and the most PCI compliant and so on and so on and so on. At the end of the day, most of you don't have time for that and so then you end up using other systems. Or at scale, this is maybe not something that we've addressed before, but it's something we're finding now, is when businesses adopted Drupal commerce and then scaled, they quickly found out that a handful of contributed modules in our ecosystem weren't built with scalability in mind. And there's nothing that we can really do to prevent somebody from going off and creating a Drupal commerce project and sort of grabbing the namespace for like a big subsystem. And I'll pick on us the discount module or keep on modules that we kicked off. Once that namespace is taken, that becomes the de facto solution for that part of doing e-commerce with Drupal. And if it wasn't written with scalability in mind, then suddenly you have the marketplace module on a site that's doing $20 million and they're getting an order entry in the database every time somebody hits a product page, which is crazy. So we're trying to find ways to mitigate that, to be more proactive in architecting contributed modules and working with developers to make sure that the solutions that come out are really solid default solutions for stock, for shipping, for discounts, and on and on. I don't really know all the ones that we have going on right now. Licensing, various payment gateways and tax integrations. I can't think of what other lessons we learned. Well, we learned that we need to prioritize UX more. Yeah, yeah, definitely. We didn't have the inline entity form module whenever we launched a Drupal commerce 1.x. And so that was probably the biggest gripe that I didn't expect it, because I actually thought the user experience in UberCar was pretty poor for managing product variations and product pages. And I can say that because I made it and it sucked, especially if you wanted to ever change any of the SKUs that you had on a product page that would get blown away if you ever added a new attribute option or saved the form without resetting all of the SKU variations. And so we had what we thought was a better underlying data model. And I think I just kind of expected the user experience to resolve itself and contribute. And it was a really lofty dream that just basically hurt us for a year and a half in terms of adoption and real-life customer success. So inline entity form module was created. A few other modules were created that ended up improving the user experience. But you might say they were, in some sense, a day late and a dollar short, because people that already ruled Drupal commerce out as a solution because it didn't, I guess because it required too many clicks to set up product pages. So of course, this time around, we made sure that inline entity form module was done first, and now depending on every word within Drupal commerce. And so with Drupal commerce 2.x at a high level, it's been built from scratch on Drupal 8. We have an alpha four that was released two weeks ago almost. And really the last major system that's in development prior to a beta release is the payment system. And so we've been hacking on that this week and we'll do so tomorrow as well if you're here to sprint. We'd be more than happy to have your help. And also to get you up to speed on what it's like to develop for Drupal 8, because it's very different from Drupal 7. At this point, I think, I've probably forgotten everything I know about developing for Drupal 8 because that was like a year and a half ago that we started. And then Boyan really took over and has been leading the development since then. And he's doing a fantastic job, not just of Drupal 8 development, but also of integrating other contributors from other companies to the process. And then last thing that we have to do before we have like a real solid beta is our commitment for the beta release is that there will be an update path from one beta to the next. And so, of course, that means solving things at the core level, like updating default configuration from one release to the next and Matt's been working on that. And figuring out migration and a few other, you know, small things. Yeah, one of the main things blocking us currently is that we still have active bugs around translations and how we do revisions. And we want to make that really solid before we actually tag a beta. But that doesn't mean you cannot start building today, it just means you would need to reinstall in like two weeks to re-import the configuration and templates you made in the meantime. But we are working hard to resolve that as well. Yeah. So I'm gonna actually hand the mic over to Boyan and Matt to take us through what it looks like to actually install the Drupal commerce site and then what features you'll find out of the box right now and what's coming. Just make sure you rock the mic so the recording gets in. So one of the biggest changes that Drupal 8 brought us is the usage of Composer. And if you've ever used Drush to download the module either using Drush DL, the command or Drush Make, then you already know how Composer works, except Composer is a PHP ecosystem wide solution that can also resolve dependencies. So that means that if you're downloading a module, it won't just download that module, it will download all of the modules that module depends on and any PHP libraries that the module depends on, which is really powerful. And since we have taken pieces of Drupal commerce and put them in external libraries, that means those libraries need to be present for commerce to function. That's why commerce can only be installed using Composer. And we've made that really easy. If you have an existing site, the only thing you need to do is run Composer, require Drupal commerce, and that will download Drupal commerce, it will download address module and inline entity form and all of our dependencies and it will download our libraries ready to use with a single command. And for people who are starting a new site, we have another command, Composer create project, which is basically the Composer response, well, way to do distributions where with one command, you get the latest Drupal release, you get Drupal commerce, and you can keep it up to date with one command. So when you run Composer update, it will update Drupal core, it will update commerce, and it will update all of our libraries, which makes maintenance really, really easy. And you can either do this on your server or you can do it locally and then commit or upload the result. So I really think that by enforcing this workflow, we've actually made it a lot simpler to simply maintain and keep our website up to date. You can read more about this on our documentation pages. So this time around, we are trying really hard to have great documentation from day one, and we started by documenting the install process, so you can read about why we are using Composer there, how, and of course, all of the details around the process. Of course, commerce has many module dependencies because it simply provides a lot of functionality, and most of the dependencies are the ones that we have built ourselves, and some of them are actually more popular than commerce itself. Inline entity form being the biggest one, so that's probably one of the most popular Drupal modules we ever built after views bulk operations and entity reference. Yeah, so inline entity form allows you to edit related entities on a parent entity form, and we use that for products and product variations. We use that for orders and line items, and this module is now in Alpha-6, soon to have a beta, which means it's in good shape and it's being used out in the wild with a few remaining bugs. I guess for media, I'm wondering. Yeah, so the nice thing about inline entity form is it's now shared with the media project, they are co-maintaining it with us, and Acquia has actually sponsored a lot of the porting and a lot of the bug fixing through the module acceleration program, right, along with MD systems and others who sponsor the other maintainers. Now, the next one is address, which is a module that inherits address field, so for Drupal 7, we had address field as a way to store an address, format and validate it. For Drupal 8, we've created an entirely new module that's based on our library and it uses the Google data set that was originally made for Android, which we got Google to release under an open license, and then we pushed many of the fixes we ourselves had in address field into that, so technically we are Android contributors now, and so we took that data set and started using it inside Drupal, and that means that we have an address format for every country and we have a list of subdivisions for every country, and when I say subdivisions, I mean states, provinces, for some countries, even multiple levels, for example, Brazil has two levels and China has three levels of subdivisions that you need to select when you're entering an address, so all in all, I think there's over 14,000 subdivisions for all of the countries that we cover, and we make sure that they are actually translated and cached and it was a really, really big effort, and I'm really proud of the work we've done there. And yeah, he's not tuning his horn enough. Yeah. Yeah. He's literally a committer now to the Android SDK because of Drupal commerce and getting off the island. We went far and wide. You can see that for example, we now have a UI for address formats. This was previously needed because of course, no address format can be completely precise. So if your client calls you and says, look, the postal code is not supposed to be required, you can just go into the UI and edit that and send us a bug report later, basically resolving your problem right away. We also created this concept of zones which is basically made so that your rules or codes are easier, so a zone is basically a collection of countries or provinces or postal codes that you can use for taxes or shipping, so that you can say that you have one set of shipping services for California, another for Texas, or you can group by postal codes or whatever granularity you need. So you create a zone and you can specify the least of geographical groupings and then use that elsewhere in the system for any kind of matching. This counts taxes, shipping, all of it. We also joined forces with the profile two team, so instead of us using customer profiles and profile two having its own thing, there's now only the profile module which is used everywhere in Drupal and we will make that the de facto solution and we use that for our billing and shipping profiles, working hard to have a beta there as well. We created a really good workflow solution. Previously when you had order statuses, you only had a list of them, so for example, validation, completed, canceled, but now we've extended that concept with full workflows so that we don't just have states but we also have transitions. So we know that based on the state that the order is in, we know which steps are next allowed and which steps you need to take to complete the workflow. And this is code-based, you can create the workflows in YAML and then use that to plug into our own workflows and add any processes that your client might have. So for example, when the order is placed, you might require the client to check the payments made for fraud and do other kinds of verifications, contacting of other systems and then so you can use a workflow to make sure that has all happened and that it's sent to the correct people, the correct department and so on. This is all nice, but we're here to talk about commerce, right? So let's start with the actual commerce features that we've done. We started with the currency management because Commerce 1.0 had its own currency list, which frequently got outdated. So we are now using the CLDR one. So CLDR is this really big project maintained by Google and Apple and Microsoft and others that creates lists of currencies and countries and languages and meant a lot of other data needed for systems like ours and we not just get a fully up-to-date currency list with releases every six months, we also get translations in over 200 languages. So that means that if you need to show a list of all currencies to the user, we always have them translated to the language that you're currently using, which is pretty great and we actually have the same thing for countries so you don't need to translate the country list manually either. We have all of that built in. Other than translating the currency names, we're also translating the currency symbols because we found out that the currency symbol can actually vary between countries. You don't show the dollar symbol the same way inside the US and outside the US. So all of these are the nice features that we got by cooperating with the CLDR project and integrating that into our libraries. We significantly improved price formatting to be locale aware because we realized that it's not just language or country specific, it's both. So that means that a price can look different for Germans in Germany and Germans in Austria and we now know how to handle that and we have the address formats once again from the CLDR project to make sure that currencies are always formatted the right way. So I think we've made a really big step forward there. You can read more about that on our blog. So on Drupalcommerce.org slash blog we have easily over 10 blog posts about commerce to the tax functionality going more into detail about all of these things. And then we worked hard to make taxes easier. We realized that tax rates actually change all the time. At least in Europe, you can expect the country's tax rates to change once a year or once every few years. So if there's a tax rate change planned that for example for January 1st that means you're spending New Year's Eve with your finger on the button so that you can submit that form and start charging 20% VAT instead of 19%. And this is becoming more and more complex because in the European Union we need to know the tax rates of all EU countries when we are selling digital products because we always need to charge the tax rates of the customer's country. If we have a customer from Germany we need to charge the German VAT same for French customers and French VAT. So we knew we needed to fix this to make sure that people outside the US can actually use e-commerce without needing to pay for a tax cloud. I mean the US is a lost cost to be honest. In the US you need to use a tax cloud but the rest of the world isn't. So for the EU that means we have a list, our own data set of known tax rates that's being kept up to date with Foxy Cart and others. And we are doing the same thing for other countries like Australia and South Africa and others. So that means when you install commerce based on the country that you specify we'll be able to import your tax rates automatically and then we have logic that allows us to choose the right tax rate based on whether your product is physical or digital whether you're doing B2B or B2C and many other things. We, this logic is now completely divorced from rules so you can write tests for it and make sure it's working well. I said the US is a lost cause and it's just my way of dealing with the complexity where basically US has tax rates that's for I not from states to state but from zip codes to zip code which means that there's no way for us as commerce developers to actually pre-define them for you. It's something that you must do on your own and then if you have Nexus in multiple states that makes the problem that much more complex. Yeah, so for that case we would integrate with Avalara and recommend using a tax service like them to automate taxability, tax rate selection, handling tax holidays and everything else that goes into that and remitting it, reporting it, et cetera, et cetera. Once again we have a good blog post describing all of these problems and our solutions on the Drupal Commerce.org website. A really big change that we've introduced is support for multiple stores within a same Drupal Commerce instance and this addresses two different use cases. So the first one is the so-called Etsy use case where you allow your users to create their own stores with their own products and then visitors can add, can have multiple cards from matching multiple stores basically buying products from your users. This is use case number one and use case number two is a company that actually has billing locations in multiple countries. For example, platform.sh has a presence in France and a presence in the US and based on where you are they will charge you from that country and charge those taxes and having a store entity allows us to do this because the tax settings and the currency settings are now store specific and all of the entities in the system are store aware. This is one of the things in commerce one of the tax that country try to do but it's much harder if you don't plan on doing it from the start. So that means that one order always belongs to one store because that's the billing location used but the product could be visible in multiple stores if need be. So for example, if you have the platform.sh products, right? Or selling kinder eggs. Yeah. You strict them from being in the US? Yeah, kinder eggs. Best thing ever. We worked a lot on redefining the product architecture and what we've done is an iteration on the product architecture that you saw in commerce kickstart. So instead of creating nodes, you create products which behave the same way as nodes used to do and then on the product page using inline entity form you create individual variations and those variations hold the skews and hold the sets of attributes and then they are the actual thing that is being purchased and compared to kickstart we actually have really robust dynamic generation for the variation titles as well as solutions for other problems we saw while implementing that kind of an architecture. So I think this really makes products much easier to use and I won't actually talk about product attributes because you deserve to hear Matt a bit as well. So product attributes and one dot X when you worked with variations like picking a size or color oftentimes we push for using a term reference and you'd use taxonomy terms and that would represent your value. Well, we're not controlling that as well. So in two dot X, Bojan created the product attribute value or commerce product attribute entity. So now your actual values like your small, medium, large or their own entity which gives us greater control and a better way to manage them. So instead of sending your store owner to the edit your taxonomy terms now they actually go into their commerce UI and they have a list here where they create a new attribute of color and then as they add their red, blue, green, et cetera they have a giant list that they can just edit and then save right here. So now it's in its own UI which gives us greater control and also when you're creating a product it's much more explicit because it's rendered from that list and there's just one single area to go edit them. Which maybe you have prevent nice things like letting administrators delete attribute terms that have already been purchased and suddenly your whole. Yeah, and so the fields are automatically added or not automatically added but when you wanna add an attribute to a variation type for your t-shirts they need to have size and color you edit the variation type, you check a checkbox and then behind the scenes we add that field for you so you no longer need to go in and say well I need to make this any reference field and pick the specific type that's generated for you. And at the same time one thing that's not covered in slides right now because we just worked on it is the concept of fancy attributes. In 1.x there was a commerce fancy attributes module which let you render colors as a swatch on the add to cart form and on the catalog which we're all pretty familiar with with the big e-commerce sites. So now using attribute value we have the form display and actually view display and we're rendering those when you need them so on that form you could display on the add to cart form you could display the color swatch so that way people have that experience and your catalog you could render an overview of all the available colors so that when they're browsing that one image of your product they can also see there's other colors available. And I'm not sure if that's a familiar concept to most people the idea that in Drupal 8 now instead of just having an interface to set the display of fields in different view modes you also have form modes where you can determine how fields and other attributes of an entity are rendered and selectable on different forms including just like not showing widgets at all on forms that you don't want that field to be present. And so we're using that for product attributes and also a few other areas that they'll get to. So the one great thing with it is that we now have a UI for order and line item types in core previously this requires two contrib modules that are now no longer needed. So that means that you could have separate order types if you wanted for physical and digital products or event registrations or trainings whatever you're doing and each different order type can have a different workflow, a different checkout flow and a completely different logic which means that for very different kinds of products you can provide completely different experience to your customers. One of the places where UX is of course important is the order UI on the admin side. We started by first creating a wizard which you cannot see in this screenshot but it's available in our blog post that allows you to create a new order step by step choosing the customer and then adding the line items and then adding the payments and everything else. We also adopted this pattern of two columns that core has and we are using the right column to show you information such as the IP address of the order geo location once integrated and to simply provide a better experience. And this form will be expanded as we add support for payments and adding manual discounts here. So one of the big complaints we had with commerce model text was the admin UI for orders was not powerful enough and requires additional contrib modules but now we are making sure that is really both powerful and extensible from day one and you can see at the top that it also shows that the state of the order that's the current step of the workflow. I'm not sure whether it says yes. It shows that the order is still in draft which means it hasn't been placed and it's not yet being processed by the system. You are still adding line items to it before the customer approves it. And to touch on what the product attribute values and the form mode. So we have the edit cart forms which are now based on the line item type. So this way your whole edit cart form is based on the line item that your product type is going to be using. So our variations can be rendered as radios as a select box or the rendered attribute as we are saying. And then let's say that you have a trophy shop or someone lets you buy custom cakes online and people can write that sweet little message on it. You would add a text field to your line item type and in your form display mode you would simply change that from being hidden to the text field widget and that would then display it on the edit cart form. So when someone clicks edit cart it creates that line item and sets that field value. So now you're able to easily customize your edit cart form, we're in 1.x. You're able to add line item fields but that amount of customizable functionality took some extra code possibly. But now you have full control because the edit cart form is powered by the form display mode and field widget plugins. So basically get to cart form is a form for creating a line item and we work very hard to clean up that code since it was very complex in 1.x due to the many things that code actually needs to do. It was so complex, I think we have like a four year old issue about making it function more like a line item ad form. That's not resolved and probably won't be. Yeah, because of backwards compatibility it's really hard to fix things if they're going to break existing sites. And so here's an example of the managed form display UI. So the purchase entity is what says in the order this is the product that the customer bought and selecting the attributes is actually just a field widget which means that if you have an advanced use case you extend our plugin class and you can write your own field format or field widget to customize that experience. And then at the same time for the custom text that's the text field there. If you want to expose quantity you change that from being hidden to the number field widget. So if you don't want to show quantity you hide it in the form display if you want to drag it on up. Before that used to be a check box hidden in the field form matter for the ad card form and you may not have always known it was there but now it's one single place to edit your ad card form. It shows a general pattern of us not hiding things in the field UI in the settings for an actual field or an ordinary format or so that it's more accessible to users. And then if you want to read more about the ad card forms check out our blog and the blog post on the alpha three and right after that there's actually a blog post coming the fancy attributes and how to set that up and explore that. Yeah, so as I mentioned when I was talking about stores we actually support having multiple shopping carts now so if I have two stores and ad products from both stores I will actually see multiple carts and be able to check out each of them separately which is basically the UI the test was. You could technically use this to allow people to see both a previous cart as well as a current one but it's probably not the UX that you want. One thing that I have explained to you is I've had different sites I've built where customer support engineers need to build a cart for somebody and then the question is how do they build that cart and how does the user check out with it? Well now in carts do we cover that? Carts are now a flag. So your customer support engineer could build an order for somebody and then while it's still a draft say that this is a cart save it and then instruct a customer to visit the cart page. Well now this order that they've constructed for the customer is there and the customer can go check out. No longer do you need to say like well actually let's set up masquerade and say that we're that user and check out as them. No your support team can build orders and then the customer can easily go check out with them since they can have multiple carts. You don't have to worry about it being hidden because they already had a cart that was active. I mean speaking of both carts we had the new shopping cart block and 1.x we didn't ship with the shopping cart block did we? Yeah we did. And just a view of the two desks to the side of the bar. So now what happens is it does provide everybody has an icon on their cart so we have that provided by default and it's just using CSS so you can easily change it. It shows the count and then it will say items and this is a block that's configurable so you can change it from say items to say widgets or leave it blank because you don't want that. If you click on it it will display a drop down of an overview of the cart. Which is a view and you're able to either disable that or then customize a view. And it will actually show an overview for each available cart so if you supply if you allow for multiple carts they can then see an overview of everything that they have that's available. It does have like a max height set to like 350 or something of that sort so that way it doesn't take up your whole screen. And at the same time when it was added there is a layout CSS and a theme CSS file using the new D8 library system. So that way if you don't want our shopping cart or some of the styling we've done so it looks good in Bartek you un-set that library or override it with your theme. You can keep our layout library for the cart block so that way you get the generic styling for doing the drop down but then just remove our styling that makes it gray or fit in a certain way. So now you don't need any more exclamation point and importance to override our contrib styling. Is that asynchronously loading yet or is that still pending? It's loaded on render it's not asynchronously loaded. Okay. So the actual block is a good example of some of the UX research we did both for checkout and for carts where we analyzed over 30 most successful e-commerce experiences and we read many reports and just try to see what the most optimal experience should be and in the case of carts it was very obvious that every site actually only had this icon with an optional expansion with a summary instead of an always visible cart summary somewhere in the sidebar and for checkout that meant recognizing that we needed additional functionality which I'll show later. So checkout is one of the pieces that we pay the most attention to. We've easily spent a month working on this and the code that you can see is actually the third rewrite of the same concept. You can now have different checkout flows for different order types. You can create your own completely custom checkout flows since the checkout flows are actually just pluggable forms. If you want to implement a completely custom form you are free to do so. On the other hand, you can use our own implementation which supports checkout paints. Now the checkout paints are pieces of the form that contributed modules can provide. For example, a paint that allows you to agree to the terms and conditions or to enter the billing address or to select the payment methods. And we've redesigned the actual settings page for the checkout flow so it looks like the one for managed display where you can use AJAX to actually configure each of the paints. And of course all of this is exportable since it uses a combination of plugins and config entities. So thank you, D8 and CMI. I think that the patch for actually making that exportable in one of the text lines that a week ago. And the improved checkout UX is not there yet but you can already see some of the things that we have. We have a checkout progress block so you don't need the country module anymore. We have a page where you can log in or continue as guest or if you do not allow guest checkout you can register. And we have a redesigned review page where you can click edits to go back and edits are relevant part of the form and many, many other improvements that will be rolling out over the upcoming releases. You can read more about some of this work on the Alpha 4 blog post and there will be more in the next one. And finally we are working on payments. This is work that hasn't landed yet. It's on a branch on GitHub and I will be pushing more as soon as the conference Wi-Fi starts working again. So in any case what we realized in one of the text was that the payment modules were too large because they needed to implement UIs or capture industrializations for issuing refunds and then they needed to integrate with the country module to support tokenization so we decided to bring all of this functionality into core to make the modules really small. That means our API is twice as big as it was in one of the text and it's taking a little while longer but it also means that porting the individual gateways should require a lot, lot less time. And since we are using Composer which is pulling in libraries automatically that means that each of your gateways can actually require the SDK and that SDK will automatically be present and used. In one of the text we didn't use many SDKs because they required an extra step but now that they're installed automatically they can be used to further cut down on the time needed to write a payment gateway. And we are starting with Braintree as our number one implementation. We want to volunteer for Stripe because it will work pretty much the same way and then AcroMedia is also starting work on an authorized.net implementation which is also popular. We will be of course working on more gateways as time and client work allows leading up to the final release. And so the hidden undernote there is that there are actually Drupal 8 stores being built right now that need these payment gateways and that's why they're being developed. So I mean as far as like readiness goes like we're already beginning to use Drupal 8 and planning launches this year that are using these modules and others that we've talked about. I guess it's question time. Which I want to touch on Ryan. Ryan said because I'm sure one of the first questions was like well when can we start when we can do something. By end of summer we will have an enterprise each Drupal 8, Drupal Commerce site ready and good to go. So if you're wondering. Or you don't have a happy customer. That doesn't mean that yeah. It doesn't mean that 2.0 might be there but we're building and we need to be ready by the end of summer with an enterprise client. So if you're in discovery phase get started you can work on architecture and fields. You know as Ryan said until we hit beta you might have to do a reinstall but you're not really gonna be adding that much content right now. You're still in architectural phase and discovery and making sure that you know all the fields are in place what product types you need. So we don't have definite dates but like I said we have a go live at end of summer so. First question. Hi Chris Weber super fan. I am absolutely thrilled with all the work and just one second of nerding out great choice of working with Braintree they're excellent. I've been having a lot of joy working with them. My main question is about some of your early blog posts we were talking about how would be possible to write your own entities through custom code and then be able to extend some kind of base class in order to make sure that that is a thing that the system works with. You're saying to make them purchasable? To make them purchasable thank you. But what extra work am I signing up for? If I do that do I have to create my own custom forms to work with my own custom entity do I have to work with my own custom workflows that my custom entity goes through what part is it hook in and what parts will I have to sign up for as a developer? Yeah you would implement a completely custom entity type with its own at edit UI or you would generate one using Drupal console and you would make that purchasable. But I should mention that most people will not need to do this the products which variations have the architecture needed for the 99% use case. The reason why this exists is to support alternatives such as bundles or anything that's very client specific. We had some big enterprise clients that had completely custom product architectures and this allows those kinds of architectures to be immediately visible to the rest of the system so they can be purchased and as to the order and everything else. I guess what I'm asking is if I create a custom entity do I have to create a custom checkout? Do I have to create a custom? No the whole point of the API is that commerce is automatically aware of your entity type so it can be added to the cart checked out, a discount applied, taxes and so on. Hi. Hello, thank you for all your work. I'm still using Uber cart on Drupal 7. So my question is I have three different beauty stores on three different platforms and I don't want to write anything. I just want to import data, is that feeds or is there an easy way just to like, how can I get products in it without one at a time having employees like, you know. That's a lot of... So you're looking for a migration path, right? Well yeah, just something where I don't have to pay somebody to type in 1,000 products where I can just dump it all in there. So it's not a migration? Yeah, yeah, I mean so the feeds module's not... Feeds isn't really for Drupal 8. Yeah, I know for D8 the main feeds module is still under porting and like a commerce feeds isn't being ported right now. I'm currently focusing on commerce migrate myself but I've kind of been making that a path to work on those kind of things. So that way when we're ready with 2.0 we have one, I've been focusing on migration path. People are gonna want to migrate over but then I would like to see feeds integration. But actually we are working, if you have like a CSV file you have to write some code. There is some code involved but I know we're importing about like a few thousand variations using migrate source CSV and we have a full product catalog being populated right now into commerce 2.0 or 2.x using migrate. But there is some code that has to be written. So it's a not yet? Not yet. Will that be on your blog or can you need help testing because I wouldn't mind. I think for that I want to try to push the person who worked on that to write a blog. They've started to write some things. I like to poke and prod them a little bit more because we need that, we need that knowledge share and especially we need to give visibility to it ourselves. Because it would also be nice to have customers but you know a customer comes and they'll log in again if they really want something but it would be nice to have them as well but the products I feel like, you know. Yeah, the reason why the imports are not ready yet is because Matt is actually working on multiple targets. He's got data imports from CSVs and from Drupal 7 we are using the Kickstart data set as an example and from Uberkart. So very soon we will have all of these targets to import from but of course since the effort is probably taking a while. Okay, all right, thank you. Thank you. I was wondering about the inline entity form and its use and wondering whether or not you have on your roadmap to allow for custom display modes for example so that the rows that are added instead of having like that status column which I pretty much never use and maybe not just the title but a image of the product or that sort of thing. And I'm wondering if that's on your roadmap and how soon if it is. Not yet, not yet because we spent a month rewriting the guts of inline entity form to reduce technical debt and make it more flexible and we are still in that mode until the code is stabilized we won't be implementing new features but I'm guessing in a few months we should be able to start accepting basically adding that to the roadmap. I would accept patches in the meantime of course. Okay, thank you. Can you talk a little bit about your vision for inventory management and any potential integration with like external accounting software? I'm thinking in the case where you've got a brick-and-mortar store that's augmented by their online store. Yeah, so two days ago Guy Schneerson who did the commerce stock module for 1.x posted his vision for stocking 2.x and he already has code implemented and the idea is to support both external stock systems and tracking stock internally. So that's being worked on from multiple places it's not ready yet. I think it will take a while longer but it is- Just as long as it's on the radar that will be happening. Is Jin Sheng's blog post not relevant? Diana's ready to launch. Yeah, that's also relevant from a UI side. We'll make sure to actually link to that from our own blog and then tweet from our Twitter. Yeah, there's a contributors website in Shanghai that uses stock management and he basically created the first pass of the stock module for Drupal 8 and we'll continue to make sure that that's transactional, multi-locational where and so on. And I had a conversation with an Australian contributor in the same, maybe same situation where he has multiple physical retail locations and is extending that to work online and wants to make sure that's all synchronized. So that's- It's the people on the way of only buying what you're out of stock. Yeah. Yeah. Yeah. Thanks. You bet. Hey guys, big fan. Eric, Peter. Eric is my name. So the order types I think is really surprising. I wasn't expecting to see that. It's exciting to me because there was a sort of half working solution in Contrib which when you installed it kind of ended up breaking a lot of stuff. How tied into, say, fields and how dynamic is that kind of thing? Like if someone adds a physical product, you know, if you have digital and physical order types, can that be changed kind of on the fly? Maybe you flip from one order type to another. Right, exactly. Yeah, vice versa. I think it's a discussion for after this. It's generally not a problem. We, I designed it for both the case where you're basically funneling, shipping and digital products into different types or maybe having both of them in the same one. Both are possible. We have a really neat idea for how you could add the same fields for two multiple types. We're calling the idea trades. We'll be implementing that as well. But I'll be happy to continue that afterwards. Awesome, thanks. Thanks, Eric. Hey, Ryan. I'm really sorry for using the WooCommerce. Ha ha ha. Ha ha ha. Yeah, yeah. So Lee pinged me about a barbecue store, I guess last year, and ultimately decided not to use a triple commerce. Well, actually truth be told, I used UberCart in 2008. Yeah. Little did he know at the time, I also just released my first WordPress plugin. Ha ha ha. So. Well, there's a little bit of honesty there, but I wanted to say the last two people that asked that. Hello. Hey. I'm here. The last two people that asked questions really helped me to kind of see that migration of products and inventory and stuff like that is pretty important. And so you mentioned something about discovery phase. I would say that not just for my barbecue business, but for where I work, that's gonna be something that I'm going to probably be pretty active in and just voicing some opinion on different kinds of data that we might be pulling over from our systems, which are very proprietary at work. But I just want to congratulate you guys on everything that I saw here was, it was a, it was a god, it's good work. And I've been talking to my brother about our barbecue sauce website. And he's been troubleshooting an error with WordPress all day. Oh, not surprising. And he's pissed, he's pissed off. So I'm gonna give him a breath of fresh air that at least maybe by late summer or end of the year, we're gonna start playing around with the commerce too. So anyway, I had to give a confessional because I went from Shopify for a year and a half of being dinged to death by every little thing that I took for granted in Uber cart and Drupal commerce with other projects. Because a lot of the contributing modules you guys take for granted that you can use every day. If you go with like Magento or Shopify or something like that, get ready to shell out like 10, $15, $20 a month for each little thing that you think that you should be able to do out of the box. So hats off to these guys. And I look forward to end of the summer, early 2017. Hopefully we'll be selling our five barbecue products. I've got a huge, huge, huge list of them. I just heard a release date so I haven't even started the project. Yeah, I'm ready. I'm ready. We were just at an awkward point and I couldn't get it. But my question is my question is have you guys, I was looking at the entities and is it, I don't have a lot of experience with Drupal 8 yet but I have a weird way of making things into entities in Drupal 7 using like the data and schema module because that's where a lot of our stuff comes in. And it might help the other people that we're worrying about integration of the outside sources. Will any type of entity that is like an entity work be purchasable inventory or otherwise? You will need to explicitly code this to be that way. Like your entity pool needs to implement an interface. Okay. Part of the object-oriented nature of Drupal 8 is that you have interfaces that we can discover entity types that implement the interface and are therefore purchasable. In any case, let's explore your problem after the talk. Yeah, that's fine. I just, that's topical enough, but yeah, that's good. Cool. Thanks, man. Chris Urso, Sava Slabs, fellow Carolinian of the North Karate, nice to see you again, Ryan and Josh. Nice, nice. It's, maybe help me understand a little bit better. I guess my question, my question is are you all three just the primary folks working on commerce at the moment versus aero code and it's clear that you guys are working on some client work as well as the product and it's just clearly like a very important thing for the future of Drupal. And I'm sort of wondering if you're playing scale up or partner out more to ensure that you can. At the, I guess the core team within commerce guys is four people that are focused on developing Drupal commerce and then also doing consulting and architectural help and other development and integration work for customers. And I'd say that along the way we've probably had dedicated developers from a half dozen or more different Drupal agencies where people are willing to set aside somebody's time whether it's Sean or Jason from Acro Media to do work on UX or development. Gosh, was it, Thinkbean is gonna dedicate developer two days a week to help us during the build phase. So we're trying to scale ourselves by dedicating boy on not just two and developing commerce 2.x which we're able to still do full time but also to use them to integrate additional developers into the process. So I think that the core level of commerce guys have we've reduced the core team but it's still honestly a larger team focusing on Drupal commerce itself now than maybe it was before when we were very distracted. And then obviously like Acro Media and Actualis are both very helpful partners for us and not just delivering client services but also contributing to the development of the roadmap and modules and everything else. So I'm working full time, Matt is working about 20% and we're working to scaling him up but personally I would love it that we never actually have more than two full time people on commerce because commerce is not just our my project and Matt's, it's ours and we need to make sure that as a community we own it because it significantly reduces our bus factor and increases the ownership we have of the platform. So that it's not just me making the decisions that affect all of you but we are all together actually driving this thing forward. It looks great, I will see you at the sprints tomorrow and sorry I said Aero Media, it's Acro Media, my point. Orca, it's Orca Media. So we'll do the last two questions and then we'll wrap up, so go ahead. So earlier you touched upon. Oh you too, oh sorry. Oh my bad, we'll do the last three and then we'll wrap up. So earlier you touched upon the scalability problems that could occur in some implementations of commerce one. Can you talk more on the work that's been done to improve that for commerce two? Recommend read committed as your transaction isolation level by default, that gets you 90% of the way there. Yeah so some of the things we're doing, we've rethought locking because previously the pessimistic locking we were using didn't cause some problems for people who were not using the read committed transaction isolation mode so we are trying to make that better by switching to a combination of optimistic locking with explicit locking when needed. We are also reducing the number of inserts that are happening during the checkout, for example there are no more order revisions because they were just taking up space while increasing the number of queries. So it's a long death path and we'll be pursuing other optimizations as time allows after the day. Also we've made the decision to defer certain types of price calculations until actually necessary as opposed to the sort of commerce one.x method of on every page request recalculating pricing from scratch and also just like pursuing asynchronous like loading of dynamic elements like the shopping cart block. Like I said it's not done yet but we won't launch commerce two.0 without that being asynchronous and interested to hear more war stories and see what else we can do to improve the core. Okay, lovely, thank you. Yeah. I don't stand so well so I would say. No problem. Hello Ryan. This may be both trivial and misdirected but the way I learned how to use commerce was videos and so I'm just curious are there going to be videos for commerce too? Oh I don't know. Yeah Sean will make them. He just volunteered. Yeah, I mean we did the Drupalize Me series back in the day for commerce one.x and then we'll be able to work with Acromedia to do the same for commerce two.x and probably other partners as well. We just committed them to it so. Yeah, yeah. So this might play a little bit into the brain tree integration that you're working on but just the payments model in general is like recurring billing and sort of decoupling transactions from orders because you might make an order and then you'll rebuild against it for months or whatever like that. So that's something that kind of had to be filled in contrib space and in one.x but I don't know what your vision is for accounting for asynchronous transactions later on. The tokenization is in core so the change we made card on file is no longer a contrib module and that allows you to do recurring then in contrib recurring will definitely stay in contrib because that's use case specific and we are keeping the same general approach and in generally whenever you recur you really want to generate an order because that is the thing you are invoicing that is the record of the transaction that has taken place and the payment is a side thing just a record of the actual money transfer occurring. So you're envisioning is that gonna be in core or are you expecting that contrib is gonna handle in contrib suite like order creation on recurring? Yeah that's what commerce license billing does today for Drupal 7 and it's being ported already to Drupal 8 as well for our client sites. Well commerce license billing is in commerce licenses so commerce license billing will is yet to be started but we would be providing a similar approach in Drupal 8 as well. Thanks. Yeah. All right well thank you very much for everybody's time. I'm gonna enjoy the rest of the conference. Hey Mark. Thanks Steve. Yeah I think I know the... Okay. Oh yeah yeah yeah. Maybe we'll back port improvements as we can. In fact we're working with the client that's already like funding the back port of these new features we have. But we're trying to keep it minimal because of backwards compatibility. This is great.