Today we are talking about Drupal Commerce, What’s new in 3.x, and what’s next with guest Ryan Szrama. We’ll also cover Address as our module of the week.
Listen:
direct LinkTopics
- Commerce 3x Overview
- New Order Admin UI
- Kickstart Recipes Templates
- Faster Checkout Payments
- Canvas Components Strategy
- AI and B2B Prototyping
- AI Closing Commerce Gaps
- B2C vs B2B Focus
- Why Shopify Wins
- AI Liability and QA
- Future of Recipes
- AI for Merchants
- Search and Migrations
- Order Agent Assistants
- Smarter Promotions UX
- Commerce Roadmap Ahead
- Wrap Up and Contacts
Resources
- XNAL standard
- Commerce Kickstart
- Anyone can demo the latest version with all the great features discussed in this show, including focused checkout and the new order management interface, using the “Commerce Kickstart Demo” button at simplytest.me.
- Irish Times Case Study
- Commerce Operations Foundation
- Commerce AI Suite
- OneSentence App
Module of the Week
- Brief description:
- Have you ever wanted a purpose-built way to manage address information in Drupal? There’s a module for that.
- Module name/project name:
- Brief history
- How old: created in Feb 2015 by Bojan Živanović (bojanz), though the most recent release is by Jonathan Sacksick (jsacksick) of Centarro
- Versions available: 8.x-1.12 and 2.0.4, the latter of which works with Drupal 9.5, 10, and 11
- Maintainership
- Actively maintained
- Security coverage
- Test coverage
- Documentation - section in the Drupal Commerce documentation site
- Number of open issues: 120 open issues, 20 of which are bugs against the 2.x branch
- Usage stats:
- 108,288 sites
- Module features and usage
- With the Address module installed, you can add an address field to any fieldable entity and within that capture multiple data points, including street name and number, city or town, state or province, country, zip or postal code, and so on. It can also support a variety of additional data points like name or neighborhood, and within the field configuration you can set which data to capture, in which order they should appear, and so on.
- Under the hood the Address module uses a “commerceguys” addressing library that uses Google’s address data and the Unicode Common Locale Data Repository (CLDR) to provide a comprehensive database of international address formats and regional subdivisions for over 200 countries. By centralizing these global standards, it enables the module to automatically adjust form fields and validation rules to ensure users always provide accurate data in the correct local format
- Address can be combined with other modules like Geocoder and Geofield to implement a full system for converting and storing address data in a format that allows them to be plotted on a map. In fact, that combination is part of the Locations recipe (now compatible with Drupal CMS 2.0), which sets up all of that and the Leaflet module to give you a full mapping solution that doesn’t require any API keys
- The Address module and its predecessor Address Field were initially developed for address storage within Drupal Commerce, so this is another example of how the work on that ecosystem provides value to the Drupal community well beyond the sites that need to sell things
Nic: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 543, commerce three x. On today's show, we are talking about Drupal Commerce, what's new in three x? What's next? With our guest, Ryan Sharma. We'll also cover addresses on module of the week.
Brian has been involved in all things e-commerce and Drupal since 2005 when he started developing Uber Card. Today he heads up Sentara, the company behind Drupal Commerce, primarily functioning in a sales, marketing, and product ownership capacity. Brian, welcome to the show and thank you for joining us.
Ryan: Thanks. Glad to be here. Glad to still be here.
Nic: It's 21 years, man. It's been, I never thought I'd be doing the same thing 21 years ago. Wait some time.
John: I mean, that's a pretty good track record. You know, most people, most people don't stick with things for five minutes these days, so. That's right.
Nic: I need to grab Steve's bio. Gimme one second.
I'm Nic Laflin founder at nLightened Development and today my co-hosts are joining us for the next four weeks as our guest host Steve W. Tech Lead at Civic Actions. Steve started building Drupal websites for Syracuse University, then state tourism websites, and for the past dozen years, he has built Drupal applications for major agencies in the federal government, including the F-C-C-D-O-J, department of Education.
Veterans and most recently the Centers for Medicare and Medicaid Services, a builder of things from dral modules to wood metalwork that affinity for old tools, old ways in giving back. Welcome back to the show. Thanks for joining us, Steve.
Steve: Yeah, thanks for having me.
Nic: Also joining us as usual, John Zis, solution architect at eam.
John: Here I am. Hey, how's it going?
Nic: And now to talk about our module of the week, let's turn it over to Martin Anderson Klutz, a senior product marketing manager for Drupal at aa and a maintainer of a number of Drupal modules and recipes of his own. Martin, every time you get promoted, it takes us a couple of weeks to get used to saying your new title, but congratulations,
Martin: this one may take a while.
Yeah. Well, thanks you very much. Yeah, it's got a few more sos.
John: That's right.
Martin: It's nice.
Nic: What do you have
Martin: for Oh, thanks Nick. So have you ever wanted a purpose-built way to manage address information in Drupal? There's a module for that. It's called Address, and it was created in February of 2015 by Bogen Shivani.
Though the most recent release is by Jonathan Saxe both of Sun. It has an eight point x dash one 12 and 2.0 0.4 versions available. The latter of which works with Drupal 9.5, 10 and 11. It's actively maintained, has security and test coverage. And for documentation, there is actually a section in the Drupal Commerce documentation site.
It has 120 issues open, 20 of which are bugs against the two x branch, which is very good considering the, the site is officially in use by 108,288 sites according to drupal org. Now with the address module installed, you can add an address field to any fieldable entity and within that capture multiple data points including street name and numbers, city or town, state or province, country, zip, or postal code, and so on.
It can also support a variety of additional data. Data points like name or neighborhood, and within the field configuration, you can set which data to capture in which order they should appear and so on. Under the hood, the address module uses a Commerce Guys addressing library that uses Google's address data and the Unicode common locale data repository, CLDR, to provide a comprehensive database of international address formats and regional subdivisions for over 200 countries.
By centralizing these global standards, it enables the module to automatically adjust form fields and validation rules to ensure users always provide accurate data in the correct local format. Address can be combined with other modules like Geocoder and Geo Field to implement a full system for converting and storing address data in a format that allows them to be plotted on a map.
In fact, that combination is part of the locations recipe, which is now compatible with Triple CMS two. Which sets up all of that. And the leaflet module to give you a full mapping solution that doesn't require any API keys. The address module and its predecessor address field were initially developed for address storage within Drupal Commerce.
So this is another example of how the work on that ecosystem provides value to the Dral community, well beyond the sites that need to sell things. So let's go ahead and talk about address.
Ryan: Did you make that recipe, Martin?
Martin: I did.
Ryan: Nice.
Martin: I was actually related to the work that I had done as part of Starshot, so, okay.
Yeah.
Ryan: Cool.
Nic: So, I, I have to say, address Field is one of those ones where most people don't understand the underlying complexity of this. You think like, oh, you just need a line, city, a state, and a zip code. And they, and they don't realize that that doesn't even cover, like, you know. Speaking as an American,
Ryan: half the half the world's address.
Nic: But that doesn't even cover mailing to us locations.
Ryan: True. Yeah.
Nic: Because we have, you know, other things than states. Guam, part of our Yeah. That are part, well there's also military bases and things like that. So this is the kind of thing where just like having a library like that is so useful 'cause it just takes care of not just one country, but it takes care of most of the world and has, has a process for updating it.
I will say every time I use it, I forget what like locality and sub locality is and have to fill it out to look. I will also say that interacting with it programmatically. Is is pretty complex because mm-hmm. It's, again, it's one of those things where it's got a lot of hidden complexity.
Ryan: And it's, and it's all, I dunno if you know Nick, but it's based around the X and A L standard, the extensible name and address language.
And that was just something that I found back in the commerce one do X days because we, we, we, we had the address field before we had the address, and the question was, well, how do I determine which parts to include and which one's not to? And mercifully had the idea to say, well, surely someone solved this problem before.
And so a lot of the complexity and the naming of things is coming from that third party standard like administrative area instead of state province locality instead of city, et cetera. Yeah, it's,
Nic: it's the same kind of thing. Like, Jacob's new I guess it's not new anymore, it's been a couple years, but his newish project of schema org, right?
There's,
Ryan: right,
Nic: there's a, a. A lot of value in standardizing things and it's very difficult to standardize things. So if you can work with a, an existing organization that has already done a lot of the hard work
mm-hmm.
It's much easier for me to look at the form and remember what locality is versus sub locality than me to, you know, six months into a project, be like, Hmm, I didn't handle the case of neighborhood and sub locality.
Well
Ryan: right
Nic: now I need to write some install hooks to update everything. And guess what, now it doesn't work with anything else.
Ryan: Yeah, two other major things like getting Google to let us basically redistribute their data set from the Android. SDK was clutch. 'cause there's always that question of, well, what do I call the, what do I call the administrative areas?
You know, and what code do I use to to, to represent it in the dataset? And then the other thing was getting the locale specific. Formats. So in other words, a Chinese address, depending on if you're formatting it in Chinese versus English, that locale is gonna determine the sort order of fields when you print it out.
And that's, you know, one of those nuances that I wouldn't have known. And, and, and really we would've basically just ended up having edge cases upon edge cases, upon edge cases in our code if we didn't realize, wait, there's a standard that we can adhere to and we can just implement their patterns and blah, blah, blah.
So,
Nic: yeah,
John: it's interesting for me because I, like in my head, I think of I, I liken the address module to like dealing d handling a lot of the, the gotchas with addresses in various formats. Like, I, like in like Avalara handling taxes. Mm-hmm. Like you get a lot out of the box where you're, you don't have to necessarily put a lot of a lot of thought into some of the nuances that you get with the dresses.
You know, I, I think like I, if I'm, if I'm not mistaken, there's some, some zip code, a little bit of zip code validation going on there too, to make sure you're kind of putting the right, right zip code in the right state or country format or right format, all of that stuff. So like a lot of things where, you know, you, you know, as you said a lot, or maybe Nick said it, but like a lot of people go, oh, it's just an address, I'll just type my address in.
Right. But like, you know, filtering that, that that state or province list, administrative area, if you will to the right, you know, the right set for the, for the country that you're in and that sort of thing. Those, those things are, are definitely like, you know, they, they are brain benders, so
Nic: Yeah.
You, you, you also get like kind of magic integrations like Barton said in the, in the intro part with like leaflet or with geo field, things like that, because there's a, you know, it's one thing to have an external standard, but having this internal kind of Drupal.
Ecosystem standard means that everything else can integrate it with, with it too. And you get nicer. Everything plays nicely together.
John: Yeah,
Steve: I really, really liked it. Martin called out how, you know, building it for one thing made it available for everybody else. 'cause it's definitely, you know, I, I've lost count of the number of times I've used that module and I was kind of surprised at, at the, the use count on it.
I was like, wait, that's gotta be like half of my sites. There's gotta be way more people using it even than that because that, that, that count seems low.
Nic: I, I've even used it just to like, for clients that have, you know, the policy for it, like to just gather zip code, right? Which normally you'd be like, oh, it's just a number of people.
But like, even just that, it's like, well, what if later on they need more of an address or if they need to sort on it. Where like most people, again, in America, most people like, yeah, a zip code is just four or five digits. It's not, and then you also have to handle that every single thing under the sum be up
John: to nine digits
Nic: can be up to nine.
Well, yeah. Plus a hyphen and everything likes to truncate leading zeros. So this prevents that. So there, there's, yeah, there's a lot of value in having
John: def definitely the gold standard in collecting addresses in Drupal, I would say. Woo.
Martin: Yeah. And it's funny, you know, I, I guess to your point, Steve, one of the things I think about, or I guess the analogy I was thinking about is like, in the same way that like, you know, NASA's program to put people in space gave us Velcro, which is the thing that people use far more widely, like than many of us will ever get to space.
You know, I feel like address is a similar thing that, you know, we all got thanks to the work on things like Drupal commerce, but you know, as you say, it's so, almost ubiquitous in terms of where it's used in across Drupal.
John: Yeah, very true.
Nic: Awesome. Well thank you Martin as always. You found another on-topic module of the week.
If folks wanted to connect or suggest another module of the week, what's the best way for them to do that?
Martin: So, I am always happy to talk about candidates for module of the week in the talking Drupal channel of Drupal Slack. Or folks can reach out to me directly as man clue on all of the Drupal and social platforms.
But also shortly after this episode airs, I will be at Drupal Camp New Jersey. So if folks are gonna be in Princeton next week by all means hit me up and let's have a beverage.
Nic: Sounds good. Thank you, Martin. See you next week.
Martin: Thanks everyone.
Nic: Just as a quick aside, I can't believe we haven't done that module yet,
Ryan: the
Nic: time. Yeah, it's you know, address is here now because it's been covered as much.
John: It wasn't, it wasn't the a hundred thousand plus sites using it.
Nic: Okay. So Drupal Commerce, I still remember when two X came out and it was such a massive rewrite. So Commerce three X is kind of a, a, a major step forward.
What would you say the most important kind of architectural or developer experience improvements that people should look forward
to?
Ryan: Yeah, well, just, just to, to springboard off what you said at first, like the launch of two X was like a major leap forward, and I'm sure John can share some some stories from the trenches as he and I worked on a, a major early deployment of Commerce TwoX.
To an enterprise customer. For folks that don't know, I mean, essentially we had to rewrite everything, right? Because Drup, it was at the time of Drupal seven to Drupal eight. We had object oriented modules. We had to rewrite everything just for that alone. But we also had a new types data, API, we had service container to work with.
We had plugin systems to work with. We had the, the, the difference between content versus config entities to figure out and all kinds of stuff we had to figure out. And and so like that, that truly like, like that commerce one to commerce two leap was the last like, like, oh my goodness, this is really different kind of release we've had.
And then since then, every release has, has been pretty straightforward because of the way that Drupal changed its approach to versioning, to backwards compatibility, deprecation notices before removals, blah, blah blah. So like even the leap from two point x to three point x, while it actually does have a lot of significant new functionality today.
At first, it was primarily about Drupal major version compatibility, PHP, compatibility, et cetera, with a few minor improvements. And until today the most recent release commerce, well the most recent I think, is Commerce 3.3 0.3, but with the 3.3 0.0 release, we had a, a dramatic reinvention of the backend, the order management interface that kind of builds on work that we had begun in the previous three x releases to, to try to tidy up a lot of the order management and store management features.
So I, I'm happy to dig into any of that. But the, the, the, the big idea is just that how, how would I say it? The merchants and the customer service representative have not been an afterthought, but we didn't have the time and the focus to make holistic improvements. You know, so we, we could chomp at the edges, we could add a feature here, a feature.
They're like, oh, hey, let's, let's make sure that we can add admin comments to orders. Oh, hey, let's make sure we can now get them from a custom checkout payment. These are fairly recent features in the two. Okay. Late features in the two x side, but I mean now we've,
John: so three x, three X sounds like it was more of like a back office refresh.
Huge and enhancement for, for those folks that are managing orders and you know, as you just said, customer servicing orders as opposed to like maybe the more front end focused user, end user customer
Nic: yeah,
John: facing features, which. You know, I think it's great. I mean, I, I, I, you know, I remember, you know, creating some of those, some of those, you know, back office interactions and features with views and different stuff, and you know, you guys were, you were always very, very helpful and, and a great partner and, and helping kind of create some of those.
But, you know, very exciting to hear that you know, the back office is getting some love because I think often it's, it's like, oh, we have to focus more on the user. Yeah. But the user, the user is not the customer is the user, but also the, the back office staff is the user, right?
Ryan: Mm-hmm. Yeah. And man, one of the biggest problems that we had to solve for was the fact that in order.
A transaction, if you will remove it from the order Entity itself is actually a collection of data objects. In Dr. Wide. It's a collection of entities of varying types. This is true for Commerce one X as well. You always at least have the order entity, which provides the order metadata, but you have one or more order items, you have one or more customer profiles, payment methods, payments, shipments, and so on and so forth.
But the order management interface was still kind of built for two x was built around this idea that an entity has a view page and an edit page. And if I want to edit some aspect of an order, I click edit and then I can just go and edit things. But since so much of what makes up an order wasn't on the order entity, your edit page was only so useful.
Nic: Yeah.
Ryan: And you'd have to go to one tab to the shipments tab to create a shipment, add a shipment, then go back to the order edit tab to edit the billing address and click copy from shipping. And then if you didn't have all the ship, the order items on the order already, you'd have to then go edit the order, then go back to the shipments tab.
It was just circular. Yeah.
John: What are guys doing now? Is it just like windows hovering over the order PA page or?
Ryan: Exactly. Yeah. Yeah. So I, I, I put a video out of this on the blog that basically shows how the order view page is all there is now. There is no, there is no edit to tab anymore, although you can re-enable it if you need to in the order type settings because we know not everybody's ready to, to move.
But the view page now has a series of cards, the billing information card, the shipping information card, the order state card, workflow card and details card, the order items card, and then the order activity stream. That's all the components of the order view page. And there'll be little edit links that open up those modal dialogues to, to add or edit or delete the various bits of information from the order.
That's using the core dialogue, API it's great. So just boom, pulls up a link in a middle dialogue. We were able to reuse some components We'd shipped in previous versions of Commerce three dox, like the the new order items widget. We added in 3.2 to finally kill off our dependency on inline entity form.
That's a module that started within Drupal commerce and we've now completely kicked it to the curb. And and then we also paired that with some clever use of like the form modes. So there's, yes, there's still an order edit page, but there's a new form mode specifically for the order details modal.
So, you know, we were able to basically maintain backwards compatibility for all those folks that had customized their order management backend, but now ship these new form modes, new display, formatters new views to create the new experience for folks that either are building from scratch or just wanna update and opt into the new the new system.
Hmm.
John: So. I'm wondering we, we all know, you know, site templates are coming to Drupal, Drupal, CMS is out there. We have recipes all of these great features to kind of like get to a Drupal site faster. Right. And some of those Drupal sites are probably commerce sites, right? Hopefully. I'm wondering I'm wondering how commerce in general and specifically with Three, three X is kind of like embracing some of those concepts, site templates, Drupal CMS recipes.
Yeah.
Ryan: Yeah. Happy to speak to that. I'd say that like Commerce Core itself is, is kind of standalone. There's nothing in there specific to recipes or templates or what have you. But along with Commerce Core, we maintain. Various other projects as part of the Drupal commerce ecosystem, you know, and the first and foremost being commerce Kickstart, which historically was what was called a Drupal distribution, a sort of packaged version of Drupal with all these modules and themes, and then kind of in it maintained by it.
Mm-hmm. Now it's a site and, and it's like you actually launch a commerce kickstart store at the time and just keep updating your commerce kickstart to get all the latest changes in models. There are still Commerce Kickstart two x sites online today. I could find them right now.
Nic: Mm-hmm.
Ryan: The new Paradigm for Commerce Kickstart as of 5.0 launched at Drupal client Atlanta last year was to fully embrace site templates as a concept, recipes as a pattern for defining features, the the core patterns for default content creation.
And so that's what we did. We, we rebuilt everything around recipes with the commerce Kickstart site template, tying it all together. It also includes our. Default theme Belgrade.
Nic: Mm-hmm.
Ryan: Which which looks great outta the box. It's great for launching new stores. We actually just put together a sales demo for a customer in a matter of like two or three days, fully customized to their site and porting all their products.
Look great, function, great. Demoed great. I hope they love it. But it also, like you can use Belgrade just for the checkout theme. We're gonna, we're thinking about splitting this out eventually, but the idea is an existing site theoretically could use the commerce focused checkout recipe, and it would be responsible for installing and enabling the Belgrade theme and the theme switcher module configured only to switch to the Belgrade theme on checkout routes.
That's one way that recipes can kind of see existing merchants who may not be using Commerce Kickstart at all. Get new features as, as we add them to the ecosystem or to commerce Core or wherever. And there's a few other things that we have there and like, like the whole recipe, sort of sub ecosystem of Drupal commerce.
Yeah, there's like the base recipe for just getting Drupal commerce. There's a admin store admin recipe for like various store admin things. But then there's the commerce kickstart recipes, the full demo recipe, the recipe tracker module, which we saw as a gap in the recipe ecosystem to track which recipes were applied to your site when, because recipes are applied, not installed.
So after they've been applied, if you want a record of what was applied when you need this module. And then we also have a module that Jacob, forgive me I can't remember the name of it. I always have to ask him to remind me the name of it. But it basically removes the default content that ships with the recipe.
So like you can install the commerce kickstart demo, but then. Back out of it, the demo content with this module, whenever you wanna start building your store's content on it.
John: So you covered site templates, you covered recipes, triple CMS. Can you, can you install triple CMS as a commerce site right now? Or is that, would you, would you not?
Ryan: Not right now. Right. But that's next. Yeah. So
John: it's coming.
Ryan: Yeah, it's coming because we have been a part of the Drupal Association's initiative to kind of seed a new section of the Drupal marketplace with site templates.
John: Mm-hmm.
Ryan: And the, one of their goals for the site template marketplace is for those site templates to be based upon Drupal cms.
John: Got it.
Ryan: To be Canvas ready to to, to basically make use of that as the foundation instead of our own installation profile. The, the commerce kickstart install profile that be based off of the recipe installer kit. And so, so we, we will be using Drupal CMS for commerce recipes. You know, the, the, the hardest part about creating recipes for the commerce ecosystem is that that recipes by definition are devoid of context.
So like if, let's say that you have a Drupal site already
Nic: mm-hmm.
Ryan: With a product content type even. And what you want to do is actually just get add to cart buttons on that existing content type, but that, that kind of, it's impossible. Let's say that you already have a user role that you wanna build a product for, to sell.
Well, my recipe doesn't know that your user role exists. And there are things that you can do to, to add configuration steps and maybe point to existing configuration to try to tailor the application of a recipe to a site as it exists. But it's just hard. And then the more recipes you apply on top of things, that the fewer things are gonna work together.
Right. Which is actually why we even established the pattern of a. A an admin recipe to kind of define roles with certain names. So then future recipes could add permissions to a product manager role or a order manager role that already exists from this other recipe. So we, we can start to have recipes that can build on top of one another.
But there's just, there's just so much in the commerce ecosystem and man, I'd hate to just blow up somebody's site by having them install something on top of their brand new Drupal CMS site thing, and they're just gonna quickly add a store feature to it and then it looks terrible and they don't know how to integrate it and you can't back it out.
So, I, I think there's a lot that we need to figure out there still, or how, how to best expose all of this power to the Drupal CMS target audience. I dunno, dunno how folks are doing
Steve: it. You mentioned that, that the three X has been a, a heavy focus on the merchant experience but there's also been ongoing work around express checkout improved, you know, purchasing workflows That's true.
And that kind of thing. Mm-hmm. How is Commerce three X helping sites reduce friction and increase conversion rates?
Ryan: Yeah, well, I mean the, the biggest thing from a commerce core standpoint is just improving the payment API to support some of these more advanced and, and the checkout API as well.
More of these advanced payment methods that are coming on the market. I'd say some of the more recent ones would be PayPal, Fastlane, or Fast Lane by PayPal they call it, which is an express checkout experience that kind of takes over an existing checkout form, but it expects to interact with the checkout form in ways that we hadn't previously conceived of that form working.
Or, or other express checkout elements, whether it's PayPal express checkout or Stripe has the. The payment element, which you can embed into your checkout form, but it also has the express element, which you can embed anywhere to enable mobile wallet payment through Apple Pay, Google Pay, et cetera, link as well.
So we, we needed to better support these kinds of concepts with the front end and backend payment APIs and the checkout flow. So some of those things are in Commerce Core, but a lot of the new features live in these other modules in the ecosystem. So of course, the PayPal module itself had a new release to support Fastlane.
This Stripe module had a new release to support express checkout. The Belgrade theme had that new release to bring the whole focus to checkout feature set to the fore. And I, and I don't know exactly where some of the other improvements would be situated, but that a lot of what happens on the front end are typically in third party modules because.
Every, every, like the front end of every store is so unique that Commerce Core does need to like really have a handle on. You can build an add to cart form and you can use this sucker with layout builder to construct a crazy off the wall PDP. But, but we don't have a, a lot of the, the more rich features backed into the core itself, they're, they're in those ecosystem modules.
You know, wishlist is a good example, right? It's a, it's a separate module, not part of the core, because hey, not every site wants a wishlist, but those that do can install this module and it will attach itself to the add to cart form and show up in the layoffs, you know, as expected.
Nic: So speaking of.
New module in the Drupal ecosystem called Drupal Canvas. Not sure if you've heard about it that I think people will be very excited about for kind of building these custom landing pages for particularly mm-hmm. Special Pro product. When, when you're looking at a kind of new system in Drupal like Canvas, how do you kind of go about validating it and seeing how commerce is gonna interact with it?
Because again, commerce is one of those ecosystem level modules where mm-hmm people kind of expect various other things to interact with it well and expect commerce to interact well with other pieces. But ca canvas isn't simple. Yeah. So how do you go about kind of scoping that, evaluating that, and what does Commerce do with it right now?
Ryan: The, the first thing that I do from a, just a strategy standpoint is let the dust settle. Because we, we tried to follow a Canvas or experience builder, if anybody remembers that name when it was first being announced and developed, and we just couldn't keep up. And so we finally said, all right, let's wait until this is released.
And so now with Canvas 2.0 that has, or sorry, Drupal CMS 2.0 has canvas in it. And even this version of Canvas is only good for like landing pages. It's not applicable to other content entity types. I can't use Canvas today to, to create a product page because a product is its own type of content entity.
So there's still some more dust selling that needs to happen. However, we are beginning to use it, like even for our site template content preve that we're building for the the marketplace. It will, it will be a, a canvas enabled theme that supports. Essentially single directory components with cards and props and whatever else they can be placed into a canvas layout.
And we'll make sure that there's an embeddable click here to enter the checkout flow button from a canvas layout, but there won't be like a PVP powered by canvas at this point. Whereas
John: layout
Ryan: using product display page? Yeah,
John: product display.
Nic: Display,
John: got it.
Ryan: Product display page. Yeah.
John: Follow
Nic: up.
But, sorry, sorry.
John: Oh, go ahead. Go, go
Nic: ahead. Yeah, but, but you could create a canvas page and embed a product into it, right. From one of the new display modes. Right. But
Ryan: yeah, theoretically we could have like a, a product component that can be embedded on any, you know, landing page or what have you. Yeah.
John: Well, so I guess that's my, that's my question.
Like, have you, have, you and I, I mean you don't have to share top secret commerce secrets here unless you wanna, unless you wanna, of course. But like. Have you, you know, the world is going to a component based layout system, design system. Right? Have you thought, oh, you know, it would be cool is if we had, you know, commerce components where
Nic: Absolutely.
Yeah.
John: Where you could go to a, like a, a Canvas page and, and drop in like a, a add to cart button or drop in a you know, a, a pro, some sort of product card or something like that. Mm-hmm. Or drop, you know, drop in a, a, a cart preview. Have you thought, have you thought about that? Is that in the works?
Ryan: Absolutely. So, so one commerce kickstart already does include in it. So at this time, again, kickstart is built around layout builder,
John: right?
Ryan: So it has, components or block types blocks.
John: Right.
Ryan: Okay. That, that offer these essentially a component library for dral commerce to be embedded into layouts.
Nic: Mm-hmm.
Ryan: And and we know that we'll have to redo the same thing with Canvas to provide, you know, these single director components that are representing different parts of a product display page order, view page, other forms of other view modes of entities that are relevant for a commerce site.
But the, the, the pattern that we'll be following will be what we actually did with the Irish Times group's website, which you can read about in our case study on. I might just be on our website. I need to get an on drupal org still, I think. But, but essentially like we, we began engaging with the Irish Times Group back around the time, or just before Drupal Con Barcelona.
Nic: Hmm.
Ryan: And this is like when the Starshot roadmap was new, the target audience was new. And yet like that, that formalization of a Drupal product roadmap lemme take to the Irish Times marketing team because this was a joint sale to. CMO and the IT director to say, from an IT standpoint, we can do everything that your platform needs.
But from a marketing standpoint today, we can give you a component library based around Layout Builder tomorrow. You know, over time we'll be upgrading you to the experience builder at the time. Now Canvas that I just tell people essentially is gonna give you those same components you can use in the layout builder, but dropped into a Figma like interface directly in the back end of Drupal.
So, you know, there's obviously the question like, well what, what, what are the standard set of components we need to ship with things? I don't know that off the top of my head, but you could look, you know, you could go to one of these Irish time subscription pages and see the comp, the types of components we built for them, where we literally were embedding products into layouts and their product cards, product comparison cards, you know, this subscription versus that subscription, that kind of thing.
So I, I fully expect us to have that, you know, where it, where the code all sits is TBD. Sure. For stuff like canvas components, I, I imagine it's gonna be a standalone module just for the sake of more rapid release and iteration of the feature set. But at least in the meantime, you know, the, the first evidence of this will be in our content pre based site template, which will be based off public recipes.
So, on our recipes we tend to have both a, a recipe project and an assets module. So any sort of custom component would likely sit in the assets module that goes along with our content, pre recipes. And I, I keep using that term. Content Preva is a site template for Drupal that will essentially turn Drupal into a private or premium content sales portal.
So if you just have content that you wanna put a paywall in front of and it's kind of all you can eat, boom. You grab this, somebody pays, they get a license to a roll. That roll grants them access to view all the content on the website and done. That's the kind of thing that we can turn into a recipe and let people literally spin up in seconds.
And we have multiple such customers that run premium content library,
John: more walled gardens powered by Drupal, coming soon to a, to a hosting provider near you. Oh boy. Here we go. We're gonna jump into the the topic du jour of the, of the last, you know, I don't know, year, two years, three years we're seeing AI like drop into commerce all over the place. We're seeing people shopping with AI and asking, asking, you know, chat g PT to find 'em the best deal on something, buy, you know, 25 rolls of toilet paper, whatever.
Well, they're using the AI for commerce purposes. I'm wondering from your standpoint, as, as as the com, the Drupal commerce guy what are the most exciting AI use cases that you see coming to Drupal Commerce?
Ryan: Yeah. Well, yeah, for, for folks that aren't familiar the different AI companies are basically putting out their, their various commerce protocols, ATech commerce Protocol, universal Commerce Protocol, et cetera.
And there's even a, a kind of I dunno if it's strictly open source, but, but a, a group that recently launched, spearheaded by Ben Marks formerly of Magento and Shop where called the Commerce Operations Foundation. That's really gonna to try to start standardizing on messaging and balance and helping people get integrated with this sort of next horizon for e-commerce through commerce protocols and MCPS and who knows what else.
Okay. That aside, I have a hard time developing for them because you have to be a merchant. I'm not a merchant. I'm a platform developer, and because I'm not named, you know, Toby Luki with Shopify or whoever it is that runs BigCommerce or these other major platforms, you know, I'm not out there getting invitations to, to be one of their launch partners.
We, we've definitely reached out to, through all the contact forms to try to work with our merchants to find, you know, an opportunity to play around with these protocols. As of today, you know, you basically would just have to make sure that you have the metatag module installed and good configuration to make sure that these bots can scrape your product dataset.
Not that hard to do using Meditech Simple, what is it? Simple. Simple site map, site map, XL site map, whatever it, you know, that
Nic: one,
Ryan: you, you make sure that you're, you're covering the bases and the LLMs are gonna find you. And then also maybe use CloudFlare to block Hong Kong unless you're selling in those regions, unless you want your site, your site to be called to hell by these LMS that don't care about your robots T xt.
That said, the most exciting thing to me for AI to date was seeing my, my project managers turn into prototypers. And here's what I mean by that. Now most of our customers have at least some form of B2B involved in them. In other words, very few of our customers are solely B2C.
Nic: Mm-hmm.
Ryan: And, and there's a, there's a good reason for that.
Like B2C or direct consumer commerce is pretty well solved by SaaS platforms. And if you can use them, you probably should. Unless you have a compelling reason, whether it's, you know, ideological regulation what have internationalization like there, there, there are areas where we still beat them even for D two C but they, they do not, there there is no standard feature set to for B2B in the same way that there really is for direct to consumer eCommerce.
John: And that's business to business.
Ryan: Yes. Business to business. Because, because basically, like as, as suppliers, wholesalers, manufacturers, resellers, as they digitize their business to business sales process, you know what, what they are digitizing is decades worth of relat. And, and they can't go to their 20 year long customer and say, Hey, we want you to deal with us in a new way.
Now they have to digitize every nuance of these old legacy processes. Now they can make them better. Like obviously digital data entry is better than fax to order purchase orders self-service data entries better than you must call your sales representative to place an order. Auto replenishment is much better than, you know, the secretary has to remember to call in every once in a while.
So there, there's obvious improvements, but you can't just jet, you can't just jettison everything that makes that B2B process unique. And so, so you, you want to, to to cater to the business and their customers, their business customers, to, to deploy a lot of these like little bespoke features, quality of life features, and so on.
And so, a, a great example is we recently rebuilt a customer site on top of Commerce Kickstart. They have two sites, actually. Same code base, different data sets, different themes, et cetera. And. They just wanted to be, they have a pretty big data set. It's, it's car parts, right? Pretty, pretty robust data set.
And they wanted a way to spot check everything at once, fill in the gaps, and then re-upload the changes. And so, of course, you know, a Drupal person will think, ah, okay, I need to export the product data sets, and then I need to import it. So I'm gonna create a view with views, data source, and now, you know, get it exported to CSV, then I'll reimport it using feeds and hopefully everything will just work great.
But it would, it would take quite some time to configure and get right, and also to make sure it's performance. Because if you're uploading, you know, a 20,000 row spreadsheet, you can't just host the, the server with that single upload.
Nic: Hmm.
Ryan: And so what my project manager on this project did was he, he basically just, he formalized the requirements with the customer.
He went to Claude and he said, Hey Claude, I need you to do this. And, and I think he spent maybe two hours, like it was the time the, the time was like I left to go to dinner, and then I was putting my kids to bed and he sent me a prototype. And he's not, he's not a Drupal developer. He, but he's, he's good enough to run Drupal locally so he could test quads output.
He could tell it when things were wrong and ask it to fix things, but he couldn't review its code to know if it was doing the right thing or not. But he could see the results by reinstalling commerce, kickstart, reinstalling the CSV sync module and running it to see if it worked. And then he when he realized, actually, this seems like it's doing the job, he handed it off to the senior dev on the project.
The dev was able to review it, qa it, we could deploy it. And then the customer has this new feature that's pretty specific to their workflow for data cleaning and data updates. And it was a four hour ordeal. There, there was no week long sprint, you know, design, build conception, qa, staging, deployment, blah, blah, blah.
And I just thought, man, like how, how awesome would it be? If every project manager on my team, when they heard a customer's requirement, didn't just have to play stenographer and then go get in a separate meeting with a developer who then has to think out loud about how to build it, who then has to go back to the customer to validate the, yeah, like, like we, we shortcutted a lot of the, the development process here using Claude and and the customer's super happy.
And, and the thing is, if, if we, if you can't ship these little features fast, I think the customer's gonna leave you. They, they will go elsewhere because other people are, even people who don't know how to use it, are using it and they will use it poorly and they will shoot your customer in the foot. The customer may not know it, and that developer may not know it.
They're, they're all operating in good faith. We, as the experts also have to be adopting these things to accelerate our workflows because there, there will be a time where they just won't put up with, well, we can get that in the next sprint. And so three weeks from the day you can have your CSV sync module.
So I'm excited about that potential and we're, we are going to basically dog food it, but we, we have used Claude again to show us the gaps in our business to business feature set relative to Adobe Commerce Cloud, BigCommerce, and Shopify, and maybe hybrids, Demandware. And we're gonna start closing those gaps, and we're going to let Claude take the first swing, and then we will whip it into shape to, to, to put it into an actual, you know, project on Drupal for pub, you know, public consumption.
My, my first target was a quick order module a feature that we actually have implemented for B2B sites in the past where essentially it's just a single page where I can put in a sku, in a quantity, hit next sku, quantity, next skew, quant, or click. Upload a CSV of SKUs and quantities to basically build a cart in one form.
Submission, boom, cla one shot at it. Next up, I'm gonna look into QuickBooks integration as well, because we, we, we really need a standardized QuickBooks online integration module. We don't have one right now. We've done it, but hey, like, let, like how quickly, basically I wanna ask my team, how quickly can we close gaps?
If you have an afternoon, you don't have a week, you have an afternoon, can you begin to close gaps, you know, using AI as your assistant? So I,
Nic: I, I have two questions about this because we just, the show we released yesterday was like you know, what is AI and how are we using it? And like pros and cons.
Mm-hmm.
I, I have two separate lines of thought and one is you're, you're obviously focusing on B2B. You just gave us the reasons why, but I think there's one, one huge counterpoint, which is that there's many, many, many, many more B2C customers and many more small one. I mean, they, they're the bread and butter.
I mean, yeah, there's, there's a, there's whales and Shopify that make them a lot of money. I'm sure they make a ton of money on just people that sell one or two products a month and having kids with $30 a month.
Yeah.
Plan either. Right. So is, is there a way that you close these gaps for the B2C customer where you can literally just have a one click install ad five product?
Like I, I've built commerce sites. It's a significant undertaking.
Mm-hmm.
For like, if you're not a mid-size business, it's almost not worth it. Yeah. But if you could get a recipe configuration feature set where it's like, hey, you click this button, you could add some pictures, say that you wanna accept payments from PayPal, you're good to go.
Yeah,
Ryan: I would say two things, mark. One, I think that like Commerce Kickstart already does provide that. I mean, essentially out of the box, you're getting a basic Shopify site with Commerce Kickstart today. Full promotions interface, coupons, interface, product management dashboards, some preconfigured product types, focus, checkout flow, blah, blah, blah.
Like I think we even actually have like the PayPal module there. See leaders just go enable the PayPal module and start selling with commerce Kickstart like in 30 minutes. However you're right, I mean, you get outside of that box at all. And, and you have to know a lot about Drupal administration to be able to put together a store.
The, the, the problem really is the, the funding. And I, and I know that there's a, there's a significant push in Drupal to not essentially like abandoned the bottom of the market. And I, and I respect it and I applaud it. And I, and I, and we have, we, we, we spent a lot of money on commerce kickstart.
To address that need. But we also have to look for, you know, the, the funding that's gonna provide for Commerce 4.0 and 5.0.
Nic: Yeah.
Ryan: And so business customers are just more capable and willing to spend on that. And, and so that's, that's why that's our focus. That said, I mean, I'm working with a major direct to consumer brand right now.
Can't name 'em, but it's a quarter million dollar build. Obviously we have other direct to consumer brands in our, in our client roster. Johnson Outdoors has been a long major customer of ours. Really solid Drupal users. Of course, the Irish Times group is Yeah. You know, B2C as well. So, so we, we are a mix.
But I think, I think what most people dunno about Shopify is that, that Shopify is an e-commerce platform and they do make money from subscription fees. But first and foremost, if you look at their SEC filings, Shopify is a financial services company. Shopify makes a crap ton of money, not on subscription fees, but on credit card transaction fees.
That's why shop pay is so central to their platform. That's also why if you're a merchant on Shopify, you don't own your customer relationship. Shopify will very gladly sell your customers, your competitor's products. 'cause all Shopify cares about is, is gross conversion counts, not your customer loyalty.
Nic: I mean, they're more, they're more, they're trying to be visa more than anything else.
Ryan: Yeah.
Nic: But,
Ryan: yep. And so, so that, that affords them though, I mean, that, that, that hundreds of millions of dollars affords them to push forward on how can I get a D two C brand to launch faster? How can I get a small site to launch faster, faster, faster, cheaper?
And we, we frankly just don't have the hundreds of millions of dollars, you know, to, to invest in the, the kinds of product research, product design, implementation that would require to. Essentially make it simple. I like make, making stuff really simple is actually really expensive. And, and abs absent in their scale.
It's a, it's a chicken egg problem. I mean, if, if I could find 10,000 small merchants tomorrow that were ready to move to Drupal Commerce, if I could just prove to them that they could launch a store in hours, of course I'd have the incentive right there to do it. But when I look at the usage counts of Drupal as a platform and see that there, there are not tens of thousands of Drupal sites launching each year right now.
Well, where am I gonna find, you know, if, if only 5% of Drupal sites are e-commerce websites, and where am I gonna find tens of thousands of merchants by aiming at the low end? I kind of have to aim up market in order to feed my team.
Nic: Yeah, I mean, it, it it, like you said, it's a catch point too. I, you, you almost have to market it not as Drupal, just as that competitor to Shopify.
Yeah. Might be a SaaS service. But I, yeah. The other side of my question then is this is something that people have answered in various ways, right? There's. There's kind of an, which is if you're building these tools using ai, how do you how do you think about it in terms of liability, right? Like if your, if your team wrote that migration themselves and there's a mistake, well, you're liable it, your team wrote it using Claude and there was a mistake, you are still liable.
Mm-hmm.
Right. So how, how do you how do you come to terms with accepting liability for something that you're, you're using a tool to write it. You're not you know, it, it's not a, well, I guess you trust the people that are using the tool, but do you just put more emphasis on testing? Do you put more emphasis on, like, how, how are you thinking about that as a business owner?
About
Ryan: what I'd say about. Ai, you know, or, or as I would typically call it, so-called ai, but I don't wanna be a horrible pedantic you know, annoying person, but so-called ai. It is a predictive text generation tool, much like Dush DR. Scaffolding used to be for us in the Drupal community, much like IDE auto completion used to be.
Nic: That's, I mean, that's not a,
Ryan: it's a bit simplistic, but
Nic: Yeah. But
Ryan: essentially
Nic: templates, but
Ryan: yeah. Yeah. It's, but, but talking about it from a liability standpoint, yeah. I think it's, the concept's the same. If somebody rolled a new release of DR and broke a template and then you shipped that to your customer and you brought down their store for two hours because you didn't catch it before going live, well, your liability's the same as if you'd handwritten that bug.
And it's the same as if Claude had written that bug. And that's why. WW
Nic: with a huge difference in scale, I think in general. So like, are, are you,
Ryan: yeah, sure. You can shoot yourself in the foot a lot faster nowadays, I suppose. Yeah. Or in a lot many different ways. Yeah.
Nic: Yeah. So, so do
Ryan: you,
Nic: do you have thoughts about that?
Ryan: Yeah, so, so as a business owner, whether you're a freelancer or a service provider like Centara, massive agency, you should have errors and emissions insurance, right? General liability, policy errors and emissions policy that covers, you know, defects and work product you produce for somebody. If push comes to shove, you're covered.
And then you also should have a limitation on liability in, in your, your master services agreement with all of your customers. That's scopes how much they're allowed to sue you for, in most cases, that's typically scoped to the the amount of money represented by any given statement of work. So you're protecting yourself the same way you've always protected yourself, whether a human wrote a bug or a machine wrote a bug with insurance, and then with.
Policies and processes internally, or SOPs that make sure as few bugs get shipped to production as possible. So going back to my example of shipping that CSV sync feature to our customer
Nic: mm-hmm.
Ryan: I said our project manager turned into a prototype, but before it ever went live, a senior engineer reviewed it and QA it to make sure that we weren't shipping something that would bring down a site.
I, I, I don't think you can get away from that step. I, I would never, not today, at least, I, I would never ship even the smallest patch produced by any AI without having a senior developer review it. And, and I, I honestly think that my opinion on that will change eventually, but right now I, I just, I, I wouldn't, I wouldn't do it.
Also right now, I mean, the, the code that we write still has to be maintained by and and viewed by other humans. The whole world isn't using AI yet to produce code. Therefore, I need to make sure that my code is legible, understandable to reviewable by humans. But there, I, I could see a day when the Drupal module developer doesn't exist anymore because the code just by machines.
Right.
Nic: Whoa.
Ryan: I'm sure that's not controversial, but but you think like, like essentially even, even recipes as a concept won't exist in five years because what is a recipe? A recipe is one person's idea of how Drupal should be configured to solve a use case. What's an AI gonna be doing in five years?
John: I mean, won't a recipe just be a prompt for an AI to go through?
Ryan: Exactly, exactly. That's exactly my point. Yeah. It'll be a prompt, it'll be a certain way to prompt AI with certain context files that ensure that the output is what works good within our system. And
Steve: the AI fits in the system. Like that's, that's the thing that
Ryan: Yeah.
Steve: Is missing from recipes right now. Rest, like you were saying earlier, a recipe can only be applied to something that's a known sort of starting point.
Ryan: Yeah.
Steve: Where ai, I mean
John: maybe,
Steve: basically, basically generate the mean,
John: maybe AI is the system, right?
Ryan: Yeah. You think let you like, like so much of what we do is Drupal developers and so much of what we script in our commit hooks and pre-deployment hooks and everything, it's automated testing, it's code linting, it's standards enforcement.
Why? So that the code can be easily read and maintained by other humans. We follow certain forms of code generation because we want make sure that the best practices we've created to ensure security aren't violated. What if a human being is not maintaining the code anymore, who cares what it looks like?
Who cares if it works with the other 20 modules in the Drupal commerce ecosystem? Oh, I detected an incompatibility here. Lemme rewrite that feature for you, blah, blah, blah. Now it's deployed like, like eventually every Drupal site will will literally be bespoke and maintained by, in AI that you want like
Nic: pounds terrible in so many respects.
Ryan: Yeah,
Nic: I mean, yeah. I mean, yeah, there's that. I don't see how that is sus, I mean, this isn't last week's episode, so let's not get sidetracked.
Ryan: Sure, yeah. I don't look forward to this piece, by the way. I'm just trying to look where the ball like Yeah. And where it's heading. And like I said, I'm, I may wait and let the dust settle guy until Opus 4.5, 4.6.
I wasn't even interested in playing with it. But as of that kind of feel like you gotta be playing with it at least.
Steve: Scale back the focus
Nic: from as last,
Steve: I was gonna say, as we scale back, the focus from AI changing all our jobs for the next, you know, in the next short term
Ryan: plan
Steve: to we scale the AI give back to like, you know, commerce, AI suite introduce to things to like personalized product recommendations and AI powered search.
How do you see AI changing the way merchant manage their stores within Drupal covers?
Ryan: Yeah. The three things that I'm really excited about applying AI to, and I have not had a chance to do so myself, are the one that you just mentioned. AI boosted search, I think is clutch. I think we gotta have it. And I think that that what that that lets you do is just pair freeform, you know, language generation and, and therefore like, like.
Searching with structured result sets. So I can say, Hey, like I'm, I'm about to go on a camping trip and I only have so much room in my backpack. You know, what's, what's a good option for me to take from this Jet boil catalog? And the search results? Say, Hey, grab this. And oh, by the way, have you considered grabbing this and this?
And so you're going in August, it's gonna be a little chilly at, at the evening. I have a great sleeping bag for you. I, I think that's cool. I also really want to see ai facilitate data migration because data migration just sucks, man. Like every one of our projects, like I feel like we keep.
Allocating a higher and higher percentage of the project budget for data migration, and it's never enough.
John: When you say data migration, you mean like product data from one system to
Ryan: product data migration from legacy systems, customer data migration, CRM data, whatever it is, at the very least, the product to product.
You know, I'm, I'm coming from system X, I need to get into system Y. How do I adapt my data a or how do I prepare this, the destination data architecture, and then map the source data to it?
Nic: Mm-hmm.
Ryan: To be able to launch without it requiring an eight week exercise from some very frustrated developer beating his head against the wall.
Nic: That's my favorite part of migrations, right? Is beating my head ball. I mean, I, I'll say, say great print.
Ryan: Yeah.
Nic: I'll say I've learned a lot about, there's one thing I, there's one piece that I feel like we missed there, right? There's a lot of pain and suffering. Like I've, I've done straight HTML migrations before.
If you want a exercise in misery, pain and suffering, I recommend that you try to migrate straight HTML to Drupal. It, but one of the pieces of value that I'm not sure how we maintain this in this type of world though, is like when you do that, you understand the data intimately.
Mm-hmm.
You understand the edge cases, how it's being used, how it was used in the past, and you can have those architectural discussions like no matter what project I work on, you, you do your best to art, you know, write the content architecture before you even start the migration.
You always find edge cases in the migration. Yeah. And I, I just don't see, like, one of the things about AI writing is they, they do. They do something that juniors do. They either ignore it or they find a way to make it work, which is usually not the right answer. Usually the right answer is like, step back
Ryan: ref might be required.
Yeah.
Nic: Yeah. Well, well, how do you identify those issues?
Ryan: Mm-hmm.
Nic: Or those places?
Ryan: Yeah, and I, I don't, I don't know what that looks like yet. I, yep. The closest process I can think of is I, I have a friend who recently launched one sentence. It's at https slash one sentence app. And this is a completely coded macros app from a guy who knows Zero Swift.
And what it does is it facilitates local dictation to an l lm just for, for voice capture, voice transcription. And what he does is he actually, he just talks to clock no, he was talking to Gemini. He talks to Gemini and he he basically says, Hey, Gemini, tell me how you might do this. He says, cool, I think I do it this way.
And he says, okay, well I hear what you're saying, but let, let's just look through what you produced together. And it's a markdown file. And he just sits there and interacts with it and, and using his voice. He is, he is refining the requirements set and then letting it go to town on producing a, a, a patch.
He can review the patch in sofar as able to understand it. He can have it build, he can test it, and then he can deploy a new release of this app. And what, what he revealed to me was this idea that you can, you can converse with the model. And iterate your way toward the same kind of refinement that, that you as a developer could converse with the, the the data set and make notes in a little text file.
He has it writing full on markdown files for him, keeping live updates to the data architecture. You know, here's the full, you know, documentation set for the domain, the, the decisions we've made together. It, it was quite bizarre, honestly. Like he had a whole dev team,
Nic: you
Ryan: scripted here, and then he produced a professional.
You're the second,
Nic: you're the second person a week. That told me that they used AI to generate a speech to text.
Ryan: Yeah. It's an obvious yeah. Obvious thing.
Nic: So,
Ryan: but yeah, it's, it's cool. But the, the, the third thing that I'm excited about for ai, and we actually had this in our, in our order management overhaul design documents, we just haven't implemented it yet, is, is like an order agent.
So specifically for customer service representatives, when I'm viewing an order page. And I just want to use natural language to tell Drupal what needs to happen to an order. I go, Hey, I need to refund this customer $5. I'd like to give this guy a $10 discount off his next order because his order got there late.
Something more complex. I'd like to extend this person's subscription by 90 days because we kind of gave bad service. And that requires, you know, updating a draft recurring order, a subscription entity, maybe even changing a billing, like, you know, so basically a chat bot that is confident enough with the, you know, the way that Drupal commerce models work to actually manage orders.
I think that'd be awesome. And, and there's obviously a, a natural next step of that would then be to have the same thing, answer customer service questions to a customer on the front end.
Nic: I mean, but you're, you're, you're back to the, the difference here though I think is you are, you are building.
You're, you're doing kind of what the Drupal community in general is looking towards. You're building tooling around tools. I think there's a tools API module. You're building tools that say like, here's how you refund something. Here's how you do this. So you still have the internal Drupal plumbing to interact with the the order entities.
And then you're using the, the AI at that point, or the LLM really isn't providing much beyond understanding the intent, which is what LMS their superpower is language processing. So you're not using AI
Ryan: processing is the user interface. Yeah,
Nic: exactly. And I mean, setting aside a lot of the other issues that come with ai, that, that feels like something that is, is useful.
'cause you're, you're using the, like that's what LMS are made for, right? All this other stuff that we're using for is like kind of like looking for a problem to fit the solution or something.
Ryan: Hmm.
Nic: Yeah. You can still put guardrails on there. 'cause if you're using tools rather than just like direct AI interface, right?
The tool, the tool tries to, if you set up a tool to like throw an error, if somebody tries to refund more than the order was, or like, you can still set those guardrails.
Ryan: Sure, yeah. And you can follow the Drupal principle of human in the loop. Like, you know, in other words, I wouldn't just immediately update something, I'd say, cool.
Like, here's, here's what we're gonna do for you. Does this all sound right? Yes. Make it so you know, which, which is the, the, the Drupal philosophy that, that that you, you shouldn't be especially taking destructive actions without a human explicitly authorizing that
John: or you even, or, or you even take it a step further.
Right? And I was actually just looking the other day at Marcus's demo. Posted Marcus's demo of what is it? Twilio? Twilio. So basically a, a voice interaction with Drupal. And you kind of take your, your example, Ryan, of like, you know, somebody maybe calling customer service and saying, oh, I had a bad, a bad interaction.
And, you know, the, the bot going, okay, well we're sorry to hear that. We're gonna we're gonna request a, you know, a $10 credit for you. And then like, you know, you come in in the morning and you see, oh, hey, here's my, here's my list of $10 credits that we gave out. All right? Yep. Those look good. This one not so much.
Okay. You know, do it right. I mean, I think like that. That type of, that type of assistance, that type of interaction makes a lot of sense. And you know, I, I do, I do necessarily, I do tend to agree with the, the human in the loop aspect of it, but I mean, I think there are a lot of these more customer service focused tasks that, that AI can be, can be really,
Ryan: mm-hmm.
John: Really helpful with. And, you know, AI's always pleasing. Nature kind of lends itself to that. Because, because, you know, we've
Ryan: all, sorry, I hear you had a bad experience. Sc g we've
John: Oh, right, right. But we've all, we've all probably experienced a customer service agent that's just, you know, dealt with one too many customers that day and they're just kind of grumpy.
Right. Like you, I, I don't know, maybe you never, you never get there with ai.
Nic: Alright, so if we're. Looking at a different aspect of kind of the commerce pipeline, which is like promotions or helping people find stuff. Do you see other ways of kind of improving how commerce presents these tools to both end users and the kind of site administrators or store administrators?
Ryan: Yeah, I mean, you're, you're kind of hinting at the concept of merchandising.
So how do I, how do I present a product in a certain light to convince somebody to buy it? Merchandising would be like going into the Hallmark store and in July they put out all of the unsold ornaments from last year in order to to move that merchandise before releasing the new you know, ornaments at the end of the special sale.
Right. It's. It, it's, it's a physical activity that has a digital equivalent in terms of how do I present my products on a listing page? How do I prioritize items and search interface, or how do I surface active promotions on the site? And so I've actually in the context of a client engagement, recently been thinking of ways to make that better because promotions are a fieldable entity within the backend.
And, and they have certain fields, a name and a description that can be reutilized throughout the Drupal interface. So for this particular customer, we're actually using a promotion to, to contain the metadata for a sale that then gets included in blocks and other parts of the user interface. But I also had had the the realization that for them you know, moving faster toward more custom offer types makes sense.
And what I mean by that is this they wanted to have a referral program. So anybody who refers a new paying customer gets a credit themselves. And on the one hand, like the affiliate models are well worn but they, they wanted the person who's being referred to also get some special benefit.
So words like refer a friend, they get $5 off and you get $5 a store credit for your next purchase. So the, the way that we ended up implementing that was via a coupon code as referral code and then a custom offer type that gave them the discount and then also once the order was placed, you know, granted the the referring customer that credits that they were entitled to.
So I think, I think there's some interesting stuff that we can do with additional offer types. And right now the promotion system and Commerce Core just offers either fixed or percentage based discounts off of particular products, variations or shipping methods. Then we also include the buy X get y you know, offer type for like a BOGO style deal.
Nic: Yeah.
Ryan: But curious to see whether. Kind of promotions we might be able to include, or even simplification to the interface, you know, to make it easier to spin up a coupon code as that
Nic: Yeah.
Ryan: That token to keep a customer happy, you know, if, if something like
Nic: that. Yeah. I, I remember the client that I most recently built commerce platform for, there was a I ended up, there's like a conditional promotional module I think that I had to use and it gave a lot of power.
But one of the problems I think in general with this space is how to, how, how to make building out the rules for these promotions match what, what people are expecting. And what, what I mean by that is
as developers we're used to thinking like, oh, I need this and then negate that and then that other thing. Where, and then like seeing like overlapping promotions to find out exactly how one is applied. You can do that, but as a store administrator, many times they don't think through that. So like you might want, like they very often would get a shipping promotion in a situation they weren't expecting because they fought, got to exclude a certain role, or like taxes, you,
Ryan: you included taxes in the total order amount and so you gave free shipping before you meant to, because it's supposed to be excluding tax or whatever.
Yeah,
Nic: yeah. The, the amount of like even just reporting and figuring out the adjustment, like I, yeah, I remember having a long discussion in the commerce channel about, you know, free adjustment versus post adjustment. But anyway. Yeah. I, I wonder if there's ways to present these things in a way that it just makes it clear, like these ones are overlapping, these ones are not.
Ryan: Yeah,
Nic: these ones are, but I mean, it's a,
Ryan: yeah, I'd I say like that, that to me is another great use case for applying an LLM to configuration task. I, I, I tend to think that. No matter how simple we make the user interface, and it's not simple today, although we've tried to simplify it, I still don't think it's simple.
It's always gonna be too complex for probably the typical store manager. 'Cause most people don't think like developers and script kitties and whatever, you know, used to logical statements and logical grouping and operators and so on. You know, within Commerce Core, and I think people generally understand this, but maybe don't realize Commerce One fully adopted rules for all things price and promotion related.
But we had such a hard time getting people to understand how to use rules that we just did away with it entirely for Commerce Two and Rules also wasn't ready. So we actually shipped our own inline conditions system. Yeah. To, to make conditional availability or applicability of pricing rules, payment methods, shipping methods, et cetera, possible out of the box.
And now we've come full circle with ECA sort of taking the, the crown from rules, the people wanting to use ECA to do those sorts of things as well. And, and once again, I just have to think like the average business customer is not using ECA now. I like the power that ECA gives, but the user interface for the business customer should be natural language processing.
It should not be a flow chart diagram, and it shouldn't be dragging and dropping things. And it shouldn't be six different select lists. You know, like, like it, like that's where this needs to go. In the meantime, the best we can do is, is try to make simple condition plugins available and make sure that all the, the logical operators are getting because you, you know, you can, once upon a time people wanted to add a, a blanket negate option to our conditions and it's like, nah, that's, that's not gonna work.
Like what does negate mean to the non-developer?
John: I struggling to negate so much. It was like,
Ryan: it really just means negative. Like this gives me bad, this
John: brutal negate, and I'm like. It?
Ryan: Yeah,
John: maybe. Yes.
Ryan: Yeah.
John: I,
Ryan: and so what, what I, what I've said is like, hey, we just need to have smarter operators. So if, if the condition is, is, you know, product categories, then there's an operator that says one of these categories or none of these categories, and it, and it is functionally a negate, but it means something to a non-technical user.
You know, if it's, if it's a price comparison, well you don't need negate, you just need to make sure that you have both greater than and less than signs available, you know, to the, to the conditions set.
John: It's way, way easier to just type into the Drupal AI chat. Like, Hey, create me a promotion.
Ryan: Yeah.
John: Where you know, this person gets $10 off if it's Friday and they're wearing a red shirt.
Ryan: Yeah. On mobile only. Yeah,
John: on mobile only.
Ryan: Yeah.
John: There you go.
Ryan: And there, there's, I think there's, there's still more that we need to bring to the table in terms of context. Like actually user agent would be a nice thing to have in our conditions set.
And thinking about the context of an order but also, compatibility needs to be expanded. We actually had more compatibility options in commerce. One with the commerce discount module right now you can say that a promotion is compatible with other promotions or it's not, and you can sort them relative.
So the first one to apply that says it's not compatible with any others, then negates the application of any subsequent promotions. Have to be able to have, it
John: always drives me nuts. I want all the promotions.
Ryan: Yeah. And we used to, we used to have basically like direct compatibility chain chains said this one is not compatible with this one, but it is compatible with anything else.
So we used to, you know, we used to have more options. So we, I, I'd say we need to expand that. So support still in commerce Core expand our, our condition set and and yeah, you know, to your point Nick, like trying to, trying to surface to the customer like how to, how to diagnose it. We may just need an audit log similar to the, the recipe tracker that I mentioned.
That's like, okay, go and place an order, then go look in the audit log and we'll record for, you know, record for exactly which promotions were applied to an order and what in what order. That would be interesting.
John: So, so Ryan, we got like two a time for a two minute answer here. I'm just curious what the future roadmap looks like for commerce.
Like what are the big, the big exciting things site builders emergents should be looking for and, you know, future versions?
Ryan: Yeah. I already kind of alluded to it with with two things. One, our, our B2B feature set
John: mm-hmm.
Ryan: Is the next major initiative of our team. So order management interface overhaul was the begging.
Next up will be this, this B2B feature set. So that would be things like expanding priceless usage, reordering, you know, faster ordering, ordering improvements to the invoice and purchase order ecosystems that we have, modules that are just okay.
Nic: Mm-hmm.
Ryan: Probably improved reporting and analytics as well.
You know, there are things that right now we use third party tools that we theoretically could use Commerce Court itself for.
Nic: Mm-hmm.
Ryan: For example, you know, on an inbound order, I could retain the query parameters from the UTM, you know, configuration, these, these campaign query parameters, stuff it in the order object and give you that information in the Drupal dashboard without killing you on full web analytics tracking.
So there's more that, that we could be doing there to support these business customers and business use cases. But the other thing really is Canvas support. I think a lot of people are gonna be very happy with Canvas. I think that, that we, we actually just came, I just came out of an hour and a half long demo of layout builder.
The business was very excited because yet though they're on Drupal today, they actually don't have any content editing or page layout editing capabilities. It, it just was never configured for them. So they're very excited about layout builder, but even in our demo, I'm wincing a little bit, every time a thro takes too long to pull up a modal dialogue and then you have to wade through this list in the sidebar of all the different block.
I was like, it's still not great. I think once we get to Canvas that that experience is gonna be so much better. And so we, we will be making sure that, that there's a great out of the box experience for any Dral commerce user with Canvas, but certainly anybody building on top of our recipes, themes and templates.
Nic: Well, Ryan, thank you for joining us. It's always it's been a pleasure chatting about Commerce and what the future holds.
Ryan: You bet. Thanks for your support. Thanks for being a part of the the Commerce channel. I know that everybody here has been in there and helped other people as well. So appreciate that, that spirit of, trial and error and paying it forward. Whenever a solution is found, that helps somebody else much obliged.
John: Do you have questions or feedback? Reach out to talking Drupal on the socials with the handle Talking Drupal or by email with [email protected]. You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel.
Nic: Want to be a guest on Talking Drupal or a new show TD Cafe? Click on the guest request button in the cyber bar at talking drupal com.
John: You can promote your Drupal community event on Talking Drupal.
Learn [email protected] slash td promo
Nic: and you can get the Talking Drupal newsletter. To learn more about our guest host, show news, upcoming shows, and much more, sign up for the newsletter at talking drupal com slash newsletter.
John: And thank you patrons for supporting Talking Drupal. Your support is greatly appreciated.
You can learn more about becoming a [email protected] and clicking that big become a patron button in the sidebar.
Nic: Right. Ryan, if our listeners wanna get in touch with you, what's the best way for them to do that?
Ryan: Oh best way to find me is probably through X at Ryan Zama Drupal Slack in the Commerce Channel.
Or LinkedIn. LinkedIn seems to have become the the, the Drupal social network du jour. I'm, I'm fairly active there and always happy to chat.
Nic: Alright, and how about you, Steve?
Steve: Yeah, I'm s swt on dral.org and Dral Chat. And also on LinkedIn is Steve Work.
Nic: Awesome. How about you, Joan?
John: You can find me [email protected].
You can find me at John Ozzi on the social media and drupal.org. And you can find out more about EA [email protected].
Nic: And you can find me pretty much everywhere at Nixon and I-C-X-V-A-N.
John: And if you've enjoyed listening, you've enjoyed talking. Have a good one, everyone.
Nic: Peace. Thanks everybody. Appreciate
John: it.