 Welcome to accelerating Drupal commerce adoption through a new commerce kickstart. I'm Ryan Zerama, the CEO of Centoro, and the creator of UberCart on Drupal 5 and 6, and then Drupal Commerce on Drupal 7, 8, and 9, which sounds more impressive than it is, right? Because really the ones for 5 and 6 are pretty similar, and the ones for 8 and 9 are basically identical, but it's like five whole versions. And I'm presenting the work, you know, not of just myself, but of our team at Centoro. And that includes Jonathan Saxic, who's in Tel Aviv, as our commerce core lead developer, or what we would call our platform lead internally, and then our front-end and site-building leads, Yvonne and Tsumchitsa, who are working out of our office in Belgrade. And we also just wanted to take a moment to remember and reflect on our colleagues who are traveling around Ukraine, making sure they don't get bombed. So they were as instrumental to the success of this project as anybody else, and we thank them every day. So as I prepared this presentation, I thought that it was kind of like a title that I threw on the DrupalCon website without fully thinking it through, because we knew our desire and outcome was to accelerate the growth of Drupal commerce. But I didn't think like, but why? Like, why does that matter? Like, what's the point of accelerating this particular project or Drupal in general? And this was really what consumed a lot of our weekend at the Drupal Association Board retreat, is what would it look like to actually 10x the amount of innovation that takes place at Drupal Core? And similarly, what would it look like if we were able to 10x the amount of development and innovation in Drupal commerce itself? But it's like, is it just for the sake of the technology existing? Because I want to keep doing what I do for work for a few more years. Is that the, it's not satisfying, it's not an end unto itself. But within Centoro, and for me personally, the reason that we want Drupal commerce to grow is because we actually believe that our vision for the future of e-commerce is better than the competing alternatives. We think that our vision matters. We're building a future where merchants go to market on their own terms unconstrained by their commerce platforms. And from my standpoint, more importantly, empowered to do what's right by their customers. So this obviously puts us in distinction against the typical proprietary platform that has a fixed roadmap, close support, maybe no insight or influence whatsoever on the development of the product and merchants are trapped and not able to innovate when they need to. And one of my favorite examples of what you can do when you don't have constraints comes from one of our most successful customers, E.C. Barton and company, or homeoutlet.com. They launched with us on Drupal commerce 2.x site. It was after Vienna. I can't remember what year that was, 2018. So in 2019, we launched their store. We said, what's next? And we weren't really sure what they needed to do next for the platform because they really just needed their stores to start using it and referring to it. And they said, well, we really wanna nail down like by online to pick up in store and near store deliveries. So within 50 miles or so radius, they have their own box trucks and can do LTL delivery to homes. Well, we talked to them and did it, right? There was no, it wasn't a long process. They were able to contribute back features related to store location and so on. And then like one month later, all their stores closed for in-person ordering because the pandemic theoretically was gonna shut down retail traffic. And I was developing contingency plans, like, all right, what do we do when this customer stops being able to pay their bills and which other ones are not gonna be able to continue to work with us? And instead they, I think it was tripled that year, their online revenue. And then now they've tripled it again the next year and they're finding more ways to get more value out of that website. Things that I hadn't even thought about, like using their website even for in-store credit card payments to take advantage of Signified, which is their fraud prevention tool that can do risk analysis and actually insures credit card purchases. So like just the fact that we were able to just strategize together what's next for you that would make you a more resilient business, make you more effective at reaching your customers, they didn't have to wait for that to be added to the platform. Like every Squarespace customer had to since there was no real like store pickup stuff at first. Although eventually my cafe got that sorted out. So that's it, like I think that vision matters. People should be freed to innovate on their own schedule, on their own terms and to meet their customers in their own unique way. And I think that they should treat their customers right. I don't think that they should accept the status quo of the Shopify's and other companies in the world that are data hungry and just shovel all the data they can into their own data lakes so that one day they can compete against all of their best merchants, right? When Shopify becomes a marketplace like Amazon. So that's the future that I think we should help people avoid. So we think this vision matters and that's what we mean when we say that we power commerce without compromise and we invite you all to kind of build that future with us. So where is the Drupal commerce project today? Right now we're sitting at it. I think what's there on the screen around 51,000 sites total between Drupal seven and Drupal eight slash nine. And as with Drupal core itself we still have a majority or well yeah I actually don't know the numbers for Drupal core and maybe half and half but like we still have a significant percentage of our sites still running on Drupal seven. But we are up to about 20,000 sites running on Drupal eight and nine and seeing a pretty consistent four to 5,000 site uptick every year. Which is cool. The project as a whole I guess it powers about 50,000 sites but what's crazy to me is just to think the scale the sheer scale of the project. Like I actually think I'm underestimating when I say that we power $4 billion of commerce a year because I know individual sites that could account for a quarter billion sites that I've worked on. It's incredible. Like the scale that you can achieve with Drupal commerce running on some of the modern passes that one in particular running on Aquia and just churning through. We actually we weren't able to reach the peak of how many customers we could go out that site. We actually ran out of licensed nodes in our performance optimization tool before we reached the end of what we could do on that site. So we have individual customers running on commerce to that sell upwards of 10,000 orders an hour at peak. Which is pretty awesome. And we're able to do things like just use the core framework, its own caching systems and then combine that with some progressive decoupling so you get the forms API and views out of the way of the rendering pipe for cart blocks and cart forms. And then eventually you can fully decouple checkout if you want to. Like those things are all supported by Drupal commerce today and those are the strategies that people are using to reach massive scale of Drupal commerce. And when we think about the feature set at a glance and this is like a very dense glance but I include this slide just to illustrate the fact that like Drupal commerce, it's not just like an add to cart button to a node. That actually was more or less the model of Uber cart where I ported the OS commerce feature set into nodes. So you could just add a skew to a node and then turn that into an add to cart button and then purchase it with a different data model between carts and orders. That made it really tricky to keep things all synced. We fix some things in standardizing our entity relationship model. And that includes things like distinguishing between products and product variations, having first class entities defined for attributes and attribute values instead of just using random field types added to a node type. Full support for your entire order data model which includes orders, order items, customer profiles, stored payment methods, login trees to track what happens to an order payments, to track the completed payments so that we will eventually expand the payment data model as well. That's coming up in commerce three. Full multi currency support, multi store support out of the box. You pair that with the commerce store domain module and suddenly we were able to build a multi domain but single site store for university to have different departments running their own would appear to be custom instances of Drupal commerce but all powered by one application. So IT only had one application they had to maintain, one payment vector they had to monitor and now they're finding new ways to use that application throughout the university now that it's deployed for them. Add to cart buttons, multiple checkout flows, price list, blah, blah, blah. It's all there and all of these features are up in free modules on Drupal.org. Nothing's locked behind a dual license model like you'll see in other platforms like this. It's just free for you to use and to give back to you and we do really appreciate all the contributions. I'm sure we have people in here maintaining modules or contributed on Drupal.org. I know some folks that I've seen and talked to throughout the conference, yeah. So like this is what we've done together. So like I love talking about the number but it's not like Centaro did this or commerce guys before. And I mean we've probably serviced a grand total of maybe 500 merchants on Drupal over the course of our life. So now we're near the 50,000 that's live. That's all of us building this together. Recent releases of Commerce Core continue thanks to Jonathan's efforts and thanks to various customers funding development in Core. Again in partnership with Aquia on projects, in partnership with BlueSpark on other projects. We're seeing money funneled toward improving the core capabilities of commerce. One of our largest customers is a company called IPC that uses Drupal Commerce to sell training credits and PDF downloads and books and things have sponsored a lot of work in the core of commerce and in the various contributor modules. So the features have added things like multi-variation type support at the product level. This is a new feature where you can have one product display page that sells either digital or physical copies of the same product using different product variation types because that's how you have to configure what is a licensed download versus what's the weight of a product. That's a kind of a configuration thing that previously required distinct PDPs. Order management features including admin order comments and we have a great patch in the queue right now for customer order comments and the ability to surface admin comments to customers on the front end. So that should be in 2.31. State transition confirmation dialogs. You're gonna be like, are you sure you're ready to mark this order paid? Are you sure you're ready to go to fulfillment? But then it also gives you the ability in the confirmation form to add additional form elements that might be custom to your workflow. So you can say yes and also capture the money because I'm ready to fulfill this and you just wanna automate capture so the merchant can't screw it up because I've done that before where we had a merchant on Black Friday authorized about 40, $50,000 in fulfillments and not actually capture the funds. Fortunately, authorizations last more than one day. We were able to recover the money on Monday. And caveat, this is so long ago. I mean, ancient history would never make mistakes now. We also have the commerce email module which says you use the user interface to configure emails that get sent in reaction to different order events. That was a new module that I developed for, oh shoot. I guess it was for kickstart. We had a customer use case but I can't remember it off the top of my head. Promotions with coupon validity dates used to be at the promotion level only. Now it's at the coupon level as well and you can combine offers. You can offer free shipping plus 10% off. That's new in 2.28 I believe. And then finally, most recently on the payment front we've added Apple Pay support through our brain tree integration, Venmo support through our PayPal checkout integration. PayPal's been great partners and sponsors of this development and other things throughout the commerce ecosystem. Unfortunately, it couldn't be with us here in Portland but they were with us in Seattle and they just love to see the energy that the Drupal community brings to commerce and obviously what's good for us and good for them it's all kind of the same thing. So then the question is why commerce kickstart? Like if Drupal commerce is already there and it already does all this stuff like why do we need a distribution? We actually thought we didn't for a while. You may recall commerce kickstarts last release was for Drupal 7 and Drupal 7's I guess when was it released? 2011? Yeah and then we released commerce kickstart in 2012 so there hasn't been a new major version of commerce kickstart since then and we just weren't sure what composer meant for site building and development on Drupal 8 and Drupal 9 and so we teased out a few different things. At first we thought well maybe commerce kickstart would become like just a composer.json builder so we had a web interface where you could select the different projects you wanted to include and we would spit out a composer.json file and that was neat but it was a novelty thing and ultimately like it wasn't the kind of thing that we could see ourselves maintaining long term and if every single merchant has like a unique composer.json and their own unique way of managing config and all this stuff like then suddenly we lose the ability to take care of some upgrades for them. So for example if you use our default config in the distribution and you haven't changed it then I can determine from just an update hook it's safe for me to re-import a configuration file so you get a new feature without breaking what you already have because I can guarantee that everything in the distribution works well together. So the reality is like new features are great in commerce core but features alone won't drive adoption especially if people don't even know how to use them or know they exist and so if for example it still requires a developer to type composer create projects and to evaluate Drupal commerce then we're necessarily limiting the number of people we could ever reach. So distribution can help us create a version of Drupal commerce that's a great demo out of the box and then has a one click install and simply test me which we do right now. You just click a little Drupal commerce demo button and boom you have a site you can log into it you can see everything that Drupal commerce has to offer but without kickstart to kind of bring it all together in a demo store you'd be lost if you weren't already a Drupalist. And so I ask myself like how can we double our user base faster because waiting another five years for 4,000 sites here and there to come on board just doesn't seem smart. It's not satisfying at the very least because again like we think our vision matters we think that merchants should be able to go to market on their own terms and do what's right by their customers which means protecting their data, protecting their PII not annoying them, not selling their data off to third parties. Like if I want more people to have that experience then one option is to as I said increase the evaluation sorry decrease the cost of evaluating Drupal commerce but another thing is to create like a fixed target that says hey this package offers the feature set of Uber cart and I have a way to translate Uber cart product types and I have to beat some options into the Drupal commerce paradigm. What if we could get 15,000 Uber cart users to migrate from Drupal six and seven to commerce to on Drupal nine? Or those 30,000 Drupal seven commerce sites we want them to come over to and you know several of our projects are those Drupal seven migrations I think we have one or two in the works right now that are actually Uber cart migrations. One of them selling tens of millions of dollars at auctions annually, it's pretty incredible stuff which means once a month their site just gets absolutely hammered which again decoupling really helps a lot with that but we want to make it easier for those folks who've been doing business and built big successful businesses on Drupal commerce to come forward and then once they're here to have just a clear path forward toward maintenance that's maybe never gonna be as easy as staying with the latest version of Shopify or big commerce because it's SaaS and it's updated for you but maybe we can make it a lot easier than it has been in the past, that's the goal and obviously Drupal core is doing that itself just by virtue of the way that our release cycles are managed now. As long as we're keeping up with deprecations then the updates are more or less automatic I think one of our largest European users we had migrated from the A to D nine or upgraded from the A to D nine in a day give or take which is pretty sweet. So at the end of the day commerce kickstart did prove the idea that this can drive adoption. I can think of two of the largest Drupal commerce projects in the world that actually launched on commerce kickstart. So it really proved the concept but there were some things wrong with it. We mixed up for example all of our default config was demo content. So if you wanted to take advantage of like our search interfaces or product display pages or taxonomy menus but you kind of were tied yet to just install the full demo store and then go in and start to delete things, undo things. And we took over the menus in what I think was kind of an unhelpful way. So it wasn't perfect but it proved the concept. 13,000 sites reporting in. Obviously that's a mixture of demos versus live sites but I still get leads today from people that are like hey I'm running commerce kickstart I go look at their website and sure enough they even kept like the logo and the favicon and here they are still doing business eight years later. Just pretty awesome that they were able to do that without having to just jump from Drupal to another platform. So when we think about kickstart to prove the concept so we don't want to do it again. We actually just want to do better. We want to make sure that the problems that commerce kickstart created for developers and site builders aren't reproduced in the new version and we want to have a tool that's even better as a sales tool, as an evaluation tool at the same time. So what's inside? Commerce kickstart or what we generally refer to as a distribution of Drupal is a combination of things. If you get a distribution you're really getting Drupal Core packaged together with an installation profile along with contributed themes or modules and configuration that ties it all together. So again it's a lot of moving parts but it's core installation profile, modules, themes and config that tie it all together. In Drupal Core, there are installation profiles. Anybody know any of them? Give me one. What was that? Standard, yes. That's what I normally use. But yeah, there are installation profiles in Drupal Core. So this just adds one more to the application and then I think we use a patch. I'd have to look at the composer.json file again but to just make the installation, or the installer go straight into installing commerce kickstart versus requiring it to be selected as one of the various options. But you have the installation profile which takes over the full installation process. We created a custom admin theme by sub theming Claro to make sure that the installation and maintenance pages look great. And it installs its own dependencies, adds steps to the installation process and then brings along with it some default configuration which we put in different sub modules so you can just install the default configuration that you want and then you can choose either to customize it and manage it as your own config or to leave it alone. And in the future, we'll be able to intelligently apply updates to those default configuration elements. We also have a default store theme called Belgrade for obvious reasons. We have an office there. One of my co-founders in Centaro is Boyan Zavanovich who's long one of the top contributors to Drupal. He's now writing go code because he wanted that change of pace. He had too much of me. But no, he's in Belgrade, Minyar engineering director in our front end site building team is there as well. So it's an homage to where a lot of our magic happens. And it's an attractive, mobile optimized, bootstrap based theme that's really cool when you combine it with layout builder because there are modules in the Drupal ecosystem that let you do things like apply bootstrap classes to the components in your layouts. So you're giving the site builder really a lot of like muscle to create nice landing pages, product display pages and so on. And then finally we have certified projects. So this is kind of us trialing out what does it mean to identify certain contributed modules in our ecosystem as trusted. They're either maintained by us or by people that we know to the same degree of care as commerce core itself. So that means automated test coverage. That means documentation, responsible maintenance. We want responsible disclosure of security vulnerabilities through the security team. We want to make sure that the documentation is current and up to date and that all of the modules that we would certify for commerce kickstart work well together. So you don't end up adding a stock module that then breaks your stored locator module or something to that effect. And then it's all tied together by what's called a project template. Has anybody used a project template before? Perhaps you've heard of the composer project template Drupal slash recommended project, which is the way to start a new Drupal 9 project. If you're just starting from scratch, I've used it for my own blog, used it for other sites as well. And the project template is basically just grabbing a composer.json file that's been registered with packages as a project template. So you type out that one command and you suddenly have a full installation of commerce kickstart ready to be used. I use DDEV, so you then just have to change into the directory, type DDEV config, enter, enter, enter, DDEV start, you can do it in my sleep, wait 30 seconds while mutagen sinks, boom, you're ready to go. And then if you want to add the full demo store, oh shoot, do you have the demo store, the demo module in yours already? Okay, again, not my machine. But then you just add an additional dependency. This is a Drupal slash commerce demo. And the reason we separated out the demo module from the installation profile itself was one, just a separation of concerns, but we don't want all the images and things being perpetually maintained in the code base of anybody who ever starts a project from commerce kickstart project. Again, the idea is for it to be both a demo tool and a development tool. So if you don't need the demo store, you just don't get it and you don't have all that bloat and cruft in your code base. All right, we're gonna do it live. We'll see how it goes. Oh geez, why does command tab not work in your machine time? All right, here we go. So as I said, like once you just install from the project template, Composer installs everything it finds. And in this case, that means Drupal 9, the commerce kickstart installation profile, our Centaro-Claro theme, the certified projects repository and it's just kind of ready to go. So it's gonna do its installation, I hope. Oh yes, okay, thank goodness. And if you're curious to see what's inside the certified projects repo, it's up on GitHub. We've registered it as what's called a meta package with packages. Oh geez, oh geez, sorry, Tom. Don't look at his TFA settings. But it's pretty simple to just look at it in the composer.json file itself, but you can read in the read me there. Like what are the certified projects? Which ones are we looking at, including overtime, our technology partner integrations? These are people that actually directly fund and support the development of Drupal commerce. We love them. And then themes, et cetera, et cetera. And then kind of what's next on our roadmap. Modules that we've written that we wanna finalize and then pull into being officially supported certified projects within commerce kickstart. So that's where you'd find that information. And then if we go back to our installer, hey, it's almost done. You're not using, you are using mutagen, right? No, okay, I was wondering why it was taking longer than on my machine. His name's Max, man. All right, this is gonna be a little bit longer than I expected. All right, so then after it finishes installing all the modules, you're just gonna do your basic site configuration like normal. Like normal. I don't know, is it gonna fail on Symphony Mailer? Tell him what's your one password, password? Just holler it out. Password one, two, three. All right, we don't need that. And so then you get to the select features step. And so this is where if you're installing commerce kickstart for a sales demo, you're more than likely just gonna click that first check box, which is install all features with sample content. If you're starting a new project, you have your options of starting features down below. And our hope really is for our customers at the lower end of the market. So talking like projects that, maybe they have a few thousand dollar budget, but they could literally just grab commerce kickstart, we could install it for them, manage it for them if they want us to in a hosting environment, and they could just install it and sell. We have customers like that, a former colleague of ours went to start a mountain bike suspension company in Switzerland, let's see if his website's live. And you'll notice once we get into the actual installed version of kickstart, that it looks pretty similar to what you're about to see revealed. So this kind of a site, like he runs a very fine business, but he doesn't need a $50,000 e-commerce website. But he didn't want to just reach for some SaaS solution, one because he likes us, he likes open source software. And it's been a great relationship for several years now, so very happy. I'm just gonna do the full demo store right now, but you can see just demo configuration for physical products, licensed file sales, memberships using the commerce recurring module, the whole nine yards. All right, this one's probably gonna take a little bit longer, so. So what it has to do is install all of the layout builder tools, because Tsumchitsa has given us the full layout builder integration, including an attractive homepage that you'll see looks just like any e-commerce template that you'll find on Shopify or elsewhere. And then there's a variety of sub modules that installs, all of those different features, sub modules within kickstart, that just looks like importing default config. And then the final step is importing default content, because we wanted to show actual sample content. Minya gets onto me for it, but I did waste several hours one day writing fun product descriptions for everything. Including some short stories and the villas and the like. But that gets installed through the default content module. This is a module that lets you basically create content, export it to YAML files that will then be imported whenever you just run the default content import, post installation. Really cool module, not foolproof. For example, it kind of falls apart with layout builder. You know, we discovered that it doesn't do things like sort or use a predictable sort for importing media content. So then if you're referencing a media entity from a slider on a homepage, for example, it's gonna reference by ID and that numeric ID, not the UUID. So you end up with images being in the wrong place. So we're looking at how can we improve the default content module to have predictable installation or just to use UUIDs for everything, which is what it does elsewhere. So all of the product content imports just fine. This is a handful of quirks on the homepage layout that differ from my local installation versus the sample ones we've done in other environments. What else was difficult? Has anybody else worked with default content? Use that at all? No. Would you just prefer my great or buddy? No? Anyway, so you recall like Sooncheat says any other principal complaints with default content, it was just layout builder support, not using UUIDs, oh no, UUIDs for everything. Yeah, okay. Hopefully we didn't just lose our projector. How can you test what now? As in like right now? Well, if you go to the commerce kickstart project page, you can see that you just have to have composer installed and that's it. I mean, well, and or DDEV or your local development environment tool of choice. So it's just literally just three commands. Whoa, whoa, what just happened? Holy crap. Sorry, not my machine. It literally just create the project, require the demo module and go to town. That's it. And then we will be working with SimplyTestMe to get this new version up on SimplyTest.me ASAP. It's still links to the previous version of the demo framework we had. So now that we're fully installed, we have, yes, we made it. We have again, just an attractive store template with heroes with sliders that can be edited and managed directly within Layout Builder. You can do merchandising through your hero images. You can do merchandising through different product sliders. So we just offer again, just a way to collect products, manually curate products into a homepage slider. I don't believe that we're actually using views in here right now. We just kind of made this like a manual curation example. But we do have a full search API example coming. There's just some idiosyncrasies around making sure that all the fields are properly defined so you can build the search API index. That's a bit more complicated than just a basic catalog and slider presentation. And any of this is easily customizable just by going to the Layout tab and finding, again, I don't need to do a Layout Builder demo, but finding the region you wanna adjust, adjusting either the settings at the region level or in the component level. And again, combined with, I can't remember the name of the module to top my head. It's like bootstrap layout styles or something of that effect. It lets you alter the styling of the different components using bootstrap classes. So we have it just demoed both on the home page as a landing page example and then also on product display pages. So if we wanted to buy, I don't know, a gigantic inflatable pink flamingo. You know, we can see it's not rocket science. It's just using Layout Builder to put the image on the left, the product descriptions on the right, get your taxonomy terms showing above the title nicely, all that stuff. But it also works with the add to cart form. It works with Drupal Commerce's method of updating the different elements of the page as you choose your attributes, right? So an image might change, the price might change, the URL will update to show what variation you've selected. And if you don't want Layout Builder, the Belgrade theme will degrade. So we have some graceful degradation so that we have defined in the theme a product template that we fall back to if Layout Builder doesn't exist. So you at least have a side-by-side image and content layout by default. And I mean, if you've used Drupal Commerce before, the features aren't gonna be new to you, but we're able to do things at the installation profile level like override module provided configuration files. So this is important because Commerce Core doesn't add an image field to anything. But you don't often go to an e-commerce website with visual products and not see image thumbnails either in the cart block or on the cart form or embedded into the checkout, I guess I don't have in the cart block, embedded into the checkout process with a little summary. So we needed to be able to override this once we had defined that base field or I guess the bundle field in the installation profiles config. So it was really cool that we were able to do that. I didn't know that I could do that until I tried doing it with a custom module first and it really complained at me. And then it just happened to move it into the installation profiles config install folder and boom, it just worked, it's great. But it's not without, you know, it's risks. If something upstream changed in the default configuration that module, you're now responsible for incorporating those changes into your installation profile, you know, configuration. So just bear that in mind if you're doing the same thing on your site. You know, this is just a standard Drupal Commerce checkout form. It's side by side by default, but themed prettily by Belgrade. I'm gonna buy my Flamingo and ship it to Tom. That's not Tom's actual address, but it'd be rad if it was. You know, again, you know, shipping options, auto update is I'm entering my address information so it's automatically recalculating as soon as it can. This is not a real credit card gateway. It's just a, you know, an example payment method for you to be able to use and that's it. You know, now I've completed checkout and purchased my gigantic Flamingo. Sorry, it's not my machine. I may have said that before, but we do ship with default symphony mailer and DDEV mail hog configurations. You can just kind of enable that for local testing to see your email receipts or play around with commerce email or whatever. And I actually don't know. Let's see if Yvonne's themed the order page. Menya, do you know? I have no idea. Let's see if this looks terrible or if he actually surprised me. Ha ha ha, okay. Yeah, so he's even themed various parts of the account administration interface. So your order history pages, your stored payment methods, your address book, those elements are all kind of just, again, out of the box functionality of Drupal commerce and accounted for, you know, by the theme itself. All right. I think that's probably all that's, you know, worth reviewing in the installation profile. Obviously you can install it yourself, play around, it's really easy to get started and, you know, delight yourself, you know, with the dozens of products that we have for sale in this store. But one last thing, of course, because this is a new feature, it's just the idea that if you're selling media content, you might want to have both the physical version of the book or CD or whatever it is that people still buy these days, along with the digital version. And so that's where being able to reference variations of multiple types comes into play because in our variation type configuration for media products, we have to define what kind of license does it sell? And in this case, the license that it sells is a file download. You can, well, it's kind of small on the screen, but you can see that we are assigning, oh geez. Let's go back, there we go. When we configure this product variation type, we're assigning traits to it, such as provides a file download, provides a license, and then these things get tied together because file is just a license type. And then I'm granted access to download that file after purchasing based on whatever terms I've set up. So I don't even know, I guess it's set up at the product variation level. We can see that I might have forever access to this particular file download. Go to my cart, let's check out again. Because I've paid before, my card on file is what we call in commerce to a stored payment method. So that's just a default setting for any payment gateway that supports it. In fact, it's our preference is to tokenize the payment card instrument immediately on the checkout form so that even when you complete checkout, it's just making a charge against a card on file in the gateway's vault or whatever they call it. It's brain trees vault, I think customer information manager in authorized.net. In this case, this is just fake. So it's just using my fake card on file because this is a digital only order. I'm not presented with the shipping options. So there are different checkout flows and which one is used is determined by the products on my order. So we're gonna review, purchase it and hope that it shows up in my file downloads section. Nope, well, why not? Huh, no clue. That's a default configuration fail. But one of the things that's neat too about the fact that all of these content entities are being created is you can combine a standard Drupal commerce installation with the group module. I don't know if there's any error message here or not. Nope, I'll have to figure it out later. But you can combine Drupal commerce with the group module and then use group to represent a B2B customer. So suddenly multiple user accounts can be tied into the same entities within Drupal. So we have one customer that uses the group module to define organizations with purchasers who are all part of that group that have access to shared address books, shared stored payment methods, shared order histories, file downloads in the whole nine yards. And that was pretty cool. And I think that maybe in commerce three we want to look at making a customer entity more of a core concept and not wholly outsource that to group because group obviously brings a lot more to the table that can may or not be what any particular developer wants. So that's gonna end the let's do it live portion. We survived. So just to kind of wrap up some of the lessons that we learned. First of all, if you're looking to build your own distribution or similar installation or what Dries referred to in his keynote as a starter kit or starter template for Drupal, check out our readme. Anytime that I hit a hairy problem, I documented in there. I think we also have in contributing.ind a few other things as well. But one example was we knew that our commerce demo module needed to be dependent on sub modules of the installation profile. But the way that Drupal packages works right now it wouldn't resolve properly that installation profile dependencies. Just it just wasn't not ready yet. So composer would break if you tried to add the commerce demo projects to your composer.json. So we just defined it as a custom repository. It's still served from Drupal.org. We just get it directly from VCS instead of getting the packaged version. I used that same trick recently because we were using Asset Packages within Commerce Kickstart. Asset Packages was basically a wrapper around NPM and Bauer to fetch JavaScript assets and libraries to build into your code base using composer. People liked it because of the convenience of having this one tool to build all of your project dependencies. But Asset Packages disappeared. It went down for a full day. So if your build was dependent on that, you were hosed. Not only that, and I needed to double check, but when it came back online there was an area mention of it. So will it go down again? Was this, you know, how was it resolved? The registrar was in Russia. How was that resolved? I don't know. So we switched from using Asset Packages to just defining custom repositories or basically our own package definitions in the Kickstart projects composer.json file. So you can do that. You can literally build anything you want to into your project just by defining it as a package. You just lose version constraints and automated updates to new versions of those assets. So a few other things, you know, we learned that you really should figure out how to separate your default configuration from your demo content. So people aren't having to work against your starter template whenever they install it. You want to mind your dependencies in your installation profile? There are two kinds of dependencies you can put in your .info.yaml file. Those that are actual dependencies and those that are optional but pre-installed modules. So within commerce, for example, I might put a dependency in Commerce Kickstart on the commerce core module, but if I put a dependency on the commerce tax module now, even if you're building a site that doesn't need tax, that module must be installed. And I like to reduce that footprint as much as possible. So you just make sure you're putting things in the right category. But even more important is not putting dependencies in your composer.json file for just optional modules you want to bundle in with the distribution. So like all of those Centaur-certified projects, we put them in a meta package so that you could just remove that package entirely if you didn't want it. Or, and I kind of just bumped against this use case myself, for developers who may want to use a different version of a module you're including in your composer.json file, if you make that a dependency, a required dependency in your composer.json file that the 2.x branch and they want to use the 3.x branch, well, they can't. Like if Commerce Kickstart installation profile has one dependency and they want to change to something else, like they just can't unless they patch Commerce Kickstart or something else to allow it. So we use that meta package as just an abstraction layer. If they wanted to use, say, the new branch of commerce shipping before we're ready to certify it for use, you can just remove the meta package from your project. So remove Centaur-certified projects and then just add back the individual projects that you want at whatever version that you want them to be. So again, trying to prioritize developer flexibility but still put a lot in the package to solve for that simple store builder use case and or sales demo tool. Finally, like I said before, overriding module provided config files is great. You just gotta manage it. And then layout builder is phenomenal. But if you are gonna build your distribution around layout builder, everybody might not want it. We have some customers that use Aqueousite Studio instead. They don't need what we have to offer from layout builder. But you can still bake some graceful degradation into your installation profile to make sure that it works with or without it. And I think what's next is it's okay. So next up for Commerce Kickstart we'll have more recipes and more use cases supported by the default configuration out of the box. We'll also be splitting it into two flavors, full stack and headless. Some of our largest sites are fully decoupled projects that use the Commerce API module and or custom resources to power pretty robust store fronts. And then we're also finishing up a store wizard in a go life checklist. So again, that's just that we can deploy it to a server for somebody, point them at it. They can set their password and then go to town preparing their store to sell. And maybe they won't even need support from us. Who knows? That's how we will double our user base, I think. And thank you for being here and taking it all in. Appreciate it. All right. And we are more or less at time. I think these are 50 minute slots. I can field one or two questions and then I'm happy to make myself available for conversation afterwards. And if there aren't none, that's fine too. Yes. Yes. Yeah, I do not. I'm still, you know, I have a pool of requests I need to pull in. But obviously, like to be honest, in many respects, I'm a builder, not necessarily like an infrastructure decision maker. So I will follow Drupal cores or the Drupal projects lead. And if that's, you know, whatever the best practice is that's what we'll implement basically. No, that's not what I was saying. I've always been a strong advocate for the GPL and for free software. And I, you know, more than happy to do what the Drupal project does to make sure that we're compliant and, you know, advocating for best practices. But I literally just did this like three days ago and then I flew to Portland. So we'll figure, we'll keep iterating. Any other questions or? Yeah. Yeah, the question was, is Drupal commerce ready to be used in fully decoupled contexts? Yep. We have a case study that we've shared before at Drupal on Amsterdam for MatSmart. They're one of our largest customers. They're based in Sweden and their website started out as a full stack Drupal seven project. And over time as their business did well, you know, they raised multiple rounds of venture capital they've grown to expand from beyond Sweden into Finland, Germany, Denmark. This site, in order to keep up with, oh geez, anyone, we're gonna go with God can kekor. All right, whoo, all right, I guess right. You know, first we had to just make it scale as a full stack Drupal seven commerce one edX project, which meant, you know, say changing your transaction isolation level if you've ever had entity deadlocks. Then we had to begin decoupling individual elements. So like using a JavaScript template to build the shopping cart block in the cart form instead of using views and the forms API completely. And then finally, fully decoupling. So this is just a react application and the back end now is completely decoupled, which then is great for expanding in the new markets because we can just replicate that back end, relaunch that front end, and we're able to kind of like piecemeal our way toward it. So like the same front end was being powered by both Drupal seven and Drupal eight back ends. And so we got them all up to date on Drupal nine. It was really cool because we've done smaller things as well, like just react applications embedded into university portals so they could drive alumni engagement and raise money for the universities. And numerous other use cases besides. Yeah, thanks for the question. All right, let's wrap it up there. And I'm happy to chat more if anybody has any other questions about the project in general. Thank you.