 I'm going to set a timer for 25 minutes because that's how long we have to talk about four years of activity. So this is an ambitious presentation about, you know, a platform for ambitious digital experiences. Let's see, 25 minutes starting now. And I'm going to kick us off, and then I'm going to hand the mic over to Matt and Boyan to awkwardly, like, trade the spot at the microphone. We are together the core maintainers of the Drupal Commerce Project. This has been kind of our bread and butter for years. Together we make up the core team of Commerce Guys. We have four other compatriots, commerce developers, and consultants that we work with. And since last year, we have been functioning independently of Platform.sh. We separated the businesses so that we could get back to our first love and focus on our mission to engineer simpler solutions to the hardest parts of selling online and not, you know, have essentially a services team subsidize the development of an unrelated hosting product. So this renewed focus has given us a chance to rededicate ourselves to developing Drupal Commerce, the core framework, developing Drupal 8, and contributing to things like Composer Support for Drupal 8 and Drupal.org, so that we could ultimately have a stronger e-commerce platform that we can then sort of refocus on building the ecosystem around. So this is where we are today, but sometimes it is helpful to take a step back and just remind ourselves why do we do Drupal Commerce? Because we could, if we wanted to, just become a Shopify agency. We could become Magento developers if we wanted to. So what is it about Drupal Commerce that still sets it apart enough to keep us working in that direction? And the first thing, of course, is that we do fundamentally believe in free software. So that's the F in free open-source software. Free software, you know, implies not just price, but also license and responsibility. It's free as in puppies, as I've heard Jeff Eaton say. You can take the puppy, but it is yours now. As I learned this year, I made that mistake. But there are very few free open-source projects in the world that support e-commerce. Even our primary competitor Magento is fundamentally like a kind of Crippleware unless you have the money to buy an enterprise license and then kind of go from there. We also believe, though, that Drupal as a business application platform is more flexible than the sort of core framework and APIs of any other e-commerce specific application. And I'm not just talking about open-source software. I'm also talking about Hybris and Demandware and these other big applications that we'll compete against. But also at the low end as well with Shopify, WooCommerce, Virtumart, et cetera. Drupal is just fundamentally more flexible and that's really kind of core to the Drupal community overall. I don't think that should be a surprise to anybody. We also believe that merchants and developers are going to benefit when they wed their commerce and content like portions of the site. We aren't siloing your e-commerce application on a subdomain and your blog on a WordPress subdomain and trying to sort of loosely string all these things together. We create this integrated whole in terms of the customer experience and shopping experience but then also making it easy to use Drupal commerce as a front-end for third-party applications. And these we believe are four of the key selling points for Drupal commerce. And of course, every particular site, we'll take them on a case-by-case basis to decide what's a good fit. But this is what matters to us. And people are using Drupal commerce today to add commerce to existing content sites, to create subscription sites and paywalls, to sell file licenses such as RiftTracks with the Mystery Science Theater, 3,000 soundtracks sold through Drupal commerce. It's also helpful that you can take Drupal commerce and expand internationally because we are multi-currency, multi-lingual, multi-store by default out of the box. And one of our largest clients right now does this on a massive scale throughout Scandinavia and have not yet hit the bounds of what you can do with Drupal commerce. We're talking hundreds of concurrent sessions running through checkouts. There's the support for scale both in terms of raw numbers but also in terms of channels and languages and currencies and everything else. And then finally, you can also create one application that is really good at combining multiple concerns together including B2B sales and B2C sales in one platform with loyalty programs and so on and so forth. There's really nice, rich front-ends like the recently launched Orlo Watches website. So if you go to OrloWatches.com, this was launched by 1x Internet. We met them at DrupalCon Dublin and they disappeared for three months and produced like one of the best Drupal commerce sites that I've ever seen. And they were able to do this with commerce 2.x with a completely custom checkout flow. And who knows what else under the hood. I haven't had like a full debriefing but Boyan can always tell us more about that as he talks through the creation of the current version of Drupal commerce. Go ahead. So there we go. Hey, did it take five minutes like you expected? That's great. I love hearing you talk, Ryan, as always. So the reason why commerce 1.x was so successful was because we started from scratch on Drupal 7 and we created an application that was immediately familiar to anyone who knew Drupal 7. And if we wanted to repeat the same success and to recreate that native feel, we once again needed to start from scratch on Drupal 8 simply because Drupal 8 is such a different platform. And that was a great chance to re-evaluate everything that we've done, all of the feedback we've received to see what went well and what went less well and simply do that better this time around. We realized that in the beginning with commerce 1.x we did not prioritize user experience enough because we launched without inline entity form and it took us a year to develop these crucial UI elements that were needed for easier product entry and for a better checkout experience and for a better customer experience. And in that time people got the impression that commerce was not user-friendly enough even though we solved that, especially once Kickstart came around, the impression stuck. But this time around we are doing all of that. We are integrating inline entity form and we are prioritizing the checkout UX. We also realized that it's not enough to simply be unopinionated, it's great to have an opinion, developers just need a way to provide their own, to swap our implementation and do their own thing when business requirements dictate that. But we're definitely looking at a more opinionated framework and simply to help other developers and agencies do their job right. Because people are not asking what it is that the Drupal commerce module can do. They are asking what the Drupal commerce ecosystem can do and we are all that ecosystem with our contrib modules, with our themes, with our distributions and with our agencies in the community. We also realized that commerce itself needs to grow. Out of the top 60 contributed modules for Drupal 7, half of them are no longer needed for Drupal 8 simply because we've taken that functionality and incorporated it into commerce 2.x or we simply improved core enough to make those modules just not needed and that includes modules that's added elements to checkout, for example being able to log in or register at the beginning of checkout, being able to see at which checkout step you are, being able to register at the end of checkout, UI elements like that. Then the ability to reuse addresses, to reuse credit cards and it goes on from there. As I said, we started from scratch and by now we've had over two years of full-time, full stream ahead development on Drupal 8. We are now preparing to tag our last beta release today or tomorrow right here in Baltimore. In fact, 30 minutes ago I actually merged the tag sub module which was the last remaining big piece and big blocker and our plan is to tag an RC one by the end of May after we've reviewed some of the other. So basically this beta gives you taxes, gives you greatly improved promotions and then we want to fix all of the bugs that we can find and at the end of May deliver something that's really solid so that moving to July we can actually tag a real 2.0. Then Bojan gets his mattress back. Then Ryan lets me return home to Serbia. I miss my family. The good news is that Drupal Commerce is production ready right now. There's an upgrade path. You can start creating sites. There are dozens of live sites launched already that I'm intimately familiar with and there are hundreds that I'm not familiar with. And there are over 20 payment gateways that you can use to actually collect money and get your project started. And more about features from my colleague Matt. So one of the great things in Commerce 2 is the concept of stores so you can have different stores that products belong to and order is made from. So the store allows you to set what's that email if they need to contact that specific store that they ordered from, the billing address. And then with the tax items merged you can now define your tax information per store. So if you have a Canadian store it will use the Canadian taxes or if you have the U.S. one you could tap into a service like Avalara to help calculate what taxes you have to pay. And one nice part about it too is you can then use it to help with the domain module or other ones to configure how your store looks. So if you do go to that Orlo Watches, play around with the different countries. If you pick United States you go to the international one. If you pick Denmark it actually brings you to dk.OrloWatches.com and I'm pretty sure they're using domain with stores to change how the site interacts and what products are available based on that using one Drupal site. And you can learn more about stores on our blog. We have a story there. So products in 1.x if you're familiar with it there is nodes which reference products and that was a product display and it was kind of a disjointed UX. So now we just have the product entity. And within it are variations. Variations are what you buy, right? When you go and send somebody to go pick an order they have different pallets that are your different products. I have a large shirt, you have a medium shirt and say Ryan is a small. So that's your variation. And to make, to identify different variations you use product attributes, color, size. If you have a subscription platform this could be your term length. Is it quarterly? Is it yearly? Or is it however that goes? So this just helps you identify what makes the different things that people are buying. You've probably seen the demo on the booth with this. Yep and I got it. So what product attributes do is, so in 1.x if you wanted to show fancy attributes is what we're calling this. Because if you go shop online you see this at every single e-commerce store where the color is a swatch. It doesn't just say red. So this allows you to use the improved entity system and display modes to actually turn the attribute into a rendered color field. So there's actually a color field module which finally had a critical bug fixed. So this demo works without a patch. And it allows you to then pick different colors and change those. And we have a demo down at our booth in the Expo Center. So if you come we can show this live or if you go we can give you a few different URLs to try this out on. And then we have different order types and order item types. And why this is special is if you have different flows. Let's say you have a mixed store that sells physical and digital products. If you have a physical product you need to capture shipping information in a shipping method. But if you're selling an e-book at the same time you don't need to collect that information. So you need a specific experience for people to go through. And this allows you to do that. And then that ties into the checkout flow. So you can have different buying experiences that people can go through. Buying and mimicking the field UI for configuring checkouts. So if you're used to configuring fields you can configure this real well. The different steps is what we're calling them. Login order information. Or where pains will go. And then you can configure. You can click the cog and configure. For instance there's a login and you can change it to be guest allowed or they have to register. Should be the next slide. So we've taken that UX. One thing before we leave this part that I really wanted to mention because it's really, really cool and really important. We were creating our stores. We realized that many stores have very, very different kinds of products that they sell which dictate a need for completely different checkout experiences. For example we would sell digital products like platform.sh subscriptions but at the same time we might be selling event registrations. For example selling our own trainings. And then some other sites would at the same time sell physical products and digital products. And these groups of products had completely different heads to cart forms and completely different checkouts. But since commerce 1.x always had a single order type and a single checkout type it was not easy to create these completely separate experiences and simply plug our logic in. But this time since we support different order types since we support multiple checkout flows that map to them we can easily create this out of the box. So we can click together checkout flows with different numbers of steps and different information required based on what we're selling. And since the checkout flows are backed by plugins they can actually affect how the steps are displayed. So one plugin might have a page per checkout step but another might have an accordion like you have on the Apple Store website. And all of that is given to us by this greatly improved API that we've built. And which ties into what we've done with the improved checkout UX. Okay. I kind of stole the mic. I know. I'm terrible. So with the checkout UX we looked at 100 websites all of the biggest e-commerce stores and looked at other systems to see just what the latest trends are and what the requirements are and how we can improve commerce to be better and how it can convert better. And some of the results are already in. Others will be visible in the future because it's an ongoing process. But the first thing we did is we now have a checkout progress block that you can see at the top so you can see on which step you are and what the other ones are. That required a separate contrib module. You can configure whether you allow anonymous checkout or not which forces the user to register on this screen or gives them a button to basically skip this step. Of course you can allow the returning users to log in right away. So that replaces the checkout redirect module and it goes from there. We have the ability to reuse cards. So we save the credit cards if the system is configured to do so and then the customer when they return they can use a previous card, the previous address with no extra modules. We've also moved the order summary to the sidebar because that's what sites now do and it's much easier to customize. It can have pains of its own which means that customers can actually modify the cards from there if a contrib module makes it possible or they can input a coupon code there. We actually have an issue for that that adds a coupon code to the sidebar. So once again we have this screen as well. Other complaints were that the review step was not easy to theme. So simply anything we could we rewrote to be more friendly. And if you look at the blog post we did for Alpha 4 you can see some of the details around these UI elements and we'll be providing more information about our reasoning once we tag an RC1. Payments were a big thing that we worked on and we've spent many, many weeks on payments and then my laptop got stolen and all of that code disappeared. Drupal Dev Days Milan it was a nice yeah that was a fun summer so then we worked on payments again and then it's called coffee on the new laptop and then this time the code was on GitHub and coffee did not affect the code. But the second version of the code was even better and what we did was create Yeah I'm crying inside. So we created an API that allows developers to do much less work when they create a payment gateway. Previously you needed to spend around five days building a payment gateway but now you can create an equivalent payment gateway in about three to four hours simply because our API does a lot more. We have integrated commerce carton file which allows tokenizing payment methods and allows saving cards so they can be reused in a PCI compliant way. We've added support for alternative payment methods such as Paypal that's the brain tree module now takes advantage of creating different kinds of payment gateways so that you can choose the templates that you need to copy when you're creating your gateway. So we now say the gateway can either be on site which means the form is on your checkout page and probably uses JavaScript to tokenize like Stripe or brain tree and then we have the offsite gateways that either send you to a different site to enter your credit card information or show you an iframe copy one of those. Then we have a third category that is now in progress called the manual payment gateways which basically create a payment without communicating with an external API so that's cash on delivery paying by invoice those kinds of things and again this is the functionality that previously required external contrib modules but is now possible out of the box I already mentioned that we have over 20 payment gateways out of that commerce guys developed six brain tree was our reference implementation and I can still say that they are the nicest API to work with and pretty much the nicest option you can use right now they're owned by PayPal but don't take that against them we also have an actual PayPal module if you're into that we have an authorize.net module which is now which needs to get accept.js improvements in that library but it's a very popular choice and they have a good API all of these are recommended people have integrated Stripe and PayMill also from our organization and since recently Square they are now actually demoing at our booth so you can stop by and see how that's working so those are golden payment gateways from there into a variety of small local ones because in the U.S. it's easy people use Stripe, PayPal, BrainTree but in Europe every country has its own completely odd gateways so that's why the number keeps increasing and Matt will tell you about promotions in course instead has been his baby so in D7land, Discounts was its own module and Coupons was its own module on top of that and they were kind of they didn't really work well together they should have been nice together but they didn't exactly cooperate so now in 2.x we brought it in-house so that way it could just be more control over it and just get it right out of the box so we have it where there's different offers and these are all plugins so you can take what we have out of the box or easily write some code that uses architecture that you find everywhere within Drupal and speaking of that there's no rules because the rules module I don't know if it even moved in the past few months or not but when we first investigated this rules was in alpha and it actually extended the conditions plugins in core which power block placement so it was like great there's already an existing API inside of core that we can leverage so we did and that powers the condition system well then you add different conditions set a price or maybe a location and then we also have coupons coupons are just another condition but the condition is you have to enter a certain code coupons and promotions have usage limits so you could say that the promotion has unlimited usages but you can only use each coupon five times, something of that sort we have start and end dates to control when it starts, when it finishes and then we have basic compatibility and so you could say yes always apply this promotion or no this promotion cannot be applied if there's other promotions available and that will be being extended as people start implementing more and more yes and this was born actually this was pushed forward by two different client projects that I was on including the coupon pane redemption which is like inches away from being part of it so it's great to have adopters that push things forward and I mentioned that we just merged taxes which provides an API that allows both remote calculation and local calculations so in the US since sales tax is completely crazy you can and should use Avalara and that integrates into our system nicely but also if you want to hard code the rates that you're using you can input your rates and you can input the zone to which it's attached so you can say these rates apply in South Carolina and these apply in Kentucky and then figure it out from there and then what we've done is create a custom plugin for the European Union which actually provides all of their rates along with logic for B2B and B2C sales and digital and physical products so basically functioning like a small tax cloud for the European Union which I realized is not that interesting to people in Baltimore but it's pretty neat I mean no other e-commerce we've spent many many months researching taxes and there is no e-commerce system that does taxes as well as we do and we are looking forward to actually teaching the world once we actually have a release out we have a really old blog that talks about some of our old use cases so that's a good starting point and we will be blogging about this more when RC1 rolls around we have shipping oh god I forgot about that so we have a great shipping module it has support for multiple shipments which means you can ship to multiple locations at the same time or you can always ship to the same location but package the orders the order items into several boxes based on weight or stock location or whatever else is being done and that was done for interflora.dk which is a flower delivery website which is huge in Europe and their Danish site is now on commerce to the tax alright so we don't actually have time for questions from the stage because the timer has gone off is Jesper in here from ADAPT I don't see him well the gentleman who is in charge of the interflora website is here which is really cool to meet him I would like to thank you for your presentation at least underscore this fact that much of what we've developed is technologically superior and also born out of real live client projects that we've launched over the last several months so if you have any additional questions I want to see the square demo please come join us at our booth we'll be there until Thursday thank you