 All right. Hi again, everybody. Just to recap, we're here to see how to use Drupal Commerce to build some rich e-commerce experiences. I'm Matt Glomman. If you want to follow me on Twitter, it's at MMD Matt. And my GitHub and Drupal handle is mglamman. We already went through this this morning. I wrote a book. I work at Commerce Guys. I'm a co-maintenor of Drupal Commerce, specifically in the 2.x realm. And this session is going to be on using Drupal Commerce to on Drupal 8. So Drupal Commerce is a native e-commerce framework for Drupal. And we like to say that it powers truly flexible e-commerce. Because just like Drupal, you can make it do anything with Drupal Commerce. You can sell events. You can get donations. You can sell webinars, seminars. You can build a cod. You can build the CREAM conference distribution. And people are using it for CRMs and all that such. Or selling shirts, too. You can do that. So one of the things is why Drupal Commerce. We have WooCommerce. There's Magento. There's ZenCart. There's OpenCart. So many. Because Drupal provides the best framework. So it's a great CMS. It's already targeted for the enterprise. And it gives us so much out of the box. If you think about Magento, they had to reinvent their own rendering layer, their own authentication system, all these other subsystems that just you need, well, Drupal does it. So we can focus on building a great product. And also, the new push is content and commerce. You need to have content on your site to be able to be discovered and help build your brand. That kind of stinks when you have shop.mystore.com and not just mystore.com that contains all your content. Your products and a tightly integrated system where you have a blog post and you're pushing your products inside of that blog post. Drupal, that's easy to do that. And Drupal Commerce lets you scale. And that's going to be covered in a bit of these slides. So it's a great pairing of the existing third party services. Just about every site that I work on has a back end ERP. There's some other thing that manages their products or orders. So Drupal Commerce is just a front end to it. We have a client who's on Drupal 7 still, and they're using it to scale internationally. They have a store in Sweden. They just launched one in Norway. And they plan on launching the store in every single country. They'll do that because they spin up a Drupal Commerce site. They talk to their back end that is like the master channel. Now they have internationalized sales and I have local marketing. So building a rich experience, what does Drupal Commerce to provide to let you do this? So we have stores. So one of the issues in Drupal Commerce is you didn't really have this concept in the store. So now in Drupal Commerce 2, we have stores. That could be your French store, your US store. There's an interesting use case we used in the next few slides. So you have per store settings. Like here's the address for here. I can only accept the UK, Canada, and US orders from my US store. You can control that in the billion settings. And we're working on it right now that each store can have its own payment gateways, its own shipping options. So when you have a French visitor, they get your French store and they can only work within those confines. So your single Drupal Commerce store can run everything. And again, orders belong to only a single store. Because you're not going to buy from two different places. So here's one example. This isn't launched yet. This is for a contact at once. This is a chat provider and the stakes. And this is a Drupal Commerce self-service page. People can buy a subscription and check out with it. And here's their parent company's landing page for live engage. So live person is a client of ours. I don't know if you've noticed, but the logo at the top. You can see that the logo changed and the site changed. And actually in the footer, the footer's changed. We reuse the store data model to control how the site looks. So we create these landing pages that are actually products and we say it's for live engage. It's for contact at once. And we wrote blocks that read that context and alter how the site looks. So if you do have an international store, you could couple it with the domain module maybe to help say, this path is this store. Change how my site looks. Change the branding of it. Then another one for the Sport Overmire Project, which was the first Drupal Commerce to site to launch. It launched right before doubling. So we actually import their customer master database and provide a store locator. We map the inventory to the stores, let you go on here, dump it in the leaflet, which again, Drupal, we didn't have to write a leaflet module. We didn't have to write the geocoder. We could pull in the geocoder module, take other addresses, get the latitude, longitude, dump it in the views, and the leaflet. And we got that. One reason that I really do think Drupal Commerce has an advantage over the other competitors, you could say, because we leveraged around the shoulders of giants, right, that's the term. Product attributes. So when you go in, you can create a product attribute. And what that means is you're like, OK, these are colors. And then you go black, white, red, et cetera, et cetera, et cetera, your sizes. And you control them all right there. And that powers your ad to cart, right? When you view a product, you're like, I need this size. I need this color. And one of the biggest advantages in Drupal Commerce too is you can see it says, how do you want it to be rendered? It has radio buttons, a select list, or a rendered entity. So that means for the Drupalism in there, you can add additional fields here. So you could attach an image and say that this color swatch represents red. That was the case for Obermeyer, which is why this was built. The red wasn't really, it had some crazy name. It had some names specific to them, so we rendered a swatch. So this gives you full control now of your ad to cart form, and also provides a really robust way for managing your products. And we have a field formatter that's called attribute overview that takes all the variations in your product that say, what are all the things I have and shows an overview of them? So in this, obviously, this is a little custom, but all we did is we extended the field formatter, did some little JS adjustments, and now there. So that took probably about an hour only to do. And half of it came out of the box with Drupal Commerce. Now, people can go to the store, they can click on the little swatches, and it actually appends a query parameter to the product that lets you go and view that specific variation that comes out of the box with Drupal Commerce being able to go and link to a specific color or size. So we're giving you something that most people go do at Giant Retailer, and that's what they expect. We're now empowering you to have that out of the box as easily as possible. And we let you customize how you add products to the cart. This is probably the most important part of an e-commerce site, because it gives you conversions. The next would be the actual checkout process. So it's completely plug-able. It reuses components in the field API and the entity display system. You can customize this in a UI as much as you want, but really, if you want to really extend it, you just write some field plugins and you can also jam it out. So here's an out-of-the-box example. Set it down to the drop-downs. This is really ugly, by the way. No one wants to buy this. So let's have a color field. OK, we install the color field module, add that field, and type in a swatch. Tell the color to do a rendered entity. Still keep size of drop-down as well. That's a lot better, and that took no code. I wanted you to install a module, but. And then you can do something like this. This is just a field widget. There's no super-secret alter and hacking everything. Just create a new field widget that lets people choose the different attributes. But to avoid channel conflict, Overmire doesn't sell direct to customers. They take you off-site to an e-commerce, their partner stores, and it creates a cart, which we didn't build that. That was a really existing book. Drupal Commerce made it super easy to implement this. There was one little component on the page. If this was still in Drupal 7 land, that would mean you have to copy, paste an entire module and then alter it. And then if you are a VIP, they have a VIP tier. So it's like a friends and family discount or specifics. Based on your roles, we're able to switch to a different field widget and say, no, let them add to the cart. So then again, this is leveraging all the APIs in Drupal that makes it really easy to build this rich experience. We didn't have to do that much custom code for all of this. Then again, there's their B2B. Now this was a lot of custom code. It turns all the variations into an ordering grid for their B2B. This took two days, but it was still something that was achievable within Drupal Commerce. And we're seeing that this is a huge need in B2B sales, is this kind of bulk ordering. So I'm hoping to be able to take some of this and either put it up as a sandbox or find some way that we can make this easier for you to do within Drupal Commerce. Probably not in the UI, but just some code that helps you get to that next step. Because we want you to adopt this. We want you to be able to use this to your customers and say, you need to build a B2B. So we'll stop paying $1,200 a month for whatever service. Put it in your Drupal site. Like you're already selling to customers. We'll let your B2B have an experience there too. It saves them a lot of money. Order types. So you can have different kinds of orders. Because you might have a physical order. You might have a digital order. You might have a subscription order. If it's a subscription, you need certain kind of data to be collected besides just a billing address. Or if it's a shipping, if it's shipable, you need a shipping address. So it allows you to add different fields and there's some different configuration items. An example here is the contact at once checkout. So they have certain requirements. This is based on auto dealers. You need like a dealer type, the website, dealer group, but then if we went to the live engage one, it's much simpler. So we have two order types and it allows us to control our checkout and say, we need to collect this data to be provisioned to make a subscription. But for this one, we only need this little bit. So it does give you much more flexibility in that case. So you couldn't sell a digital in a physical store side by side, but if somebody only had digital products, take them through that experience. So they have less to fill out without any kind of monkey around to hide things and do all these crazy checks that you used to have to do. My favorite part is the custom checkouts via checkout flows. As I said, one of your biggest conversion things is getting somebody to actually put something in their cart. That's your first hurdle. The second hurdle is like, please, actually give me the money for that product. Do not leave. Please, please, please, please, please. So the checkout flow is controlled by the order type. You say my digital one is going to use this digital checkout flow. You can customize it in UI. So we have these things called panes that go into the different steps. If you use Drupal Commerce 1, we call the steps pages. We change the name because we want you to be able to implement easily the Apple checkout flow where it's more like collapsed field set. So as you move through the steps, the phone just rebuilds and it looks like an accordion. So that's something that can now be done. So you don't need to use this either. You could write in pure code. LivePerson project has nine checkout flows and the support Overmire one has three. But I don't use this. I wrote a one plug-in. I wrote my own form API code and just done. And we also give you some out-of-the-box UX patterns too. We are giving some, since Drupal 8 makes it easy to give an opinion that can be scaled backwards. We are trying to give you some of the best UX patterns that we've found out-of-the-box. We check out was about a month or two months with AcroMedia sitting and going and making poor people try because we never checked out our carts because we needed to see how their checkout worked, what their experiences were. So one thing that that saw is when you go to check in and you're a guest and you have this turned on, you either have to log in. You can continue as guest or you can force that to be a registered farm. That was like four different modules before that are now one in Drupal Commerce 2, so an out-of-the-box experience is allowing guest checkout or logging in or registration. The next one, and I feel like this kind of broke the mold. We weren't sure if we should do it, but we did because we want you to have something good out of the box. We put a sidebar up. If you've noticed, that's a new trend. Every single e-commerce site, there's a sidebar that has the cart summary and that's where all of your readable information is and everything that you have to input is on the left-hand side. Now again, you just override the twig file. You override the template and say, I don't want this. So you can peel it back, but we wanted to give you the best out-of-the-box experience. And you'll notice one thing, so the payment, we actually tied the credit card entry and billing information into the same area before and in a lot of other e-commerce solutions. You have the billing up here, then you enter in your money information here, but those need to be tied, especially if you have reusable payments. If you have a tokenized payment gateway and you're saving that payment information as token, you need to reuse that billing address. So why are you letting it be this distant other information? We didn't have somebody who came to us and said they didn't like this because the site design was for the old Drupal commerce. It's like, well, maybe we can adjust it because this is like proper UX and we know that many people break this, but this is, we spent a lot of time looking this up and just about every single e-commerce site that's at the enterprise level has it set up somewhat like this. Not as plain, but. And so here's an example of the Overmire Checkout for the VIP. When they sign up, they already give us their billing and shipping information so it's a simple payment form and this is all just form API single-page checkout. So we do allow you to build a single-page checkout right now, but if you choose to do so, make sure that you're not required by law to have a review page. We have a lot of people that like, I want a single-page checkout, but I believe in Germany and a few others, if you don't have a review page where they can verify everything, you're breaking the law. So as I've brought up before, scaling for internationalization, we have a client that is using this to spin up new stores in every country and we want to push Drupal commerce, not as just like a native solution that you are managing your orders in, but also as something that you can just use as a front end to scale, to build the business and your reach. One thing that comes out of the box via a bunch of libraries that we wrote, Boyan spent the first initial development of Drupal commerce too, was about a year of writing these libraries that solved the hard parts of e-commerce. That weren't just Drupal specific, but there were just problems and we wrote general PHP libraries for them. This then piggybacks onto the multilingual support in Drupal 8. So if you look, there it's viewing a US price amount in Brazilian Portuguese, right? US, then the currency symbol, 89, usually a lot of them. Then we visit the site in Portuguese. Portugal has changed its format and then viewed in German and it changes format. That's just happened. Like when I changed the language, it caused that to just re-render and change how it's formatted based on the locale, which is really important because right, if you had a site that was just Portuguese, it's not formatted the same in the two countries. This is even true like German and Austria and then German is different as well, if I remember right. So we allow you to import every single kind of currency that there is. We get it from the CLDR data from the Unicode project, say some JSON, we import and then create config entities. You can customize it too. So let's say you wanted to add Bitcoin because no, Bitcoin's not registered in there. So if you did have some kind of subscription service and you wanted to collect Bitcoin, you could add your own custom currency. And each store defines what currency it supports, which going to multiple currency products, it's partially supported out of the box. We had like a weird unexpected bug that we just got merged this week. It takes a little bit of code to get to work for now. So it's being documented at this moment. I think we have a pull request on our docs that can get merged in. So this would allow you to add like multiple fields and say, here's my US price, here's my Canadian price, here's my UK price. And based on where they're locale, we would swap off the resolved unit price. And it's being actively implemented by contributors too. So there's about three to four people that have come up with this and they're actively using it and coming to that canonical solution. I want to touch on current integrations because a lot of people are like, well, you're still in beta. What do we have that's available? We've been really busy at work so we haven't been great at communicating at this. So that's really bad on us as maintenance. So I want to show some things off. We have some specific integrations available. The biggest one is obviously payment gateways, selling online and collecting money. It's only a little big, important piece. So we have Braintree. Braintree actually sponsored the development of our payment API. That was our first integration, which their new way of doing it is insane. Each individual input field is an iframe that gets rendered via a JavaScript library and we use the Drupal-forming API. So it's drop in, you have your PCI compliance, it lowers your need of PCI compliance because each iframe is an input and somehow it recombobulates it all. Authorize that and that was the second that was sponsored by Obermeyer. We just wrapped up, actually somebody wrote PayPal Express Checkout and another developer actually wrote PayPal or the Payflow Payment Gateway. You rewrote the payment API to make it much simpler to implement and these things are just rolling in right now. Mr. Scott Hooker wrote Stripe. Would that take eight hours? Six. Six, so that's phenomenal. Like we're taking a while to get the RC up because we want to do it right, but just proving, seeing that somebody converted a payment gateway in six hours, that's fully functional. It's like, that's great. You shouldn't have to make hard decisions when integrating something with Drupal Commerce. Like we should tell you how to do it easily. You plug the two things together and you'll be on your married way. So we also have WeChat Pay, a contributor in China just finished that. Genico Vantage and Worldline were done by Tavi at actualis, the Commerce Guys French affiliate previously of Commerce Guys. And then other integrations. So LivePerson pushed forward the port of AvaTax which is a tax calculation service. We actually don't have tax in Drupal Commerce right now. We yanked it out to make it better. The data model didn't fit. We came up with a way to optimize it. So at least right now for people in the US, and I'm pretty sure you can use them over here in here. I'm not totally sure. Which in the States, I told people to use this anyways because our taxes are insanely difficult. Because they vary on no sensical matter. And then FedEx. So we also got a little derailed because this company called Adapt, funded Boyan's time, his priority really, to finish shipping. In January, we ported shipping to a beta status. And that had been a project in discussion since mid-camp last year. So last March we first started talking about how did you ship in? Because it has shipments, it has boxes, it has packaging logic. It has a way to get a tracking number if you want. So it's a really robust solution that got finished up in January. And somebody wrote FedEx for it. So we have this really great problem right now of too many contributors and too much code coming in to be able to keep up and communicate this to the users of Drupal Commerce or prospective users. So if you wanna learn some more, I went, we used to do our slides in a much different fashion that went in some of the background and developer stuff. But if you want some of the information on the design decisions, go to dupalcommerce.org, slash blog, slash tag, slash commerce hyphen 2x. And I'll put these slides on the session page so that way you can easily get to it. But these are all, they're in there, there are some tutorials, but there's also, we did a story series that explains all the decisions behind what we made, such as Boyan's adventures with currency. And I'm pretty sure it got him to be an approved contributor to Google's dataset. So he's now officially like the Google contributor because of this. Just cool, right? Get off the island that's been the mantra. He literally hopped to a whole new platform. Our docs, our revamp, we're not putting them on dupal.org. They're actually written in restructured text and hosted on platform.sh. We did this because go into dupal.org, edit in it, it's not marked down, it's kind of a pain. So with this, we actually, people can go to GitHub's UI and edit in place. We're hoping people to show up like there's a typo. I wanna add this page, click a button, submit a pull request, and actually build on platform.sh so you can see a live demo of what your changes will be and go forward. And this is actually mimicking what symphony does for their documents. And of course, IRC, not everybody's a fan of it, but we're always there and we're always hanging out and we'll always listen to you. And dupal-commerce. I know there's like a drupal slack, I'm not part of it because I need one lap, I don't need any more slack teams in my chat app. But if you do ever have questions, you can hop in IRC or hound me on Twitter, that's usually how you get my attention really easily, it's like, hey, pay attention to me. If you wanna try a demo, now this is not something that's up and running, I hope that we do get a live demo working, or maybe work with the simply test.me folks to get the composer support working, because right now we do require some composer, you do have to build this, and simply test.me doesn't work with that quite yet, I hear that it's coming down the pipe. So the first one is a demo module I'm making, you install the demo, and it imports like three T-shirts, an ebook product type, and it installs the shipping module too. So if you buy a T-shirt, it takes you through a shipable checkout flow, which actually for your shipping information, you pick a shipping method, or if you buy an ebook, such and such, and some other little goodies. And then if you want to get started on a project or actually see what a full build looks like, the commerce project template is my opinionated Drupal 8 build. When I say opinionated, I was like, it's just, this is how I set up my projects. It has a config directory, so you can use Drupal 8's configuration management to export and commit to your repository. It has my build setup, it has my Docker files in it, so if you want a quick up and running, or just don't, even if you don't know really how to structure a Drupal 8 site quite yet, take a look at that, that's one reason I released it, is with the Sport Overmire project, we've probably spent maybe a month, figuring out how are we gonna structure this new site, as we were used to Drupal 7, and the make file goes here, and other stuff goes there. So that's the overview of all that. I wanna open up for questions, and if we don't have enough time for all the questions, ping me on Twitter, hunt me down in the hallways, and ask me a few questions, because one thing I'm really enjoying about going to the conference is hearing what people have to say good things about, but also complaints about. Dublin was a great experience for that, heard a lot of use cases that we wouldn't have considered as time. No, okay. She brought up one, they take phone orders, and it's a pain in Drupal Commerce 1, so we're gonna try to figure out how to make the admin experience better in Drupal Commerce 2. Now, most people would have an enterprise solution, but I got to hear a complaint, and it's like, actually I had that too, but I forgot about it. So we do wanna hear that, because we wanna build a great product that lets you easily build an e-commerce store on Drupal. Questions? Byron. Yeah, so Commerce Tax was in during the Alpha stage, and it kind of was put in the repo and not touched. So before the beta, we removed it, because once code is in beta, it was nothing would get removed, no breaking changes once it was beta. So we wanted to rethink it. We found some performance issues with the modeling. Basically, we just got to learn Drupal 8 better and make Drupal Core better too. A lot of things have gone into Drupal Core that we've been working on in Commerce, and it was just not very performing what we had set up. What do we have? Okay, good. Alex. What's the best thing about working with Ryan? And when will commerce be ready? The best part about working with Ryan is Ryan's snarkiness. And when will commerce be ready? Our release candidate blocker is taxes, and I believe documentation. We have a list somewhere, but we also want to come out the door with documentation, which actually there's a contributor from Shaijan that's been opening pull requests every day. So that's coming out the door too. So basically, I think I just need to sit down and be like, okay, what do we gotta do for taxes? What's going on there? So I would like by Baltimore to have an RSC, or at least sooner than that. But we've had so many bug fixes come through that I don't know if we'll have a long RSC session. It might be like RC12, and hopefully just released, because we're getting so many people using it already. And yeah, bam. So the question was donations, right? The gist of it is, how well do we do donations? A firm just actually sponsored a day of voyage time to document how to do that. This is also something that's really new to Drupal Commerce too. We have people actually sponsoring us to develop. They're not just clients pushing it, but there's actually firms coming up and like, we want to sponsor your priority. We want to influence your priorities. This is what benefits us. And it's like, well, sure, yeah, if you're gonna buy our time and it builds the product, it's been a huge change. So he documented it. And if you go to BoAns GitHub, so BoJ, A-N-Z, it's like donation demo or sandbox, something of that sort. I wouldn't use it yet, because he uncovered some things that make it hard to do donations in commerce. Not too hard, but not easy. So he's actually gonna backport those in, so that way it's easier to do a donation out of the box. But we had somebody that just paid us to figure it out, and it's been figured out and proven. So that's nexus of that. He's telling us custom code and you might sandbox it in the future. Could you give us a vague idea about how much about custom code was using commerce in the office, and how much was using Drupal Core, not removing so much to add to it? So for that right there, it was just inside the field widget, a lot of logic and loops, really. It was okay, get all the variations. I had to build a matrix of how they identify products to make each row, then the sizing, because there's petite or large or tall or regular, and then all the sizings across. So that was why it took so long. It was the logic of, build this out. Oh, what catalog are reviewing, because they have seven catalogs at the same time that hide and show products. Well that says, is this yellow at 10, or is this yellow at 15? So that's why it took a bit. It's just because of looping over so many things. And I would like to see if we could get a bulk order card that just does a grid. None of the other fancinesses, but does a grid. I know somebody is working on bulk creation of variations in the admin, but I don't know if they're working on a bulk and buy. But it is something that we would like to have available if not as a contrib, just a basic here's how you do it. Which, on the docs, we do have a code recipe section. So it might even end up there. Instead of polluting the contrib space, because right now there's 700 contrib modules for Drupal Commerce. So we're trying to say, well here's a code recipe. We don't need a contrib for this one class. Just copy, paste, adapt to your needs. Saw a hand over here. No rules. The question was, Drupal Commerce, when relied heavily on rules, I can say with a smile on my face that Drupal 8, or Drupal Commerce 2 does not use rules. Important reasons were made behind that. Rules wasn't ready. I had to build, I built the promotion system. So discounts and coupons are now in Drupal Commerce. They used to be in something else, you had to download. So I don't know the full story behind it, but I believe it's from all the panels work that in Drupal Core there's a context system, there's more actions, there's conditions in there as well. So kind of like what Chaos Tool is provided in Drupal 7, it's in Drupal Core. So we built a custom field that lets you say your conditions. So we used the core condition plugin to build our promotions and do all the checks. So we didn't need rules, and I'm hoping that we can leverage the core plugins for anything that needed rules before, and then once rules hits a stable, I haven't checked on it in a while. I heard it was a little stagnant. Make sure that rules doesn't break our integration because rules actually extend what core does. So eventually I imagine that rules could be in core, or at least some shape of it. But what that will mean for some of the site builder-ish ways to interact with commerce, we need to see it. We also need to know some of the use cases too, like what were people doing in rules that we took away from them without necessarily knowing, because I never used rules. I disliked rules completely with coming into Drupal. But I know there's people that, they can do everything in rules. I'm just like, I don't know how to do that. So it's one that if you do try it out and you find that you're missing something that you used to be able to do, let us know and we'll figure out how to make it happen, or make the decision like, okay, we do need something like rules after all. We'll go up. Yeah. So there's talks. There's about three people that need commerce. So in Drupal, commerce one, there was the commerce license, commerce recurring, commerce license billing. There's like four. Dunning, recurring. There's a whole bunch of modules that did that. There's talks about porting commerce license very soon. So license says I bought this and it's good for this law, a subscription. Recurring is what would say, well, after the end of it, renew it, charge their tokenized payment method. It's in the talks right now. We know people need it and we know we're gonna have to port it. I think I heard word that don't take me on it, but I think I heard word that maybe by Drupalcon Baltimore will have a license. Commerce license is easy to port, especially with the Drupal eight code. It's gonna be really simple. The hard part is recurring and Dunning and all that fun stuff. I started a port of license and would never... Yeah, I'm kind of against that too. I'd rather leverage payment APIs or payment gateways that do their own recurring. So commerce would say, control the subscription and say that the license is good to hear. When it expires, tell the payment gateway, stop charging them. Instead of Drupal commerce re-initiating the payment each time. But it's on the roadmap. We don't have a definitive one, but I do know that there's people jockeying to help fund it's porting. Pricing requirements that are kind of scalable, more complicated than what could be solved by discounts or promotions. So like, you know, you tend to tell them about beyond doing it. So the promotions UI has always just been, the promotions has always just been a UI for discounts. Like you can do everything in code you want to. And oftentimes I would say difficult purchasing solutions need to be in code. Like it should not be run by anything else because that's, it's going to be slow because every condition is like a plugin and it does all these things. So in the technical way that they have it, we have a unit price resolver. And that says, what is the unit price for this purchased item? That's where you could do the bolt check or say, did it five, 10 minutes. That's where you could say, are they a B2B user? Well, if they are, they automatically get this price. That's how we're doing multi-currency is check their locale, swap out the price that they're going to get. We have an order refresh process. So when in order saved or it's been loaded after a long time, we kind of refresh it to make sure that everything's up to date. So at that process you could say, okay, the order refresh is happening. You add a processor and say, loop the order items. All right, it has this product. They bought this much. Add an adjustment to give them a discount. So there's ways to do it. Again, there's a few ways you could do it but two entry points. And that's something that, again, is kind of in the documentation but not fully there yet. I saw a handover. It's built in. So that's one reason it took so long. And it's a grim because there was commerce shipments, commerce. There was like three ways to do it. Now we have packaging and boxes in there. So you define your boxes or like FedEx says you have these three boxes and it will package it and then rate it for you. Out of the box, it doesn't, you have to configure it because we made it really simple at first but you can scale it up that way where it says, okay, try to put these things in this box and then weigh it. We make it easy to add it something that are their weight dimensions. So it can either be just weight or actual dimensions. But that's him, that is there. Okay, so we have time for like one more. No, I have not. But I know that there's two gents here working on a CRM and I don't know if there's gonna be a true commerce integration or not. I think no. First, on the old Myer use case, how about address data, how does this do that? They have a backend ERP that they put in and then when they give like a registration code to a friends and family person they type in their address. That part I didn't need to really worry about. We just had to interface with their API. Is there anyone else or are we good? Ah, sorry. That's the question everybody asked and I'm like, it depends on what you wanna do. A lot of people are like, well, I don't think it should be so rigid. I'm like, then don't make it be. I mean, I just know that if I had a site that sold both, if they had an order that only had one type, I would go to that preferred one. But let's say that it was that case. Well, you would listen to that and say, I'm gonna override the default. It has a digital one in it. Send them in through like, maybe there's a different checkout flow. You have three. One is for mixed product that says, fill in your shipping but also sign this agreement because it's a digital download. The world's your oyster. We have time for one more if there's any. Okay. Is there anything for stock management or integration with stock management? Where's that? It's in the works. Okay. I'm inspired here. We have, so there's yourself, Steve Oliver and Ola, which have been a huge contributor so far. Steve Oliver alone has been really big on pushing 2.x. He helped me with avatax. I went a lot of design, a lot of internal decisions too. So we have a really unique first world open source problem of too many contributors contributing too much code. We have two more to talk about for the stock location and it's gonna be for the actual one. Yeah. All right. That's it.