So a question, right. Commerce kickstart, like seems like a great starting point, right? Demo demo site. If you were like, Oh, let me show you what Drupal commerce can do. Like, here's a great example. I'll use commerce kickstart to get get that off the ground running running quickly. Right. So what I'm wondering though is commerce is a separate module or, or I guess it's a little bit of a grouping of modules right to run commerce. In what cases or what instances might someone say, I'm just going to use commerce directly as opposed to, as opposed

to using kickstart. Yeah. So, that's a good example. So, you know, you can use it to compose or like any competent developer can just do that composer, install Drupal slash commerce, whatever. What you get out of kickstart as a developer would be like a kind of like a guarantee, I guess, that any of the modules that we're going to kind of put into your code base have been maintained to like the same standard of care as like commerce core and some opinions about what additional things you might want to have in your project. So, I said, so like a project that's already going, just add commerce and whatever else you want. A project that's just starting today could theoretically still use commerce kickstart and just not install any of the default configuration. Because at that point, it's really the same in nature as the, what is it? The Drupal core composer project template. And to go back to the next question, like that's what Drupal, that's what commerce kickstart is. It is a composer project template, not technically a Drupal distribution. But we made our templates such that once you've installed it, we're not locking you into our opinions. So, even though we include modules, for example, by default, that we think are good and ready to be used. If you don't need them on your site, we don't like, we don't lock you into that. And, you know, one example I gave, I think, of that talk in Pittsburgh, John, is the one project template to be useful for developers who know what they're doing and don't want all the things. And for simple site builders or site, site, simple site building is we kind of have like a little bit of an abstraction layer in our dependency chain. So, all of the, what we call like Centaro certified projects that we throw into commerce kickstart, like commerce license, commerce shipping, modules that we maintain that expand the commerce feature set, but aren't part of commerce core. We bring those in through a third party project called, I think it's like Centaro slash certified projects or something. It's just a composer library that we maintain on packages. And so if your site doesn't need all that stuff and you're developing, say, well, I don't want anything going on to my production server that I'm not using. Well, then once you've created a project from that project template, you then just remove that group dependency and then we add the individual projects from that that you want. So, so the idea here is that like, if we had made commerce license a dependency of commerce kickstart and you use the commerce kickstart installation profile, then you could never uninstall commerce license from your code base, even if you never installed it in Drupal. You're still in the code base. And, you know, I think depending on people's security consciousness, I mean, like, like having code on the web server is a liability, even if it's not supposed to ever be used. Right. We know this from the WordPress plugin world, right, like somebody could go, I mean, tomorrow, put on my black hat, I could go buy probably five WordPress plugins that all have 10,000 users each and add a backdoor script into those projects. And then push out updates and nobody would be any of the wiser. That's happened. And so

you don't want that happening, you know, if you don't know. I know means are we suggesting that any of our listeners go and do that. We're just saying that they're. No, no, no, no, no. But it's not. So that's like, they basically tried to make it so that it like

we could use it internally when we launch a new project that's not going to use any of the kickstart feature set.

So you still use kickstart internally. Yeah. Yeah.

So I, I was

just saying I'm glad we're talking about this because I'm in the process of like finishing touches on a commerce project and we were upgrading from a Drupal seven commerce kickstart project and we explicitly didn't use kickstart because it, I think in seven years, it was a little bit more opinionated. It was more of a good traditional distribution. So we were a little terrible at that. So,

and learn Indians in there. It was good for the time, but yeah.

Yeah. No, it was great for then. So, um, are there any, if you use internally for everything? Are there any cases you would say somebody shouldn't use commerce

kickstart? Honestly, like, um, I'd say that most agencies and probably many freelancers and solo solo preneurs, if you will, have a starter kit that they use on every project. Um, like, like we discussed earlier, right Mark, like admin tool bar. It's on every project. So if you don't want to have to retype in composer, install admin tool bar every time you go start a new project, you know, most of us end up with whatever the, the agency slash Drupal, you know, project name is. I mean, I'm sure I'm sure most, if not all agencies have this because you need a standard way of starting a new project if you're trying to sell your services. Um, so, you know, look at what it has to offer. And if that's good enough, then, then roll with it, you know, the other advantage is that, you know, we're kind of making that commitment, like the projects that are included here will be maintained to the same standard of care as commerce core. Um, so at the very least, you can, you can say before you go fetch a new project offer, Drupal.org to build your site, you can at least see, okay, well, does Centara think this is a good idea or not. That's not to say there aren't good projects on Drupal.org that we don't maintain. We may not be able to guarantee it. Uh, and then finally, and this, we haven't realized this potentially yet. And I can't remember if it was part of my talk in Pittsburgh or not, but like my goal would be, um, simpler migrations. So in other words, if you know, commerce kickstart two dot X is the source. And then commerce kickstart three dot X is the destination. We can actually create reusable migrate plugins or migrate configurations. Um, that, that handle that source to that destination, but it's, it's a bit harder if you don't know what the, the destination looks like. Um, you know, everybody has to create those migrate configurations themselves or whatever. Yeah,

I will, I will say the profiles and legacy orders that migration was, I mean, we basically flattened a lot of that data and try and migrate it as like a legacy. So we can have like a legacy portal so the client can go back and look at stuff, but yeah, we don't have a lot. Yeah.

Like I asked the client to say, Hey, look, like we can do a one for one data migration for you. How much money do you really want to spend on this? Okay. What data can we leave behind? Um, because they don't, they don't need it all. You don't, I mean, yeah, at the very least, you know, you don't need it all in the same shape that it's in and in Drupal commerce. Like, if, if I can, if I can just add a log. So in Drupal commerce too, we have this concept of an activity log on orders. That's where things like state changes are monitored. We don't, we don't use revisions anymore for various reasons. But if I can just add an additional log whenever that migration happens, that just kind of has the pertinent information from the previous order and save

two months of migration writing. Yeah. Probably better for the client. I'm glad to know I made the right decision there architecturally because I was looking at migrating orders and I was like, Hmm, this is going to take months to a legacy. Um, but interesting.

Is there, is there a something, is there a certain type of commerce site that commerce kickstart lends itself, or is it pretty much a nice blanket?

Yeah. Yeah. So, so, uh, I'll say basic catalog stuff, my basic physical product sales with a nice attractive visual catalog where you have good images for everything. Um, totally fine out of the box just to rock and roll. Um, we do have commerce license in there now. In fact, the one of the main reasons we didn't, we don't actually have the 3.0 point. Oh, tag yet was we were waiting for the commerce license full release, which just happened over the summer. And so now we're ready to move that forward again. But if you're selling file downloads, I think it's a great starting point. Um, for that. Um, we, uh, we wanted to be able to support, like membership and recurring building use cases, but frankly, we just descoped it for the sake of getting something. Um, but that's why in Pittsburgh, my, my session was really focused on that file, download, certificate sales, use case. And it's done a

lot with like reoccurring, reoccurring payments and subscriptions for a while, right? Well, what

commerce has, but kickstart doesn't have like default opinions on that, if you will. Yeah. So I mean, yeah, we have, we have many recurring building clients on Drupal commerce, but we, like you and be able to just get that out of the box and commerce kickstart today. Got

it. Interesting. So we've talked about a couple of other other services, right? Shopify, big commerce, those sorts of, those sorts of things, right? I'm wondering. We may, we may not be able to answer this question. We'll see. I'm wondering how you feel Drupal commerce and commerce kickstart kind of stack up to some of those solutions, more specifically like Shopify,

right? Yeah.

I mean, like the, the simple answer, of course, is like, there's no contest. I mean, Shopify has five billion, billion dollars to advance their platform. And they got to a point where most of their innovation today happens around the edges or around the customer experience, meaning they're an app marketplace. All of the innovation happens through third party app developers working in their ecosystem, but all those companies have a built in business model by being in the app store to do things. And, you know, Shopify as a company is a payments company. Like most of their money comes from merchant services comes from lending their merchants money and getting interest from them. It comes from the transaction fees from the gross transaction volume on their platform. Like this is all public in their filings with the SEC. And, and, like, so just, just technically speaking, like there's no way we can compete with such a behemoth. However, right, like you always want to find, well, who, well, then who wouldn't really want this? And that's what that's what we try to focus on. It's like, okay, like the feature set that we have is good enough for most merchants who don't want to end up competing with their platform provider. All right. So, and that's a, that's a, that's a bit of a marketing spin right, but like it is true that if you sell on Shopify, they're going to use your data to push other people's products. Oftentimes your direct competitors. And the example that I use, you know, is my friends coffee or a certain methodical coffee here in South Carolina. I bought coffee from his website. I love them. I support them. And I got credit for using shop pay, $1.47 in credits now or whatever. So then now Shopify sends me push notifications from the shop pay app for other people's coffee I might be interested in. Oh, and those other companies are part of a promotional program where we will 10 X your shop dollars. So I can go get $15 off on, I don't know, black rifle coffee or whoever else is selling on there, which means like methodical coffee is paying a monthly big monthly fee to Shopify to now promote their competitors products to their every customer. So when you think about like, how do I stack things up? I say, cool. Like Drupal commerce will never do that. But

also one of the magical lands in the Dries note fairytale. Yes. Yeah.

Yeah. So, yeah. So, wait,

wait, good call back there, Mark. Yeah, I think, you know, folks, if you haven't, you know, stop this episode now go listen to the Dries note, come on back and we'll still be

here.

Ryan, I think you raised an interesting point there, right? So like, I don't know that people tend to realize when they go to a solution like Shopify. And, you know, I would say that Shopify is great if you're, you know, a small brick and mortar store that needs to get online or you, you know, you may not be, you know, you may not be able to support, you know, infrastructure and developers and people to kind of build you a Drupal, a Drupal commerce or a commerce kickstart site, right? So like, I don't know that people tend to realize when they go to a solution like Shopify. And, you know, I would say that Shopify is great if you're, you know, a small brick and mortar store that needs to get online or you, you know, you may not be, you know, you may not be able to support, you know, infrastructure and developers and people to kind of build you a Drupal, a Drupal commerce or a commerce kickstart site, right? So like Shopify is great. So like Shopify has a, has a use case there. But I think for, you know, larger organizations that are looking at e-commerce, like that's an interesting point to A, you have to pay Shopify for their services, right? Not that implementing Drupal is free. We all know that's, that's, we not, not the case. But, you know, it's not, there's not a licensing fee or a monthly, a monthly payment there. And then you're not also necessarily providing them permission or the ability to kind of like promote other

people in the same way. You endure data against you.

Right. Right. Like, so like your coffee example is a great one, right? So I think that's like, that's an interesting consideration for folks.

Yeah. And I think the, the honest fact is that most merchants don't really care. You know, otherwise there wouldn't be a bajillion Shopify sites. They just wouldn't be. Right. The cost to them of that is lower than the cost of paying somebody to build them a custom e-commerce website. We want to reduce the cost of building someone a custom e-commerce website, but it will never be zero. But I think too, like, like what, what does get obscure is the fact that most Shopify sites have any appreciable complexity have their own build cost. And then you're hiring a Shopify agency to go implement some custom template for you and learn the JavaScripty templating language that Shopify has to write custom Shopify apps for you to do the integrations that they don't support or to add the features they don't have. So like, like it's not, it's not that different. There are still some things that, that, you know, would be nice if they were easier. So like I can go install commerce kickstart right now, but I still have to know that such a thing as a payment gateway exists. If you just launch on Shopify, you're collecting payments immediately as soon as you go live. Very different. Right. And so we could, for example, embed payment gateway modules into commerce kickstart that have simple one click. Get me started things like like whether that's PayPal's merchant on boarding or Stripe Connect or something like that. But, but typically, you know, that's like, like in the case of Shopify, if you're using ShopPay, like they've certified you and have granted you that that merchant accounts are now willing to. Just kind of green light your payments on boarding, whereas, you know, it could be just a little more scary to work with the third party to get that all sorted out. I don't know. But the other nicer thing, we discussed this earlier, like, because, because they are just providing a purpose built e-commerce application like the back end is just a lot cleaner. You have the full, like, really, like almost the same if not better product management capabilities out of Drupal commerce out of the box as you would get on Shopify. In some ways, much better. We, for example, do things like structure the concept of a skew with a product variation, whereas Shopify still uses that Ubercart style, like toggle on all your options, then you can get this form and try to tap in all your skews and hope nobody ever changes anything. And then you lose your skew. We support unlimited product attributes, whereas in Shopify, I'm pretty sure it's still just three. But again, most merchants don't care about that stuff. So, what they do care, though, is that when they go into manage orders, everything, like, the back end is just, I'm managing my store, whereas the back end of Drupal commerce is still, I'm managing my Drupal site. And that's just like one step removed. It's a bit abstract. Our order management interface needs to be better. Right now, it's just kind of painful to manage the order items on an order. If I could pick one place to wave a wand and magically improve it, it would be that order management UI, specifically for editing orders. I think we're actually pretty solid for viewing managing customer servicing orders. But if you're trying to edit an order, there are some gaps there.

Yeah. But even one of the things my client just to cover the other day is you can add items and create a cart for somebody. That's not a lot. If you have a customer that's having trouble finding the right item, you just edit their cart and add all the items. But yeah, you're right. It's a little clunky, but it's painful, but it works, but it works better than the

past.

I'd like to point out before the next question that you have a buddy that runs a coffee business and I've yet to see you at a coffee

bath. Just to really play it out. My bad. I should bring his coffee. It's really good. They've been on it lately with these more experimental Colombian producers that are doing things and generating flavor profiles like in the past, I've only ever seen in like natural process coffees out of Ethiopia. Costa Rica. But stuff like this, this one coffee was basically double anaerobic fermented the secondary fermentation involved in an oculation of yeast from like from a beer production. It's like a, they call it a IPA wash coffee where, sorry, it was just the IPA varietal is coffee. And so it had hops and this, this yeast inoculation put into the secondary fermentation. And I swear it was like, like I had it as a quartado and the aftertaste was like fruity pebbles milk. You know, that like kind of like generically limey citrusy sort of flavored milk. Like that's what the quartado tastes like.

So for our for our,

join the coffee. I can go along on that. For

our listeners, we'll have a link in the show notes to Ryan's friends coffee. You too can order it and try it

yourself. Look up Sebastian Ramirez on all this stuff. All my favorites from their site right now. Okay. Okay,

so switching gears a little bit, both from the coffee and from the previous question. I'm curious about commerce itself. So I, as I mentioned, I'm working on a commerce site right now and the client had a requirement where pricing for particular products was different depending on the role. And I got ready to kind of just write some custom code and what we had recently had your in host on the talk about the CA. And I remember, you know, rules has always felt like one of the big missing pieces in Drupal eight plus. Yeah. And ECA is not, you know, listen to the show. It's way more complex and powerful. I decided to just write an integration between ECA and commerce. And so right now it only has a couple of actions, you know, the ability to reset a price. But it posed all the default conditions and action events from commerce. So my question is, this is a little, I guess, maybe selfish, but also it helps the community, but I'm curious about what's the process for getting like additional, you know, conditions or something in commerce core. For example, I was recently trying to figure out how to check if a user had a cart. And there's no like condition that commerce cart provides that says like this user has a cart or more cards because there's just that little cart. You know, is that, is that the kind of thing that, you know, there, it's on the roadmap somewhere, you know, just, no, I mean, honestly, great feature request for the issue queue. Yeah.

Happy to happy to do

that. But I'm curious, like, what, what kind of processes there for that? Like, do you guys kind of rely on the community for those types of feature requests at this point? Because it's kind of stable or do you kind of still have brainstorm sessions? You're like, Hey, what are we missing? What are the gaps and. Yeah.

So you have like, there's three threads that I'm going to try to follow up to in reverse chronological order. Sorry. No, no, there's two, two, the two previous, so two of the threads with things that you didn't directly ask. So I'll answer your direct question. I'm going to work my way backwards. The, the, the simple answer to that is that we, we add new conditions to commerce core when we have clients that need them. And we say, this would be good for everybody to use. Why don't we just make this a generic one, patch it and put it in the next release. So the process for anybody else would look very similar, like, Oh, I'm going to write this thing for my client. If I just make it generic enough that anybody could use it, I can throw a patch in the commerce core issue queue, and we can get it, we can get it integrated. So to be in commerce core, that means it's going to have to have some test coverage. So that's a little bit of an extra burden on, say, just a typical project budget, maybe. But testing a new condition shouldn't be that hard. And I'm sure there are, there are templates for doing so in the promotions module at the very least. Either that or I'm wrong, and we just don't have test coverage for those, in which case, fine. You know, just throw it back. So, so we do have like pretty broad coverage for most things that we think people will need for promotions for shipping method or payment gateway availability for tax applicability, because most of these things are just kind of dependent on like. Aspects of an order or have a billing or shipping profile. So like how, where is it shipping to? What user role does the owner have? What's the total order value, et cetera, et cetera, et cetera? What taxonomy terms are applied to a product? That kind of thing. But there's always going to be stuff that we haven't foreseen or just even thought about. So, you know, does this person have a cart or not or another cart or a cart for a different store, even? Those are all interesting things. Right? Because like you said, you can have multiple carts in commerce. Each one could represent a different store and maybe I want to offer somebody a discount when they buy from multiple vendors at the same time, whatever that would look like. Who knows? But so yeah, so that just begins in the commerce issue queue. And if you don't get any traction from us there, because there's frankly a lot of issues a lot of people can contributing in there and doing work in there. Then we were pretty active in the commerce channel in Drupal Slack. So if we don't see it or if you just want to get some eyes on it, is this going in the right direction? Pinging us in there, even just the community in general, like I'm on there all day every day. You can probably see me there throughout this morning even. So it's, you know, hopefully, hopefully we're not that hard to get ahold of. But right now, you know, like our core internal discussions around like core improvements are more around like our frustrations with the payment API limitations with the model of payments entities right now. Or the kind of intricacies that arise between a payment gateway plugin and a store payment method when that gateway might create payments of multiple different method types. So like the stripe gateway supporting credit card mobile wallet, a firm cash app, Venmo payment methods. How do I manage that within one module? So that's where a lot of our future thinking is going toward, but like conditions are like, those are, those are pretty low hanging fruit. I think if you had a good idea, I think that we'd get it thrown in pretty quickly. To go back one step, thinking about ECA in general, I actually did have a good conversation with Jürgen about this at DrupalCon Leal. So we talked to some length about the status of the module, his desire for me to take a look at it and see about making a more official integration supported. The reason that didn't happen, like you said, is that, well, rules just didn't exist and we needed commerce to be done. So we skipped rules, but we also replaced it with kind of more natively embedded conditional interfaces within Drupal Commerce that we believe better serve the average merchant. So that's always going to be the challenge with like an ECA is like the same problem with rules. Like unless you were a programmer, you could not create a rule.

Well, that's the nice thing about the ECA, both how Jürgen kind of architected ECA and how you architected commerce is like my plugin, obviously I'm creating the custom action. This is kind of this kind of some actions that probably are missing that people would expect, but if you, we have drivers for the conditions. You provide a condition is automatically available to, although there's a couple of exceptions, but in general, the conditions are always available. The events we have to manually listen for because ECA has to kind of intercept them and act on them, but there's, you know, the most of the engineering went into, how do we handle these events without making sure that commerce cart is installed, right? And if you try to listen to an event that doesn't exist, I'll help breaks loose.

Yeah, but again, like the bigger issue to me is, is who does it actually serve? And this is not a knock on ECA. It's the same. It was my same challenge with rules and I love rules. So we advanced rules quite a bit. We use it all throughout the Commerce 20 ecosystem. But it doesn't like it doesn't serve the end user, the merchant who has to go configure a promotion or pricing system or a shipping method availability. Like it doesn't serve them because they will be lost in that user interface. And it doesn't like, I think it can serve like a site builder developer or developer who just has a like simple requirements and would like a visual record in the back end of Drupal of what custom things might be firing. But, but like none of the developers on my team have ever asked for user interface to do that kind of thing. They would just write an event subscriber and write the code that they need. They would write a custom price resolver. They would write a custom order processor before they would ever reach for a UI based tool to do the same.

I think we, I think we have to get them to focus more on the ambitious site builder and what their needs might be.

Yeah, maybe. Yeah. And you're going to tell me that like, ECA can process these configurated configurated configured. What do they call them? Rule

sets? The BPM and I mean, they integrate the VPN. So you can, a lot of businesses will use that language to write out their logic. Yeah.

So like theoretically, the promotions module could produce those outputs. So we could actually keep our own user interface and then he's ECA for the actual processing of those rules, which would be interesting. You know, I'm open minded. Finally, like to go by one more thread, just, just so I don't miss it. If you wanted to give custom prices per rolls, you could have used the priceless module. So if you couldn't use the priceless module for some reason, you know, you may have had other ways to accomplish the same thing. That's all I was going to say. The promotions can support in commerce core, like a fixed percentage amount off based on the user's role. The price list module can support any kind of arbitrary pricing and then be configured per roll or per date or per region, whatever. There's a lot of ways you can filter that. So I will admit like the UI for managing the prices in the priceless may not have been ideal for what you needed. Well, that kind of

raises the other issue with the commerce ecosystem. It's kind of a sub problem of the Drupal ecosystem in general is you have to know about the module to use it. And I couldn't find it. So.

Yeah. Well, yeah, because if you're searching role based pricing, a price list doesn't sound like the thing that you need. So maybe we need to find a way in the actual UI of Drupal commerce to. Do you need more complex pricing than what you have here? Check these out. I feels like Project

browser could help with that.