 I am Ryan Sarama, this is Matt Glomman, and we are here to talk about launching online stores with Commerce 2.x on Drupal 8. We actually gave a version of this presentation in New Orleans where we were talking about building stores. Today, we actually get to talk about launching our first really large nice site, and we'll be demoing that and talking about it during the presentation. Together, we make up two-thirds of the core team of Commerce Guys. Boyan Zavanovich is not with us, that's why his name was in parentheses. He is back home. We're going to go join him after Dublin and Belgrade for some bicycle riding and late night dancing and then group hugs on the couch. We are what remained of the Commerce Guys team after we spun out from Platform.sh and then partnered with our two affiliates, Acromedia and Actualis, to deliver Drupal Commerce services as Commerce Guys in North America and then also in Europe. At the core team, we're all the maintainers of Drupal Commerce. We offer performance consulting services around Drupal Commerce, but we're also really engaged, obviously full-time for Boyan, part-time for us on developing and maintaining Drupal Commerce 2.x and other projects that ultimately tie into our mission of engineering simpler solutions to the hardest parts of selling online. Sometimes I guess the hardest parts aren't even what you might think they would be. It's not always about the software. More often it's about the fulfillment process, the reconciliation process for accounting and so on. So we get to really flex a lot of different muscles to help people sell lots of things using Drupal Commerce. And recently, you know, we had a chance to rethink why Drupal Commerce. Because historically, Commerce Guys, I co-founded it in 2009 with two guys at DrupalCon DC and we were just building UberCart sites and delivering services around UberCart at the time. And then Drupal Commerce is really just then sort of our default next iteration of UberCart whenever we hit Drupal 7. And so the question often comes up, like is there really a place for Drupal Commerce when you have Magento or Shopify, which we often recommend to our lower-end clients? So what is the place for Drupal Commerce in the general e-commerce ecosystem? And so with Drupal 8 coming out, Commerce 2.x coming out, we had a chance to just think again, OK, what is it that's distinctive about Drupal and Drupal Commerce that we deliver to the market that nobody else does? And really at the top of the list is that we do believe in free software and most other even open-source solutions, our dual-licensed or semi-proprietary or what have you, Crippleware, if you will. And we truly believe in making and writing and distributing free software and ensuring that everybody gets to benefit from that. But that's not enough to sell a business on a tool. You also kind of have to be good. You have to be built on a flexible business application platform. And that's what we believe Drupal provides us, even more so with Drupal 8. We recently had a chance to speak with the CTO of Oro, which is a CRM and Commerce product that spun out of Magento back in the day. And the first step for them in creating Oro CRM and then Oro Commerce was creating a business application platform from scratch. So imagine a four-person team sitting down to write a Drupal and a views and a rules and an entity API and everything else that's required to create business applications. And we don't have to do that because we natively extend Drupal to do e-commerce and get all the benefits that that brings us. Additionally, we believe that both merchants as the end users and developers as those that don't want to learn how to maintain multiple different systems benefit from combining both your commerce and your content, marketing and sales sort of channels in one piece of software. So we still believe that's a very legitimate use case for Drupal and Drupal Commerce and many of our highest profile largest customers echo that back to us in ways that are much more clear and compelling than I just described to you. And finally, we believe that Drupal Commerce works great when paired with third party applications. And so we often talk with our prospects about this continuum of responsibility where Drupal Commerce can do as much or as little of the sales process as you need it to do. Cuz there are many things that go into creating and completing and finalizing an order in an e-commerce website. And so you may have some shopping carts that exist only in your Drupal application. And they're full of products that exist actually in a third party PIM but are permanently duplicated and then synchronized in the Drupal site. Then whenever you're creating an order, you might do tax rate calculation or shipping calculation that's real time and never actually powered by the Drupal site itself. And so you kind of just have Drupal sitting as this controller that connects to all of your different back end services. And that's where we found a real strength for Drupal and Drupal e-commerce sites. At the end of the day, you can do much with it. You can extend a content site to do commerce, such as taking UNICEF's website, for example, and adding a donation platform to it without having to introduce a new technology and try to integrate them together. You can expand your business internationally and suddenly get free, multilingual, multi-currency, international tax support, et cetera, out of the box. And you might also address the unique challenges of multiple types of users, including B2C and B2B and VIP and everything else, Acronomy, together in one application, like the recently launched Obermeier.com. And we'll be talking about this. Matt's been heavily involved in this project along with the BlueSpark team. So I think BlueSpark is here somewhere, right? So BlueSpark came to us and asked for assistance in architecting and launching Sport Obermeier's new website. And we'll be showing just how that's impacted the development of Drupal Commerce 2.x, and also the great work that their team has done. And then the ways that Matt was just able to use that project to improve core parts of Commerce 2.x itself, which is really cool and our ideal partnership because we don't have design bones in our body. I'm up here wearing a three-year-old T-shirt and four-year-old shoes. And don't really think about appearances so much, but they were able to create something that was very beautiful, very functional. And with a great internal UX team, and we were able to bring the sort of commerce know-how and expertise to bear to create a really special project. So that's where we are today. We started Drupal Commerce in 2014, and here we are in September, almost October of 2016, launching very complex enterprise e-commerce sites using the new version that will be tagged today as a beta. But the foundation was laid in 2014 to build Drupal Commerce 2.x from scratch on Drupal 8, which is similar to the approach that we took on Drupal 7, where we redesigned e-commerce on D7 around the field API. Well now we get to sort of redesign around all the new core concepts in Drupal 8. The latest beta, if you've been following the alpha releases includes the payment, pricing, and promotion systems that we'll be discussing. And we also now will officially maintain an update path between beta releases. I think until now you've probably rebuilt your site how many times? Every breaking change. Yeah, so no more of those, well at least no more breaking changes. No more breaking changes. Update paths, yeah. So whenever we sat back to re-imagine e-commerce on Drupal 8, we wanted to think through what were some of the key lessons that we learned in the Drupal 7 development life cycle. And the first was that we want to prioritize user experience from the start, which means in a lot of ways going to a variety of Shopify stores and seeing what they've done well. Fortunately, it also means looking at some of the best examples of Drupal Commerce implementations like the Olsen-Gurthel website, which I always talk about, and seeing what really is either trend setting and or just really simple from a user experience standpoint and encoding that logic by default into Drupal Commerce. Instead of making it an afterthought like we did in Drupal 7, we're also providing more direction and mentorship to other developers and agencies that wanted to be a part of the process. How many contributors do we have to Drupal Commerce in the room? Are there some at least? I see, okay, like 20 or so hands came up. All right, Scott, good computer. One bug when he fixed a comment, I think. But Boyan Zvonovich is the Commerce 2.x lead and he's done so much better than I ever did at engaging agencies and really training their teams and involving them. And then other agencies have been very generous. I think Wunderkraut and they're gonna slip my mind. Other other agencies around Europe that I don't know that are in Serbia and Slovenia, yeah. Is there somebody in Greece? Maybe, maybe somebody in, there are people in Greece, yeah, yeah, okay. But different Drupal agencies have sort of lintess developers over time. And also some even in the US, thank being generously donated, a summer's full of Matt's Mondays to contribute directly to Commerce 2.x. And so we're really working to build that consensus, so it's not just a Commerce Guys project because there's way more here than we as a small dedicated team can do. And so we're trying to be more educational to the community to make sure that everyone knows how to make Drupal Commerce work for them. And then finally we're incorporating more critical functionality into the core project itself. So that's why, yeah, the motions and. I mean to touch on that Obermeyer, there's no contributed commerce projects. And except for Commerce Migrate to import from the ERP. So that full-fledged e-commerce site, no contrib. Yeah. So we were able to do it all without needing like 20 different contributed modules to extend core. Yeah, yeah, it's kind of neat. Yeah, maybe that's also why we haven't released the beta before now. It's a two-edged sword. And that was not a carted chap. It was a sword. As of today, we are also dependent on the latest version of Drupal 8 itself. So something that's changed, that's kind of been revolutionary to Drupal 8 is that you have more minor releases that are bringing new features and new modules to the Drupal 8 branch without breaking backwards compatibility. But bringing great improvements to things like composer support, entity API permissions, and so on that we needed to take advantage of. So a lot of our work in developing Commerce 2.x has really been improving Drupal 8 even post-release so that we can then sort of move the goalpost for where we have a dependency. So currently as of RC1 for Drupal 8.2.0, we're dependent on that branch and we'll continue to follow core because a lot of the core that we write ends up in core and we want more of it to end up in core than has already. So there are some large things that came out of the Drupal Commerce development process in core like the entity reference field module. The views forms functionality, all that that's part of core was in Drupal Commerce on the D7 cycle. And now we're continuing to improve the entity API, like I said, permission support. Plug-ins. Yeah, the plug-in forms that you can have multiple forms per plug-in type and on and on. Condition reference or plug-in reference fields and a lot of stuff that ultimately we want less and less code for us to have to maintain in Commerce itself and for you to have to work with in Commerce itself and more just of a stronger base foundation. But it doesn't mean that Composer is a requirement now and some people really kind of freak out at that. But I know that Yoris, shoot Yoris, are you in here? What's your company name? Boris on on Drupal.org is actually creating even a UI for managing Composer based projects that should simplify the experience for new users that aren't used to CLIs or command line interfaces. But Composer's requirement because we are getting off the Drupal Island and we are taking advantage of third party libraries in various parts of Drupal itself. But we also, just like we sort of reinvented how complex modules on Drupal 7 would use the entity and field system with Commerce, this go around. We're actually trying to lead the way on putting more of our code into standalone generic PHP libraries that we then depend on in our modules. So getting off the island doesn't just mean finding cool projects out there. And depending on them, it also means taking the knowledge and the experience that we've gained as Drupal developers, as website developers in general, and exporting that to the broader PHP community. So we now have five different projects up on GitHub that are distributed through packages and available via Composer. For you, some other projects, I guess a few here on the screen. But the main one that's being used elsewhere is the tax library, which powers, I think, tax calculation in Foxy Cart, which is a SaaS-based PHP-based application. And addressing to your own. Yeah, I don't know, I don't know if they're using addressing or not. But the idea here is that these are libraries that encode very specific, like general, but very specific knowledge, like what was the tax rate in the UK for certain types of merchandise from one year to the next? When did the tax rate change? So at any point in time I can go and see what the taxes were on items in an order. The addressing library is another really cool project that sort of was born out of Damian Torneud, our CTO at Commerce Guys, now CTO of Platform.sh. Just emailing Google and saying, hey, can we re-license and redistribute the Android SDK's address format and form generation rules? And they said, sure, why not? And so now Boyan, as a result of this library, is actually a contributor to the Android SDK, which is kind of fun to see like this little humble Drupal project now impacting form creation on your iPhone, or not your iPhone, but on your Android phone, sorry. And on and on, so the INTL libraries, I think, been adopted in some respect by Symphony Core itself. And we sort of continue to find ways to export our generalized e-commerce knowledge because we can then bring more people to the table to maintain some of those address and tax rules and requirements without any of that really being dependent on Drupal itself. And this is actually an approach that we've taken in our Drupal 7 project still, is to create payment gateway integrations or other API integrations as just a standalone PHP library. We use dependency injection to inject them like the callables that might hook into the Drupal module implementation of the API. But we're sort of trying to adopt the mindset of just PHP first and then Drupal second as far as, yeah, I mean. Even with the, well, we'll get to payments, but authorize that net SDK library. It's proprietary licensed, can't use it with Drupal, and it's also requires Symphony YAML 3 where Drupal's tagged at 2.x. It's at 2.8, so it's conflicting. Open that up, actually found a few others that were upset about the license and just how the SDK was formed. So our new one, using Guzzle, is adopted by at least three other contributors who are now opening pull requests. They added bank support. I just did credit cards, now we have bank support. So that can automatically now be pulled in. We've kind of dispersed the amount of work to the wider PHP community. And now we can pull those in and let you build bigger, stronger sites. Yeah, yeah, I think that module ended up being about like 150 lines of code for full payment gateway integration. Yeah. Which is not what you're used to on Drupal 7 if you've written a payment gateway module. I don't think any of mine were less than like 1,000 lines at least. Lots of forms. To create a new Drupal commerce site, if you wanted to try it out, you can do it completely using Composer. So Matt maintains a project base that kind of takes the place of Commerce Kickstart 1.x that kind of pulled all the basic components of Drupal Commerce together. And so just with one create project command, you get the full Drupal 8 installation commerce, all of its dependencies. Is there any demo or initial configuration? There's no official demo yet. I have a sandbox module on my personal GitHub that I want to flush out a little bit more and put it on Drupal.org, but it does import sample data that allows you to have a quick startup and demo site. And then you can also use Composer now to add Commerce to an existing Drupal 8 project thanks to the package manager work that the Drupal Association has been sponsoring and got rolled out to Drupal.org itself. So you add the Drupal package repository or package management repository, and then you can use Composer required to install Drupal Commerce on your D8 site. And as a side note, right now you have to add that packages remote, but it sounds like they're going to be taking it out of beta soon. And I'm assuming that means committed to core, which probably would be part of 8.2, one reason for the requirement. And there's more information at the documentation if you want to know how to get started. All right, so the next thing to talk about is module dependencies. We've always had them. And I believe we may have more of this go around than we did in 1.x. It's been distributed out a lot more. And part of that is a result of just wanting to, like I said, improve the user experience out of the box. So many of us will be familiar in Drupal 7 with the architecture of products requiring the creation of your product variances, standalone product entities, and then a product display node type that referenced all of them together and turned it into an added card form. And that's probably the most common complaint about Drupal Commerce is this is too complicated. This takes too much time to set up a store. And the reality is that every single e-commerce application has the same architecture. We just didn't have an inline entity form dependency out of the box. We developed this after we released Commerce 1.x. And so you had to create the variance in one place and then tie them to something else in another place. So the inline entity form dependency allows us to create just a single product page where you're inching all of your product data. We then use that same form for line item editing and customer profile management. Promotions is going to use it. Promotions will use it, yeah. And so a lot of our field and entity code that we had to create, I guess, for each entity type and each field type in Commerce 1.x will just be replaced by the inline entity form and its plug-ins for those different entity types. I have payment, too. It's everywhere. Yeah, and I guess the media module is also dependent on inline entity form now, so we're getting more people contributing to that and helping us maintain it, which again is great for a small team. If you have an interest in contributing in any way to Drupal Commerce and just thinking, OK, how can I contribute to one of these modules? It would also be very helpful. The profile module is another example where we use this for our customer profile types instead of creating our own sort of separate idea of a profile within Commerce. State Machine is another example where we knew that we wanted to have more robust workflows for orders and line item-based fulfillment, payment, shipment, fulfillment, all that kind of stuff. So rather than just encode workflow and state controls into Commerce itself, we kind of took over the state machine project and made that our own. And now we depend on that for checkout workflows, for order workflows, payment, et cetera. The address field module is being supplanted by the address module, which again is dependent on our third party library. This has full functionality for creating forms, storing addresses, formatting them for any locale, because it looks different to format the Chinese address in English versus Chinese. All that stuff is encoded into the library, and the module then just ties that into Drupal itself. Oh shoot, I've got ahead of myself. But this is the UI for that. We also have the zone library that address depends on to group things together so you can say, well, is this order from the EU? Is it from certain states? What states do I have tax nexus in in the US? You can sort of create these ad hoc zones that you then use for simplified conditions around taxes, shipping, special fulfillment requirements, and whatever else. I don't think we have other dependencies. If we do, I forgot them, and they're not on the slides. I mean, there is the entity module as a dependency. It's not really listed here, but it's a sandbox. Just like chaos tools is still around to be an incubator for core. All of our experimental entity improvements either go into commerce and then port it into entity, or rather just into entity, and then we work with other contributors to move that into core for the next minor release, such as making the developer experience around entities better. We just wrote a full entity permission generator. It's in commerce now to generalize it for entity, and then the road to core. That's like the only other one, I think. OK. Great. We'll add one in a beta release and surprise everybody. I'm just kidding. All right, so let's talk about commerce 2.x features themselves. We said that commerce itself is now more robust. We're including more out of the box, so that there's less busy work to find all the right modules and tie them together. And one of the things that's drastically improved in commerce 2 is our currency management. So rather than try to maintain a full library of currency data on our own, we're taking advantage of the CLDR projects library of locale specific currency formatting. So we know how to format the euro for Germany versus France versus the US. We know how to format the dollars for Canada versus the US versus Australia, and so on. And the idea is that you simply import the currencies you want to use. And whenever they're formatted, they will be locale specific. Although you can edit the actual implementation if you want to or define your own pseudo currency for store credits or Bitcoin or whatever else it is that you're using. Once you create your currencies, of course you can alter the formats and then begin to assign currencies to stores. And I will go back. At each section, we have blog posts that detail the particular feature and how they were developed. I'm not going to sit on these slides much because we're putting the slides online, and you can just click the link. It's a lot easier. So with stores, the idea here is that you can have any number of currencies active per store. And we have support for any number of stores out of the box as well. I'm about to sneeze. I'm going to step away and let Matt take it. So the nice part is in 1.x, if you had a store phone, how would you set that? You wouldn't really have a store address. It was difficult to specify that. Well, now all those general global config items belong on the store entity. So now each store has its own address, its own default currency, all that. And it allows us to have orders belong to a specific store and then specify which products are sold in a store. So then you can have your international stores listed on one site, but then restrict, well, we can only sell this product in the EU and can help restrict where things are sold based on the customer's billing location. And I think other platforms might refer to them as channels as well. I think Shopify has the channels that you can publish products to. We actually discuss that. And I think of channels as social media is a channel. Google is a channel. Amazon is a channel to call your store where you're actually selling from. It's bike shedding. And you also were able to make use of this on the overall project. So one of the beautiful parts about this is just the general data model, a store that has an address by default. Well, at Obermeyer, they have partners where you get sent off-site to buy from or physical locations that buy stock. We're able to use this to build the off-site redirection and also generate a map of who has bought what and has what possibly in stock. So now users can go find in the store. And it's literally using the store entity and building a map off of it. So we were able to reduce a bunch of code that we'd have to write by just reusing that data model and being able to tie it all in with the existing API. I think there was a commerce marketplace module and maybe one or two other related modules for this sort of functionality in commerce1.x. And so the idea here is that rather than make this a separate contrib concern, it's pretty common for people to have multiple domains or stores or physical locations, physical fulfillment centers, and so on. So this entity type is new for 2.x and solves a lot of those use cases, including marketplaces as well. So like an Etsy or Amazon style marketplace where you have multiple shopping carts and then choose if you want to check them all out at once or check them out in succession, and so on. Do we have a question about stores? Will we be able to share between stores? Will we be able to share users, shopping carts, for instance? Yes, yes, so the store is, I think of it like a glorified taxonomy term. So it doesn't actually create a separate store or a separate database or separate site or anything like that. They can only exist in one domain and purely be behind the scenes if you need. We've talked with other folks about using a store per TLD to identify which country I might publish products to. So the classic use case for us at Commerce Guys was building the Cartier store, which had a single PIM, a product information management system that we built in Drupal 7, and then published products out to the different TLDs for US, FR, JP, et cetera. And in that case, the store entity just sort of defined where something should be published, kind of like a domain access-y kind of thing. But everything else is shared. It's purely, is this product visible in this store context or not? And does this order belong to this store? Although orders can only belong to one store. You can't mix stores for orders. It's a glorified text on the term for right now. It's open-ended for you can turn it into many things if you want it to. And there's more about that on the blog as well. So I'm happy to chat about that more after. For taxes, then, we have the standalone tax library that covers most of the European VAT requirements. And Australia. And Australia. David could correct us if we're wrong. But it's sort of an extension of the work that David and others did on Drupal 7 to build the commerce VAT and commerce EU VAT modules. This logic has now been turned into a standalone PHP library that we can share with anybody else in the PHP community. And like I said, we're getting corrections back. So I think Foxycard recently contributed back a fix to how we were calculating VAT rates for US-based merchants that were selling into different countries. And it's a really classic example of why we wanted to open this up to the broader community to begin with. We also have tax resolvers for all the major use cases because you have different requirements for physical products versus digital products, B2B versus B2C. And then for more complicated tax requirements, which would include US-style sales taxes, we integrate with Avalara, which offers sales tax automation and tax remittance and reporting and so on. And they also do have global VAT support now. And we're continuing to work with them to improve that integration and kind of treat that as a first-class citizen alongside the basic core tax support that you will get out of Drupal Commerce itself. So for products, the big change here is that, like I said, rather than have nodes that then render referenced products via an add to cart form display formatter, you actually have product entities. The product entity is what most everyone in the world, except for the three of us at the time we were designing Commerce 1.x, thinks of as an actual page that lists products for sale. And the idea is that the product page is now, we're sort of conceiving this as the node in Drupal 7. And it references all of the products via a default product variant reference field. And you will edit those using the inline entity form so you have all of your variations. But then it just sort of gives you one place to go and edit as a merchant who doesn't understand what entities are or why references work or how that all ties together. I don't know if you have anything specific to talk about from? No, it's just it gives a really inline experience. Like you just edit that form, go in, and you're out. And did it simplify how you actually built the Overmire catalog to not have to worry about the reference? So one thing is that it allows us to have more control of that reference. We can say the product knows what its variations are and the variations are aware of the product. So when we do an import, we can just say, we can create that product and then go like, all right, all the variations is who you belong to, save them. And it does the automatic back reference. So it's definitely a developer experience if you are importing from ERP, which is mostly just like, here's all your variations. And one of the common drawbacks of the architecture on 1.x was having to continually query the database to try to find which node is at the reference to this product. And then you get into situations where multiple nodes reference a product. And we're trying to find the page to send somebody to review a product if there's multiple options. It's kind of hard to know which one to send them to. It is a one to one. There can only be, that variant would only live on one product just like you typically would have when you sold products in a physical realm. But product attributes function very similar to how they did in 1.x in that it is a reference field from the product variant entity to some other kind of entity. But rather than sort of piggyback off of the taxonomy module, which is what we often recommended in 1.x, we now have specific attribute and attribute option entity types that we use to define all of your different attributes and options and then enable them on a per product type basis. And again, as with products and product variants, having this sort of deeper understanding within Drupal Commerce of how the different entities are related, this lets us control a lot more how and when attribute values are created and destroyed. So for example, if I was selling products on Drupal 7 and using taxonomy terms as attribute values for t-shirt sizes or cell phone cases or something, well, if I accidentally deleted a taxonomy term because you could, suddenly a product data model is broken for all of your historical orders because you can't get that TID back that represented that color of product. Similar, if you were dependent on just a list text field or something and deleted an option or couldn't add options after the fact. So this is just a much more robust way of managing that data model, controlling what can get deleted and created when and also just improving the UX. Because we know that if you have an attribute type, then it just can be enabled as an attribute on a certain product type. Whereas with taxonomy, we didn't know which taxonomy vocabulary was an attribute type or not. And also just the merchant experience and your own experience when building the store instead of having to leave the context of I'm in the commerce section editing my shop. You don't have to leave and go like structure taxonomy to this whole different section that has no correlation or context. You're in there, you're editing and actually to pop back, if you have internationalization on and you're translating, you control the translations from here too and any other fields added to the product attributes. So it's a one-stop shop for editing which will be a huge architect, like when you're building your store it'll be a huge experience gain. All right, so then once you have product pages you have an added cart form that is similarly a display formatter for that variant reference field. The added cart form has attributes just like we did before with multiple widget types but we also have, I don't think we actually have a slide for it. Yep, right. No, is that fancy attributes? Not, well, yeah, we don't have a slide. Yeah, a little side chatter, sorry. We have support in core now for what we call fancy attributes in commerce 1.x which is the idea that you might use an image to represent an attribute selection on a product page to choose a color or a pattern or something to that effect or any other type of display. I know some people that like to, maybe Sport does it, sizes might be like a bunch of boxes where you click on a size and have availability visible. So in Obermeyer we have images, every color has an image. I have actually a blog post on a Drupal commerce site that talks about enabling this. So that killed about like two or three contribute you would need to have, that added cart experience you saw everywhere is now something that you can do in core harnessing the form display modes and the field API. So we didn't write anything custom, we harness the new APIs in Drupal 8 and some of the new features. Yep, and are form display modes familiar to people? We know what display modes are for, or view modes are for nodes, right? You can have a teaser versus a full page, et cetera. So in Drupal 8, they actually added the concept of form modes, which is what you see in this screenshot. It's just kinda small, so maybe you can't really see it. But the idea is that we can say that this form can be rendered and displayed in multiple different contexts and then have widget selection and options much like you can for display form matters on the display side. And so that lets us do things like improve the support for line item fields appearing on the added cart form. I think before you had to find and know to check a checkbox and the field config. Now you drag it from disable to there and also it allows you to customize the added cart form more. Obermeyer actually doesn't use any of this. It pulls the image from that variant. So it's not even from the attribute, but all I had to do was extend our class. I had to do two tweaks, make a new field widget and I was done. I didn't have to hack anything or copy and paste any code. I extended the class, little bit of logic change. Went into this form and I checked it, dropped down, picked something different and we have a very unique experience that meets the customer's need with minimal effort. Yeah, and the reason this works too is that the add to cart form is basically a line item add form. It's much like you go hit add a node and you fill in all the info you need. Well, when you're adding something to the cart, you're creating a line item that's being added to an order that's functioning as a shopping cart. Oh, for example, a shopping cart, okay, great. So there's actually like a little checkbox that identifies this order is currently a shopping cart. It's also in a draft state, so it hasn't been published yet. And we've sort of improved our handling around timestamps and major order workflow events. From what we had in 1.x, where we just had the created and updated timestamps. And if you wanted to know, well, when did the customer actually complete checkout? You had to essentially abuse the created timestamp and reset that on checkout completion or something. And there was a bit of naivety on my part at the time. We thought, oh, well, we'll have revisions for everything. We're gonna just look at the revisions and find when checkout was completed. But working with revisions is actually pretty difficult in Drupal 7 and I'm not sure it's much better in Drupal 8. And so instead of trying to make use of a lot of sort of derived logic and derived data from their full database server visions, we're now trying to make things like this more explicit. This order was placed on such and such a date, even though the entity itself was created way back when. And then for anything more complex, you'd more than likely just integrate with a third party like analytics application. But once the shopping cart is created, you can view it in a views driven cart block, much like before, although Matt did work, I guess, was that part of Obermeyer to make this all JavaScripty and fun, or was that? This, actually, no, I don't think any of this. It was just your weekend. Yeah, it was a weekend product. It was just a weekend start. We do have it where we looked at every other e-commerce site that we could find and what were the similar traits with the cart block. Icon, Count, and Texas as items. So we had that, we provide the default icon, which we are using D8's new library system to make it easily swappable. So just un-set our one style sheet that says the icon, which would let you still have some of the layout benefits you'd like to drop down and replace your icon. We notice that most carts have a click and then drop down to review, so now we have that. And if you want to disable it, you can just edit the cart block and say, no, I do not want to drop down. And you're, again, able to swap out that library or use the extent, or you can extend it to then add your own JavaScript. Let's say you want it to be using the Bootstrap library. Well, extend it, convert it to Bootstrap, and it will just seamlessly work. And in addition to what we're trying to do here with commerce2.exe is think about some of the performance concerns that we introduced in 1.x by being too aggressive and recalculating prices or always showing dynamic content on a page. So whenever you have a shopping cart block that looks like this, you probably have the order load and then you have all the line item loads and you have the product loads to be able to define all this data. And then loading an order might trigger price calculation which then might trigger another price calculation and entity sales and yada yada yada. So in D7, it can be kind of tricky to sort of unwind all of that and actually perform at scale. So we have users that are currently operating around like six to 800 peak concurrent transactions and we want to get them up even higher and higher. And so there are plenty of Drupal commerce sites in D7 that are doing thousands of transactions an hour. But what we want them to do is have less to work against in Drupal 8 than they have to in Drupal 7. And so in ideal scenario, this block for example would be lazy loaded and you can use big pipe to load it in after the page has already been returned. And I'm... Which most of our stuff, if you attended Fabian's session last night or at the end of the day, we are implementing lazy builders, proper cash tags because we want this thing to zip and fly. So you have, I mean, you don't make conversions on a slow e-commerce site. And we also have introduced multiple levels of price calculations. So you can do a shallow calculation that's good enough for the shopping cart block. But then when you get to check out, do the full of our bus price calculation that may include fees and taxes and shipping rates and all that kind of thing. The forms are, okay, the forms pretty similar to 1.x. Using views to build the forms, we just don't have to maintain the views form functionality anymore. You can also have multiple order types and order item types, which are line items in commerce 2.x. Which actually, well, to touch on, do we have a, is it the order form next? No, yeah, let's check out. So the next, when you can, with the order types what's nice, is that cart block, you can specify what the view is supposed to be for that. And then also the cart form can be decided based on the order type. So if you have a digital order type and a physical order type, there's certain things that you need to show to the customer, and that can allow you to have a different form that maybe shows like a different view mode for that one product. So it allows you to have control, we're giving you different types, we're allowing you to control how it's displayed in different areas. Which then comes to bear whenever you get to the checkout form as well, because you have multiple types of orders. So for your B2B customers versus B2C or your VIP customers, as is the case with Obermeyer, you can use multiple checkout workflows. So I create a checkout flow and I assign it to an order type. And so then rather than having to hook into the, you know, checkout form builder and validate and submit handlers and override validate callbacks because they all get called regardless of what they were shown in the form. Rather than having to hook into the commerce checkout router, what you do now instead of all of that to create custom checkout flows for different types of orders is create a new checkout flow. And then you assign that to the order type and it's going to just work. And I think you had a really good experience with a single page checkout. So Obermeyer has like an editable card. Yeah, so Obermeyer has three customer personas, I call them, which have different buying flows for each. And they're, you know, B2C, they actually get brought off site, but the VIP is like a privilege as a user who gets to buy direct. They have a single page checkout that has an order overview that's actually an editable card form. And we were able to use this checkout flows or just a plugin and our checkout is just regular form API. We're actually not using panes there, but you could, so you could have a very simplistic checkout form that doesn't have all the extra stuff or you could have this robust pain system that lets you drag and drop and use a UI builder. So if you're not one for the UI, you can jump right in or if you are like a site builder and you don't want to touch the code, you could drag and drop a bit. And it is, one thing that buoyanted it is he actually mimicked the field UI for managing the checkout flow, which is a huge improvement if used at 1.x. So to change pains, you just move them up or down. If you need to configure them, you click the cog. Ajax is in the form. A big one for this is now we support login and it can say force registration or just let them continue as guests. Yeah, which was a contributor module on 1.x that basically became part of the improved for UX. Yeah, yeah. And so the idea is that the first step of the default checkout form now is to log in or continue as guests and I think there's also a registration option like managing them to show up on the right. Yeah, so they can continue as guests who swap to a form and taps into the normal registration form and validates them. Yeah. And it's kind of getting into a gray area of what modules should do to do things like design a two column interface because it may not work well in every theme. But again, with the library system and the ability to... And having a bit twig and D8 makes this a lot easier too. So this is just a twig form. It's the default twig form. If you don't like it, take it out. Swap out your classes. It's much easier to override theming defaults in D8 than it was in D7. So we want to give you a best practice out of the box experience which 80% of all sites, it's this. And if you do not like it, you override the library, override the twig template. You know, in like five minutes, you can undo this. Yeah. And it looks pretty simple and plain and boring on the screen but like I think Boyan probably went through about a hundred different checkout flows and we've got a huge library of screenshots and no somewhat words. My skidges. Yeah. And then also benchmarked against Shopify, BigCommerce, WooCommerce, who else? Spree. Spree, Magento, et cetera, et cetera. To try to say, okay, what are the things that we can do? Whether that's, you know, checkout to a continuous guest or log in to a continuous guest or have like a two column checkout form where the summary is sort of persistent on the right hand column as you fill out the form on the left hand side. We've also done things like create a credit card tokenization and improve payment forms out of the box so you can enter in your credit card or, you know, reuse an existing one out of the box based on, you know, API availability for your chosen payment gateway. All of these things are just sort of designed to improve the overall user experience whenever you just first install Drupal Commerce. And as I said earlier, the beta release includes the payment API so you can begin porting your payment gateway modules to Drupal Commerce 2. We focused first on Braintree, who generously sponsored a lot of the work to develop a lot of the API's support for tokenization and for shared management solutions where you essentially have an iframe embedded into the checkout form on your own page that may or may not be customized, you know, to match your theme. Braintree's is really ingenious in that you actually have separate iframes for all of the different fields. So it's one iframe for the credit card number, one for the expiration month, one for the expiration year, and you can then completely theme and style those and place them exactly how you want. It's really cool. So creating, you know, using them in their most complex API by default, then ensured that, you know, the downstream simpler payment gateways would necessarily be supported as well. And I said already to the authorize.net just sort of basic API, the AIM API. You know, it was like 150 lines of code because we have all of the payment forms supported by our payment method plugins. We also, and this is a big one, we removed the configuration of payment method instances from the rules module, where we previously had that all kind of tucked away in a kind of an unmanageable blob of data inside of rules configuration. We now actually have config entities for your different payment method instances. So you can export those, manage them. Yeah, manage your API keys more securely. Overmire uses authorize.net for the VIP and we exported the config entity for the payment gateway, but removed the tokens and then we committed like in the testing and like settings.local that overrides it for our test credentials. But that way in production, it's not in the database. It's not in version control. It's in the environment variable where we can then set those production API keys and it's not accessible. So if somebody gets a database dump or gets the code like they're not going to have that and be able to find it. Yeah, and then I'd be remiss if I didn't at least mention you can also use locker.io to manage those API keys for you securely offsite completely so that your site only ever talks to locker and is given an API key back in real time and sort of like removing the chance that your API keys may be just accidentally distributed in a database dump or taken off by a developer and then you know, charges run up. Yeah, because if it's on the server, they can still get it. Yeah, yeah, yeah. So payments are supported. We also have promotions supported in CoreNow. So there was the commerce discount and commerce coupon module in commerce 1.x that the promotion system basically combines and improves upon. And so the idea here is that a promotion is anything that alters the price, whether that's a discount, like a percentage off or a dollar amount off of an order or a line item, or it might be sort of an offer, a special offer like buy one, get one, which is the most complicated thing in the world of program. I've had some very fun, long complicated conversations about how to support bogos appropriately. I'm like having flashbacks. I gotta not get stuck in there yet. But this depends on the new adjustments API that allows for both line item and order level adjustments, which we didn't support in commerce 1.x. If you wanted an order level adjustment, you had to write a module that created a new line item, a line item type, whether it's a fee or a discount and add itself to your order. And that was kind of janky in commerce discount. I'm not sure that it still really works completely. But you know, when you're having to worry about managing these extra line items that have to be deleted and recreated on a really frequent basis during the order refresh process, it's just much more costly. It's extremely important. Yeah, costly. And so now it was just writing adjustments to the order price object itself, much faster to create and recreate those values. And so this part is still gonna be an active development and you'll see new features added in subsequent beta releases. But coupon support and both coupon creation support was added to the module. Thanks again to the Obermeier project. They drove home the whole, the reason it's in core and even developed and will be available at least in just like the API bits is because of the Obermeier project, 100%. In fact, this morning just finished up a little bit of work on it. The UI is a little buggy like any UI would be, but at an API level, you can programmatically create promotions, set the conditions for it, what it's gonna give you and apply it to an order via its refresh process. So that's really cool to have that in core. And by being in core, we control it more, which means we can make it do more awesome. Yeah, be better integrated. Not have to abuse the shopping cart refresh process and all that. So we just wanna talk briefly about this project because this was the first full build that we've been able to participate in just as partners with BlueSpark who led the project. That project went really well. Again, thanks to the sort of general domain expertise that BlueSpark brought to the table in both content marketing and e-commerce. We were there as architectural consultants and really to see in what ways might this project benefit the development of commerce 2.x itself. So that's what we're looking for in literally every project that we touch. How can this project result in core improvements that everybody gets to take advantage of? And we have other users here in the audience who have directly funded contributions both to Drupal 7, commerce one and Drupal 8, commerce two. And we really like those projects. It's fun. We wanna be able to take these opportunities to improve the project for everyone. Yeah. And a lot of people are always worried about like, well, early adopters, like the risk. I mean, there is a risk, but also they gotta say and they validated our early architecture which means we could develop faster because we had ideas about how do you validate ideas without putting them in practice. They allowed us to validate those ideas but also give them back like the robust added cart form and how it's completely decoupled and you have product attributes. You can make them be an image of color. It wouldn't happen if we didn't have Obermeyer or early adopters pushing that and wanting to build a great flexible e-commerce platform. And, you know, it could be risky but this particular site was scheduled to launch on August 20th, sorry, September 20th. It launched on time. It launched on that day. So, you know, despite the fact that this was still a really in development project at the time, you know, they were still able to launch on time which again is kudos to the project management team and the development team at this part. D8 was decided when it was like right when 8.0.0 was released and 2.x we maybe had like stores and not even like orders flushed out and they were all for it, so. Yeah, and you know, I wish I could bounce back and forth. I think it might be a keynote issue. You can't bounce back and forth really easily to the browser, but you know, what makes the Obermeyer site great and you can look it up on your phone. It looks great on mobile is, you know, one fantastic design in UX direction from Blue Park's team. As I said, that's a real, you know, great partnership for us because we just don't have that practice in-house. But it's also this complex migration of three sites into one. So they had D6, UberCard site, a Silius-based application for their loyalty program, a SAS B2B application that they were able to combine into one single new Drupal 8 site. And you know, that work, one just really simplified their lives and actually made their technology manageable. We speak to a lot of enterprises that have dozens of technologies powering all their Myriad e-commerce properties. And all of them want to reduce the craft and standardize on a single platform. It just makes sense from a budget perspective, from a team training perspective, from a flexibility perspective, because you can then focus on actually improving your core software instead of improving how your different pieces of software talk to one another. So it's time saved one place, spent to actually improve the shopping experience and conversion rate. Additionally, this work funded a lot of the migrate work, which is where the commerce migrate module came from. It started the base before that, but this really pushed it forward because we import from an ERP. There's a yearly dump of the catalog, import it, and that, you know, most solutions have some backing that they read from. And it's like now, even the demo that I'm working on is based off some of this original work that says I have this flat file of all the different things we sell. How do I convert this into commerce's architecture of product and then variance? And we have that. And even commerce kickstart two uses it now to make the demo story, but it's still had issues, but we don't even have the beta, and we'll have it now. But before the beta even hit, we had a stable way to import data and build your site and be disruptive at the same time. You could handle changes and start in early development because of it, which is huge. And our migration sources that are supported right now are in development by community members that are Drupal 7 commerce. One, Uber carton D6 and D7, and Magenta 1 and 2. Yeah, and hopefully we'll commerce. I think we'll commerce. We'll commerce, okay. I didn't know if anybody's on that one yet or not. And so the idea is we do wanna make it easy to get into Drupal commerce and this product contributed to that. But also what makes it great is just the fact that this is a great example of where I feel Drupal commerce strongly fits, and that's for these companies that have complex requirements around both B2B and B2C sales. So you have to deal with channel conflict. How do I sell direct to consumers without cannibalizing the sales that my dealers are dependent on and that keeps them happy? How do I ensure that sales get routed through my dealer? So I have a company that we're consulting with based in my hometown that has a dealer network of 600 different shops. And yet they want to sell direct to consumer. And so their arrangement is just to simply find the nearest dealer to the end purchaser and distribute it through that store to the end customer if there is one nearby. If not, they just do it direct and take the full margin. So we're able to support multiple types of complex pricing, cart management, checkout workflows all within one application. And no other e-commerce application that I've seen can do this. If you're on Shopify and you wanna sell both B2B and B2C, you create two Shopify sites. If you're on, well, that's the only recent example I have. The other one would be like if you're on Drupal commerce 1.x, okay, but you don't poo poo my old code too bad. But it's just this interesting niche that I think is a good target for anybody that's looking to develop a Drupal commerce practice that might avoid the usual why don't you just use Magento? Why don't you just use Shopify? It's trying to find these complex use cases that merge very complicated pricing rules and product data models with international distribution. No other solution offers all of that out of the box like Drupal does, which is again, Kudos to Drupal itself not to anything special that we've done. And if you'd like to learn more about the Overmire project you can go check out the case study that BlueSpark has up on their site. URL in the footer. It's a really great case study. Full a lot of screenshots. Yeah, okay, better than anything that I would have done. And also if you want to see what it looks like to try it out as a VIP customer, you can email BlueSpark at Overmire at bluespark.com and get a code to go and purchase your next ski jacket. Yeah, because the VIP phase launches this week. That's right. And so with that, I think we'll just sort of close it off with if you want to get involved in Commerce2.x, we'll be meeting at the lunch tables downstairs after this. All the birds of a feather rooms are full. So we, yeah, migrating down to the lunch tables to just continue the conversation around really, for this one probably like scalability and performance. And then there's also another scheduled boss at 345 to 445 in one of the official boss rooms. You can also find us on IRC in the pound Drupal-commerce channel. There's also a Slack channel, I think called Commerce Folk that you can get into as well. And we will happily spend the next five minutes taking questions if there are any. And if you ask a really good one, we'll hook you up with a band. We're doing just a drink set, the Trinity Inn at 645 if you'd like to join us. The address is on this band and you can ask a question or not. We still might give you one, just talk to us afterwards. Any questions? Yes, you can take the microphone. We really, you actually could come up on stage. I talked to Boyan and he said, so order revisions have been killed in Commerce 2.x. How do you do audit trails or auditing of orders? So the plan is that revisions just didn't work. So why make orders revisionable? Because it's just gonna blow up your database. The next step is to do order bar. By not work, we mean that if you had a line item reference field and it referenced a line item from an order, that value of the field is what's saved with the order revision, but not the actual full line items. And so if you looked at a historical order and you changed your line item IDs, that reference will actually have incomplete or broken data and so it just always was a mismatch. And people just use revisions for an order log. So why enable revisions and just provide a way to do an order log? I'm hoping that in the next few weeks we spend some more time on that. It's not getting a hit beta, but it is something we wanna do where it actually says this change was made, this change was made, this change was made and implement some versioning too. It's very similar to what CommerceKickstart 2.x had in the commerce message module. So instead of trying to create a full revision history of orders, you can instead have messages that identify each major change to the order. That is the main thing. So user, what was the thing that was changed, et cetera. But then also third party systems are better suited to storing and inspecting that information after the fact. Yeah, if you wouldn't mind using the microphones, they can get it on the recording. That'd be great. There's one right here at the front. Oh, you didn't shoot a rubber band, Adam. What are you doing about mobile experience? Do you completely leave it to the developer or are you doing something specific in commerce? Yeah, there's nothing specific to it in Drupal Commerce beyond just taking advantage of Drupal 8's general mobile performance. It's something we can look at like after the fact, I suppose, or will probably be project driven. You want a bracelet? You can just throw it. Anybody else, any other questions? They don't have to be. Oh, yeah, yeah. You can just come up to the mic if you have one. Yeah, I got a question about an international shop. If you have a model or some system for the currency exchange and if it's automatic updating or I need to do it manually. Yeah, it would be similar to commerce 1.x in that we have currency conversion rates baked into the currency data model but it wouldn't actually fetch the latest rate. So there was always the commerce currency module that handled tying into an actual currency exchange and calculating that. So it would still be a concern for now. Although you could support multiple price fields if you wanted to just have direct pricing for each currency. Yeah? We've got a massive Drupal 6 website with Uber Kart. I just wanted to know if you're gonna do anything to help us migrate to Drupal 8 in commerce because we are gonna do it. So, oh shoot. So the commerce migrate, one nice thing about it is it's harnessing D8's new testing infrastructure and we have fixtures. So I have an Uber Kart 6 data set that's in there and every test is run against a cleaned, a sanitized live Uber Kart 6 site. So our tests are migrating it and there's actually an environment I made where I can then go into UI and do so. So unless- It's specifically what's being migrated. Products, attributes. Products, orders, attributes, users, user information, billing profiles, shipping profiles, anything that's in there. So if you want to make sure that we can migrate, it would be to check out that module and see if maybe, you know, what if the test fixture isn't robust enough? What if there's some edge cases? What's missing? Maybe to help contribute or like, talk to us later today or tonight, like I would be willing to donate some of the data set to help improve the test cases. Payment tokens would be really cool. Yeah. Which it does remove the credit card. The migration removes the credit card snippet if it is in debug mode. But that would be the best way is just let's have a chat and then see how we can make it a better module to ensure that we have stronger migrations. Thank you very much as well for everything you've done. You bet. Thank you. Hello. All right, so you got into it. That's the spirit. Hi. Hi. One of the things we struggle most with on Drupal 7 is doing telephone orders, like using the back end. So what's the sort of admin and order workflow like on the back end for Drupal 8? Yeah, so the primary change that would, help call center order entry would just be a bit more of a wizard to find the user ahead of time and then go into the order edit form from there. We're sort of adopting the node forms to column layout for managing your metadata versus the content of the order. So it's not like, it's not gonna be a full order management system, but it will be a better iteration over 1.x. And then also like I'm actually actively seeking out order management system partner. So like potentially considering just, sorry, partnering with a vendor and sort of making them like the recommended OMS for full like call center order entry support and multi-channel order entry support. Right, so the biggest change is I equate the 1.x is it's just a paid call. We'll have time for the one last question then you can follow up after that. Thanks. Hiya. So do you know recent integration such as Drupal to hybris for e-commerce? Do you see that as a threat or how would you promote just the standard commerce within Drupal? Yeah, I think that oftentimes the decision to use any particular e-commerce application is it's political as much as it is technical. We had an example where one CTO was really hot on adopting Drupal 8 in commerce. The new one came in who just happened to have a background with another vendor and said, we're gonna go this direction. And there's nothing you can really do about that. But what we do is we will talent the benefits of using Drupal commerce as a front end to a back end application. If you want to use hybris as your order management system and product information management system but perhaps need different satellite sites that are all very different or unique and want to tailor the front end UX in Drupal itself well then let's figure out how to wed Drupal commerce as a front end to the e-commerce application on the back end. If we're trying to sell and compete directly against them of course there are many different angles that we would take to talk about pricing, licensing, customizability, flexibility, the full advantages of the Drupal platform itself. But at the end of the day if somebody really wants to spend a half million dollars on a license we can't stop them. Do you think it matches the technical capabilities? Technical capabilities? I think any one of those applications is gonna be more robust than Drupal commerce and they have million dollar budgets and giant teams and we're really a core team of four with a big community but we're all otherwise occupied. So technically speaking we won't be able to compete as a standalone e-commerce application but that's where we do look at the strengths of wedding your Drupal commerce front end to an order management system and fulfillment management system on the back end and depending on these other strengths in it and oftentimes works out to be a better deal for the merchant because they have 100 web properties but they don't need 100 order editing back ends like they might get with unique demand ware instances per site. So we're looking for other strategies where we can be involved without necessarily convincing somebody to make a decision they're uncomfortable with. But that's probably a longer topic of your conversation but it's good. Well thank you very much for your time and attention. We will vacate the premises and see you all in a few.