 Just by way of introduction. I have four guys on stage with me today. I'm Ryan Zorama from Commerce Guys. I'm the erstwhile project lead of UberCard to now Drupal Commerce since Drupal 7 has come out and I'm joined by four guys that have been really some of the early adopters of the software, both in building really complex sites, building some of the essential contributed modules that we've needed to flesh out what Drupal Commerce can do. And also they've just been really good contributors back to the project in terms of bug review, patch review, really supportive. So really glad to have contributors like this. I'll let them introduce themselves starting with Jamie and on down. Hi, I'm Jamie Wiseman. I'm a lead developer for SAP Hub. Hi there, I'm Richard Jones. I'm the technical director of ICOS. Hi, I'm Jacob Trup, and I'm a do-over as revealed IT. Hi, I'm Petri Filipe and work for Kandu Image of Switzerland based web agency. Thanks guys. So which who's coolness like do we get any feel for their personalities? There we go. All right, and we really do with Drupal Commerce value every contributor. So I'm so happy. I really believe in the power of the community to develop even a very complex piece of software. And I'm really impressed with people like Peter who start working on Drupal on the most complex side that I've seen as their first introduction with Drupal Commerce still in alpha and Drupal 7 not out yet. And I mean like he's an early adopter par excellence. So I'm really impressed with these guys and I hope that what they have to show you about what they've been working on will give you some idea of what you can do when you develop sites with Drupal Commerce. And we will be looking at mostly screenshots of things that they've actually built with them discussing the implementation. I'm not actually going to pull up any code because I don't think you'll be able to read it anyways. But if you want to talk code afterwards feel free to find any of us. We've all got our hands dirty. But we'll just dive in with the presentation here. So one thing that I like to do whenever I give a Drupal Commerce presentation is sort of frame the discussion so you understand where we've come from and where we think we're going with Drupal Commerce. So obviously I started my Drupal development with UberCart and whenever we started working on UberCart we had a very application mindset thinking what should UberCart be able to do and let's use Drupal as just sort of the base. This provides the CMS functionality. UberCart is the e-commerce application. It needs a feature list and so we just work toward those features. And what we eventually did is we worked ourselves into a whole because some features never worked together such as VAT and coupons I think. You still couldn't get your taxes right around that. Multi-currency never really worked great at a core level. And then just if we didn't have features there, the question in the issue wasn't how can I build this using all these other contributed modules from Drupal but why doesn't UberCart do this? And so we're really trying to deflect a lot of those questions now by focusing more on being an e-commerce framework. And so I guess it'd be fair to say we are a little bit more than just a framework if you want to be a framework purist. But we have this framework mentality where the core of Drupal commerce is just the core systems and components you need to do e-commerce on top of Drupal. And so I guess what that looks like is we have a few core entities and fields that I'll introduce in a minute. Things like a shopping cart and a checkout form. We aren't hard coding business rules. We aren't hard coding any sort of business logic into the modules themselves. Instead, we're depending on other modules like views and rules and entity to provide a lot of this configurable e-commerce functionality on the back end. So with UberCart and with Magento and OS commerce and a lot of other e-commerce applications, the question you might come to it with is what can I do with this? With Drupal commerce, the question we want you to have when you come to it is what can I build with it? And if you need a good starting point, there are distributions and other ways like commerce kickstart that will help you start doing something quick. But still the big question is what can I build with it? And I think that the testimony of these guys will be that they've been able to build some quite diverse stuff all using the same core project without having to do any hacking of core, I hope. And with contributing a lot of patches helps you not have to hack core, right? So, you know, moving on, we have also this slide that we've used since Chicago to sort of explain what I feel is the Drupal commerce ecosystem or platform. We're starting, of course, with Drupal, and Drupal commerce is the foundation of everything. And we actually did just get Drupal commerce 1.0 release two nights ago. Yeah, so it was really exciting. We actually wore out one of our developers. He just had to go home. Voyon's no longer with us. It was a bit of a marathon just to make sure we had all of our tests surpassing. There's no critical issues. And really it is production ready. We're using it in production sites. These guys all have production sites. And we're really confident in the strength of our foundation. So I really think the solid tag on the side is really fitting. It doesn't do everything. It's not a robust e-commerce application at its core. So for the application type features, we're depending on what we call essential contributed modules. And so there are things like Jacob's shipping module. If you want to do calculated shipping or flat rate shipping, that's not essential to what e-commerce is. The business of finding out what somebody wants to purchase and taking their money. It is pretty essential for a lot of people doing e-commerce. So this is an essential contributed module for us. One that, even though it's not part of core, will be maintaining. I'll be helping maintain right along with the core modules. And that's actually been my focus for the last week before the con. Is shipping and other payment modules like PayPal and CyberSource and Authorize. And I guess these guys have a host of other payment modules they'll talk about in a few minutes. But then on top of these essential contributed modules, we still know that that's not going to be usable for most people. Like a casual store administrator, a newcomer to e-commerce. Because you still have to know how to install a Drupal module. How to configure a view, how to build a rule. And that's, you know, almost a programming language in itself. So what we're going to do is target preconfigured features and use case specific distributions of Drupal. These are things like the commerce kickstart, which takes the core Drupal commerce modules and packages them up into a store out of the box. It's a very minimal store right now. But we have the ability for it to create example content and guidelines perhaps for you to know how to use the commerce modules and how to start building a store successfully. And then the last piece of the ecosystem, of course, is that even that won't be enough for everybody, so we still need accessible experts and integrators. Whether it's Commerce Guys, one of our partners, one of these guys on stage, or one of the many developers that have been contributing in the queue. And then, you know, of course, whenever we talk about accessible experts and integrators in support for e-commerce, we also are happy to announce that this con, that Commerce Guys will be partnering with Acquia to actually have service level agreement type support for e-commerce sites on Drupal. That's really exciting for us because it really brings a measure of viability, in a sense, to Drupal as an e-commerce platform for large scale corporations to know that they can actually have dependable, predictable support of the software. So what we're going to talk about in the next questions and things that I present to our panel are how do these guys make use of our core entities and fields? Which are things like a product entity, line items which go on orders, customer profiles which capture billing and shipping information, and payment transactions which, of course, capture every attempted transaction in the result from the gateway. So we'll be discussing these. I'm going to slide really quickly through these slides. They'll be online with more description if you want to read through them later. We'll go through these core entities and fields, and we'll also talk about our core commerce systems. One of the primary ones of which is the product pricing system which I'll introduce in detail in about 10 or 15 minutes. So we have the product pricing system for all of our dynamic pricing and taxes and discounts and fees and currency conversion and everything else, all working through the rules module. We have our shopping cart which all works through the views module. We have a checkout system that has the drag-and-drop form builder, multi-page, single-page, you name it. And then, of course, we have a payment system that everybody's going to have to deal with one way or another. So having introduced Drupal commerce and the core entities and fields and core systems, I want to start asking our panel some interesting questions. So the first one is how can you customize the buying experience with Drupal commerce? Are you locked into one paradigm? Do you even need a shopping cart? If you've used Uber cart, you're familiar with the cart module containing all of the checkout codes. There is no separation between a cart and checkout. So what I'd like these guys to do is to show us how exactly they've been able to customize the buying experience and, in some cases, get rid of the shopping cart and checkout altogether and still use commerce as the base for their e-commerce system. So first, I want to pitch this to Rich. How have you guys at ICOS customized the buying experience for your clients? Okay, thanks, Ryan. So what we've got actually to show you first is a really, really simple example. This particular site we were building didn't need quantities because they were selling unique products. And really, one thing Ryan mentioned there, which is just so critical and really, really, really powerful is that the cart and the cart block are now powered by views. So in this particular example here, we were able to just redefine the view so that we took the quantity column away. Again, very, very simple example, but the fact is now in Uber cart we would have had to go into the theme layer, we'd have to have a messin' around with the cart, four waters, all sorts of things. But now, because it's all views, it's very, very simple and you can just change that exactly as you want. And it's the same with the cart block as well. Yeah, it's really exciting actually that we got the views form functionality as now a part of views three itself so that you can actually build, you know, drag-and-drop form, not just with commerce, but I assume that other modules are going to start using it too, but I don't know of any yet. So we're the first ones to find the bugs. And then I guess we also have Peter if you want to talk about Eurocenters and just tell me when to flip your slides. Yeah, Eurocenters is a very special case where we sell language courses in foreign countries. So you can't buy several courses at a time and that's why we totally bypass the cart as you know it and we changed it to some kind of a product configuration. This means this one is customized. This whole part shows all the options a language course can have and if you switch it, actually what you see here in this corner is the cart view. So with some HX magic you can have it like changing something in the page, in the configuration, and you see immediately the change of the price and fees and all that stuff. So no cart icon and another idea behind that is the user experience and the conversion rate. You don't allow the customer to escape somehow. You have this one way. Now, well, you found a cool school, now decide what you really want and then let's go traveling and learn foreign languages. And do they even do checkout on here or is it just like booking and then pay offline right now? They have a checkout flow with an overview but no payment at the moment because our customer takes really care of every detail of the travel and gets in touch with them and provides more information and some kind of offline upselling. Okay. Great, thanks Peter. And then Jamie with SubHub, if you want to talk about your custom buying experience and what you've done to make it work, that'll be great. So our core offering is basically a subscription model where users are signing up for our client's sites and buying effectively a role. So this here is, we invented a new product type called a subscription. And this here is just a view, displaying the, well, it would be more roles but there's only one. And it's really, because our users are quite low level that they want a very simple experience. So it's literally you click the button, go to your checkout page and it all happens on there. You can't actually see the submit button underneath if I had a bigger screen to capture. Is this a custom checkout form or are you using the core checkout? This is actually completely custom, it bypasses the core checkout completely. So we've built a form that utilizes the entities off of the product. When you hit submit, some Ajax magic happens so it goes back, generates the order and adds the line items to it. And then read our extra PayPal and when PayPal happens, other stuff happens. Do you have to be a magic user to start using Drupal commerce? A magic user. Yeah, you guys are talking about Ajax magic and stuff. The barrier entry is not so high but if you want to learn magic, I mean we can teach. Well, marketing buzzword. Marketing buzzword, okay, okay. Cool. And so yeah, so these guys, I guess we started with Rich saying that you can use views in the UI even to sort of affect the buying experience of the cart block and cart form level. And then we have Peter bypassing the cart form entirely. Jamie's now bypassing checkout and doing his own thing. And then lastly, I think, Jacob, you had one where you guys just, you don't even use cart or checkout, right? That's right. I think this is a good example of how Drupal commerce can be used as a framework and you're not locked in to do it in a certain way like you are with UberCart. And now this page is what you get to on a side roommate. It's a printing company and it doesn't actually use products. It uses web form instead. And the problem is that we faced is that they have a very complex price calculation. So if you order like 10 magazines, it's one price, 20 magazines, it's a different price. So instead of making like millions of permutations of products, we make a web form where you can fill in different stuff as you would with a product. And when you click order, you get this page. And you can see on the top left is the details from that web form with the basically product info. And on the right hand side, you have the customer details in order to use this stuff. They need to be what we call a pro customer. So they are known by the company and they have an agreement. So they already have a customer profile. So we pulled it in using the customer profile entity. And there is some different fields for the order. You can give it a title. So you can search on it and manage your own orders. And at the bottom, we have a file widget where you can upload multiple files. Typically you want to have printing files saying if you print a magazine, you have a cover, you have all the pages. And basically what we went for is have a single page where you can do all of that stuff. And at the bottom, you just click submit. And behind the scenes, we managed to create a web form submission. We linked that to the line item. We added the price from the calculation where the images or the printing files and where the order info at the order and all of that we linked together as a single order. And we send them off to a completion page. And because of the commerce system, they can use, they can see their orders and the people at the printing company, they can use the backend of commerce to see all the orders that's made and they are notified by email and they have different customers. They have a system called project managers. So they manage different companies. So they handle maybe the need to talk about when the printing can be done or they need to push it ahead and stuff like that. So they can still see all the orders coming through on the front end as well. The customers can go and view their order history and everything. Exactly. And that's still core functionality or did you customize that? That's basically commerce core. We customized some of the functionality on the user page where you can see the orders. So we added some search functionality and we added some advanced views integration so different users that are part of the same company can see all the orders that's been made. Cool. And the backend, that's totally just commerce more or less out of the box. Cool. Yeah, so what we're trying to sort of give a big picture here of is that you can do anything. You can customize this Taylor Mega 2 a particular business need, whether it's no cart, no checkout, orders entered on the backend. You could use it as an invoicing system where you create an order and then just send a customer a checkout URL. You don't have to have the cart module. You don't have to have the checkout module. But I should say that, you know, what's the double negative here? Non-developers can still use this. So you don't have to be like an advanced core patch contributor to be able to build a store and maybe we should have started with just like a generic example of here's the experience out of the box because we still are providing the cart experience, the checkout experience and then rules that execute on checkout completion to create user accounts and email notifications, update order statuses and all the like. We just didn't demonstrate that. We sort of went straight for the hey, we can customize it. But I think developers tend to gravitate to that may be intimidating for some of you. But we are still very much concerned with the out-of-the-box experience and we've had Boyan Summers been a really integral part of the team. He's on the usability team for Drupal 7 and he's really been making sure that what we're doing conforms to best practices and is good for core and for e-commerce conversion. So that's the gist of the first question, I suppose. How can we customize the buying experience? And if you have any further questions, maybe hold on to them and you can refer back to something that somebody said and we'll have time for Q&A at the end. But I want to move on to what I think is the pinnacle achievements, I guess, of Drupal Commerce in its core product pricing system. I introduced this just a little bit ago as the main thing through which every product price is calculated. And what happens is whenever you want to see a product on a page, if I want to go to this t-shirts product page or something, it's going to have a price there. But the way we arrive at that price is we package it up into a line item as though it was in my shopping cart right now. We send it through rules and then all the different rules that are attached to this event called calculate the sell price of a product, they can alter the unit price of this line item. So they can say add a tax, subtract this discount, convert to this currency based on where the user is shopping from and all of these changes are going to be stored inside this price data array. So we actually have, like, a change log of what's happened to every price on the page so that whichever rules got executed, whether it was, you know, well, you can't really read those, can you? Whether it was taxes, whether it was discounts, you can actually come back and see this trail of how did I arrive at this price, which lets you do some fun things, like I think I want to steal Richard's thunder, but it lets you do some fun things with that data on the product page itself, and then also these prices at the unit price level will then make their way over to the total of line item down to the order total and display to you on the checkout pages and cart pages, sort of a breakdown of how much of this is the base price of the product, how much of this was, you know, your VAT, how much of this was your membership or bulk reseller discount, and then your grand order total. And it's very flexible in terms of display. You can have, I guess, price components or things that get altered onto the price that don't display up front and only appear at the end, such as U.S. type sales tax and maybe sales tax in other countries where you calculate it up front, but you don't display it until you actually display the order total. But you can also do your VAT, whether you do it through a pricing rule or on the product edit page, entering your prices including a particular VAT rate. So it's really flexible in terms of how, when, where you actually alter the price and what you do with the data after the fact. And so I guess what I'd like to do is look at Eurocentres Peter and just, just explain to us how you've used the pricing system and maybe how you haven't used it because I think that you have an interesting case of, you know, a few hundred thousand products to avoid just using this system. Yes, indeed. Our approach was that we need to know all the prices of all the courses within the valid price range and each option has an effect of the price. So we're pre-generating actual 430,000 products. That's for a one and a half a year the prices. And then we add at that step we add fees and whatever is possible to these prices as price components. So if you choose a date, you actually switch the product that's pre-generated so we can skip a whole bunch of very complex logic on execution. But in addition to that, we have fees that are not possible to pre-generate. So we use the rules events, Ryan mentioned to add them on execution. So it's quite an interesting mix especially because we are also handling multi-currency in several different ways. How are you doing currency conversion? We started with a currency price field. Every currency had its own price field and if you calculate the sell price we do some girl location look up and whatsoever to determine matching currency for the user and setting it as price in the commerce line item. So you're swapping one price field from the product in for the actual purchase price. That was the start because our customer had the wish to do that for our currency except Swiss francs. So now we have an exception and Swiss francs are calculated or converted on the fly. So first result, you have to decide actually whether you do some calculation conversion on execution or you have to use this field approach. Well, we see now you can use both of them. And I don't know if I already should announce it, but there is a module in work right now that helps you to decide what to use and helps to switch between these models. It's going to be done by next week's commerce camp, right? It has to because of the pressure of an announcement. Cool. And I can't remember. So you've sort of combined using product price equals, but not just depending on the system entirely. Was it for performance reasons or was it just because you're importing everything from an external database or what exactly caused you to want to pre-compile all these different prices up front? Well, we get the data for the prices in Excel. So it's quite fun to get that into a system and there's no enterprise or source planning system in place yet on our customers side. So we decided we just use nearly the Excel as they do it internally and the idea was really to have benefit in performance to have all that calculated before because you have to imagine you have school holidays and national holidays and all that stuff and you have to pre-calculate course prices on these states and really heavy operations and doing this for every single thing would be just too much. Yeah, so the idea is that rules is very flexible and powerful as a programming language inside of Drupal but it's not the end-all be-all and there's no reason to avoid either writing custom conditions and actions for your pricing rules or to even bypass rules-based calculations entirely and sort of pre-compile and pre-calculate all the variations and dump them into the database directly. Exactly, and I have to say the planning was done before the price cash with rules was in place so we were really early with all that stuff. That's the joys of being bleeding edge, right? Indeed. So Peter's talked about maybe some of the configuration on the back-end and the types of things you can do when you're developing complex pricing systems. Rich, if you wouldn't mind just giving us a brief introduction to that very fuzzy part of the screen up top what you can do whenever you're actually displaying a price since you have all of this price data, the component data what went into making this price this price what have you done to display that for the customer? Okay, so hopefully actually the case studies we've got are more generic and more sort of simple based stores and the really important thing again for us here was that, especially in Europe and the UK is that VAT is now really sorted out in dual commerce whereas in Ubikai it was always a pain. So here we've got VAT but because as Rahm was saying prices are calculated by rules it means we can do really great stuff. So in this particular case this site that went live a couple of weeks ago they were running a special promotion so everything was 33% off in August so we were able to write a very simple rule that's checked the date before the price was calculated and say it's okay if the date is before the 31st of August we're going to subtract that 33% off and based on that and the VAT calculations we were able to then split that what you're seeing there actually says RRP and offer price what we've done there is we've taken the component prices and selectively chosen which ones to display so normally you would display the users the customers calculated price which might be based on as in our case the date or it might be based on a particular role for example if you want to give a role a discount so you can do all these really good things with the rules so what we've done there is we showed the original price prior to calculation as the RRP and then we've shown the customer price which in this case is anyone can come in and get this discount if it's just based on date but we could also have done that using a coupon for example if I've put a coupon code in up front I can see my prices on the site so this is all completely dynamic and you can see the prices that you're actually going to pay and that could be completely different depending on who you are because it's all accessed through rules and again we've not done any heavy customization here this is all stuff that's out the box and the views and rules and integrations are just so key to this whole project and have made it massively powerful in terms of stuff that before you would have contributed modules all over the place doing this stuff and now there's none and one of the strengths I guess of us building on top of Drupal 7's field system is that if you need a price to display like this all you have to do is write a display formatter for it and the code for that is not that complex that's right again in this case this is one template that was the only override template we had to use for this entire site was this because we did the rest in display suite but it's very very simple to just make that one change great let's zoom back out here and then we were going to say too that this product pricing system is going to handle the same shipping calculations in a similar manner to what your product price calculations are determined right so this is pretty new functionality in shipping right? I think we went in like a few weeks ago or something like that so the problem we've been having with shipping is that before we used the price components we would create a line item and display that like you see at the top so we would display the shipping line items as well but there wasn't a good way to combine it to you because shipping line items and product line items are different the product line items have a reference to a product and the shipping line items don't really have that you don't really want people removing their shipping from the cart right? yeah so this is where you have done the shipping so the problem is how do you display that to the customer in a good way and the way we did it was to allow shipping modules to define their own price component so what we have here you can see we have the subtle and the shipping and then the auto tool and that is something that pretty much is handled by commerce out of the box because we decided to define the price component when we created the shipping line item so we just tell commerce oh this is not you use the base price this is the shipping and by doing that commerce will spread out the prices as it does with tax handling and it makes a very nice way to display to the customer this is your shipping fee your auto fee this is the taxes and all of that and it's very easy to do I think it was like two or three lines of code to handle that and it works perfectly so the idea is that this whole part of the checkout form is a view it can be customized if you want to to include images or extra information attribute information or whatever and then this part of the view is what's called an area handler it's new to view three instead of just being able to put text into the header or the footer you can plug in this area plugin so this one just takes the order total and uses it to display format the order total fields display format to split out all the components and so the idea is that even though the shipping line item hasn't been displayed in the view itself the view had a filter that said only display product line item types it's not displayed up top and so it gets added into the order total field whenever we display the order total using the display format it says hey break everything up it shows up and whenever you're configuring your product pricing you even have a select list where you can say which price component should this be so anyone that's been defined on the site or any additional price component that you define in code you can choose so that your store administrators know how to register different adjustments to the code or adjustments to the price so if you move on from there that's the product pricing system it all there's one advantage of it all working through rules I don't even know if anybody's using this yet so if you are please raise a hand what we can do is take all of the permutations of your product prices and just put them into a database table so that you can then sort and filter views based on the calculated price even though that calculation is happening in PHP I don't know that that's being used yet but that's the primary motivation for us to handle all of our price calculation through rules if you're just allowing modules to hook in and alter prices willy-nilly we wouldn't have any dependable or predictable way to tell which rules are going to apply for this user and how would we join to the table and so on and so forth so if you're interested in that come find me afterwards I'd love to find good people that we can show off as hey we actually made this work but that's why all the product pricing happens through rules if you're curious the next thing that everybody's had to do here except for Peter because he kind of doesn't like taking money online is how should you best integrate with payment services and if you're looking to find which payment services have already been integrated you can go to www.drupalcommerce.org and I think there's a list of maybe like two dozen or so payment modules including a 3D secure module that have been developed for different markets I think the US, South America and Europe have some, I'm not sure if there's any for Asia yet maybe Alipay has been done the idea is that Drupalcommerce defines this core payment system that can on the checkout form process transactions or from the admin form process transactions and every time a transaction is attempted whether it fails or successful or requires further action like a capture or an e-check to clear we create a payment transaction entity and associate it with the user's order and then you have a view of payment transaction entities on the back end that you can go and look at to determine if the order has been paid in full if there are payments outstanding or if somebody can't figure out why is my payment keep failing you can actually look at the API response from the gateway and determine what is it that's causing this to fail and so I guess does anybody have anything they'd like to add about how you've integrated payment services or occurring or special needs for European gateways or redirected gateways that we can just sort of give people an idea if they have to develop their own well deferred to I did the payment system as it's core is also very dependent on rules and that is one thing you need to understand and it's very general term in commerce is we use rules for almost everything because then you can customize it within the interface and basically when you create a payment method commerce will create a rule for that and you can set up when do you want to apply it, do you want it to be enabled at all and what conditions do you want it so you could create a payment method that would basically skip if the order total was zero but you only want to show that the order total is zero but if you have order total higher than that then you want a different payment system and what you need to do to actually integrate it is pretty simple because commerce will expose some callbacks to your function to allow you to add some form elements if you want to do like inline payment and it will call your function at redirect time to if you want to handle when when the payment is happening offside and all of that and basically what you need to do when the customer returns is to send them off to an encoded URL that will tell commerce this transaction is okay and commerce core will handle sending the customer to the next step because of the way you can customize the checkout flow you may have a single form or you may have multiple steps and you don't know how is it customized but commerce exposes an API so you just tell the commerce okay I'm done take it to the next step and that is a good way to show off commerce that is very flexible but the APIs for the developers is very flexible so you don't have to figure out where to send them you handle that to commerce itself this is a big advantage for developers especially in Europe most of your payment is offsite you go away and you have to come back somewhere so the idea is that in the US most of your stuff is going to be on site so we have helper functions to assist in credit card payment on site so you have a credit card form so that will get a lot of use in the US gateways and elsewhere but then when you are dealing with all these redirected payment services we really wanted to have the same checkout workflow that you would have if you were paying on site so we don't want to introduce two forked checkout workflows especially on the same site I guess where we have kind of been before is that the PayPal module for UberCard had to define its own return URLs and its own completion URLs and whenever you go out the same point that you leave the site from is the point that you will come back to and using the order status we keep track of which step you are at and checkout so that whenever you come back from the gateway we know how to send you to the next page and we know if we get a payment notification in whenever you receive a payment notification your module would be responsible for calling the checkout completion routine that then handles all the business logic of an order so as soon as you know payment has been received we will be using Drupal commerce to create the user account or send the notification update the order status or so on and then it won't duplicate it but whenever the customer comes back from the site then they will go on to the next page all as well, they don't know and your site doesn't have to know that there were two different types of payment happening so that's been a breeze for me because I've traditionally maintained a lot of payment modules and we are still churning out more I think just by a quick survey on the stage, which ones have you integrated or have you used maybe starting with Jacob on down I've done Dips and PayX and ePay okay we've been working on this SagePay all three directs, redirects and form based okay and you guys also did 3D Secure for the direct one we had to do 3D Secure support as well what we tried to do is abstract 3D Secure out so that other people using direct can use that 3D Secure and we were able to do that by just as I said with commerce you're able to find extra check out steps pages or check out panes so we were able to do it that way cool and Jamie yeah we used PayPal but purely just for subscriptions which is a slightly different API to the standard one okay yeah that was fun I just have a bad history with recurring payments so it's just it's like the thorn in everyone's side I think and there's probably plenty of people out here that have some horror stories about trying to make recurring work through UberCard or on Drupal in general so my strategy now is to try to avoid it and to use instead a third party service called Recurly to manage all that stuff these guys were brave and tackled it but I'm sure that a native solution will be in contrib eventually I'm going to stay away it's actually in the comments subscription mode kind of should be split out we'll do that soon cool so in addition to interacting with payment gateways another thing that you're going to be interacting with if you have any sort of custom type store is the line item system and just for a brief introduction to the line item entity what it is it's a default entity type that we define that has a unit price and a total price and a quantity I think that's it and then you'll have different types of line items so these you define a new type of line item for anything that's going to add to the total of an order so by default you get a product line item type and that's it the shipping module defines the shipping line item type various people have defined their own custom line item types and what you do is you can add any additional fields to them that you need to capture the data for that line item type so the product line item types all have a product reference field so you don't actually put the product data directly into the line item it just says this line item represents this customer purchasing product 5 and whenever it has that association I guess you then can access the product data through your rules and through views to display them in the shopping cart to make discounts and you can even if you have additional fields through the user interface attached to your line item types you can expose those line item fields through the add to cart form to create a sort of customizable product and so the idea there is that you can I guess turn the add to cart form into more of a product I don't know how to put a product form you use like a registration form for an event you might put in there their real name their email address in their company in the add to cart form so you're purchasing a registration for a person to that event and you can do this all through the user interface just by adding a field to a line item type and clicking the little check box that says hey show this on the add to cart form and then you know once the user enters that data it's available to you through views to then expose through the cart block through the cart form one use case that we came up with in the training has anybody used the UC variable price module that I wrote? maybe a few? okay cool so the idea behind this module is that people wanted to use UberCart for donations and so what we wanted was a product that could have a variable price based on customer entry so we added this price field through the add to cart form and then we would store that amount that the customer entered in the product's data array and then whenever UberCart loaded this cart you know we would alter the price in what we can do now is you can actually just add a custom price field to your line item type and then create a product pricing rule that says you know if this field has data swap it in for the price of the product and so suddenly we're deprecating a lot of modules just by using rules and using views so I think if you could pass a mic down to Julian I want to put him on the spot yeah yeah go ahead and give him because I have here a screenshot from his latest work where he's not just interacting with a line item system to create custom line item types but he's done a full like customizable product creator right? so just explain this to us what's going on here in this page? the idea of this project was to be able to create some products customized directly through an app flash application and the idea is that you have those buttons with those buttons you can add some text and some images and you have something that we call the printing zone where you can add and move and resize and rotate those elements and once you click on the save customization button a thumbnail is generated and this thumbnail is stored directly in the line item as a field that we call the variation and with that... is it a custom field type? yeah it's a custom field type we are storing that XML data for the flash app and we are also storing the path of the thumbnails and the SVG version and the idea is that you can switch with the HTML that you are seeing the different images, the colors and you have also the size and the printing techniques and this is some advanced HTML not just the select list or the radio buttons we have to implement that too and once you are clicking on the add to cart form you are going to your cart and in the cart we are directly displaying the thumbnails of the generative products are you exposing line item fields through the add to cart form on this? are you using the functionality to expose fields in the line item to the add to cart form? yeah okay where would that be represented on the page? the design bar? yeah what I find really interesting about this project is that it is still using the basic add to cart form just right out of the box you have your quantity selector you have attribute selector so if you have attached a size attribute to this product type or a color one those are still showing up here but it is like you have combined that with the custom line item type to create a whole custom interface for building products so I am really excited about the project it actually comes up a lot are these radio buttons that you have themed to look like images? actually because in html you can't really use some random advance edge markup inside some labels and stuff like that we had to use some javascript to make sure that we are still using a kind of degraded version but it is really tick on the radio buttons and some javascript okay so there is radio buttons just hidden that those images all map to that feature actually comes up a lot in the issue queue how can I take the add to cart form and actually use graphical selectors for various attributes we will release some kind of example code for that have we or we will? we will alright an announcement now you are on the spot great thanks a lot Julien and Julien is our lead or senior dev I don't know exactly the title but in Paris he is the guy so thanks Julien alright the next question is maybe more maybe pre sales or business oriented what exactly should you keep in mind when quoting complex jubile commerce projects at least two of you have worked on very complex sites I know that we have quoted some so Damien if you want to say anything you will be welcome to but if you have any advice for us when we are developing with jubile commerce is there anything specific to the way that commerce works that is going to send the price up or maybe allow you to bit a lower price but how does that work out for you Rich? we have found actually probably in common with not specifically to commerce projects but it is content really getting people to get their content together if we don't have that up front we really don't know what the job is going to be like so with commerce specifically there is a slightly maybe difficult to explain way of doing products in that you have a product and you have a product display and I am now fully on board with why that is but it can be a little bit of a difficult one to explain to a customer and the reason it is like it in my opinion anyway so you can do stock control on individual items and you can have variable pricing as well so we have found that to be a little bit difficult to explain and get that message across and also I guess making sure that we know what the gateway is going to be at this stage of commerce development not every gateway is going to be available so obviously bear that in mind if you are looking at a commerce project it is that gateway development is not particularly difficult in commerce but it still takes time to factor in yeah what you are saying is look at the pieces that are providing and what custom development am I going to have to do around importing and maintaining the product catalog and capturing payment that is right and also one that always comes up is tracking are they using some sort of special tracking affiliate tracking obviously everyone has Google analytics these days but often will need to put tracking on the checkout process in various places often multiple checkout that is another one I am just looking out for because that is where you start to get into custom work and one thing that came up in our BOF discussions in the commerce mini con over in the college was the idea that there are many different types of side administrators many different people that will be interacting with this e-commerce site and the backend of Drupal commerce is going to be fairly intimidating for most of them because it is just a set of views and it is some rules and if they want to customize any of this stuff they are going to have to be technical Drupal users and so I think what we have done on projects is really built an entire custom backend and that is part of the reason we separated out the UI from the API modules in the core commerce package so that you can do stuff like this whether it is building your custom views building custom pages, dashboard widgets or whatever you will want to keep in mind how exactly will the people that are going to be using this site need to interact with the backend of the site because you are going to end up doing a lot of that development I don't suppose any of you guys have done any backend customization we tend to at least do minimal customization of the initial views out of the box just to add some filters and stuff like that and again it is just tweaking the UI really to meet the customer's requirements I think Peter you were really helped on Eurocenters by having like 3,000 pages of wireframes yeah I think one problem that arises with commerce is you can do nearly everything so you have to know what the customer wants or bring the customer to know what he really wants that's not like ubercarpet you have some kind of a closed feature set and you have a dead end and you can say to the customer well that is simply not possible or too expensive with this framework approach it is really a good investment to create very specific and detailed concepts and it won't work always like we decided for this multi currency field approach and it looked promising that was what the customer wanted but you know the Euro got weaker and then some when they decided well we should be more flexible with Swiss francs and all that stuff so even there no dead end you can't do it thanks I guess we'll move on from that question if anybody has anything else they'd like to add we're going to do Q&A in just a second so the final question and I'll just feel this one is where can you go for development support and how can you give feedback or give back to the project and the primary places that you'll find myself and others are in IRC on the same IRC the channel is poundjupel-commerce and you'll find me in there at way too many hours of the day if you need to just talk with me about contributing or figure out how the core works we're also really working the issue like Madmen so we're turning through issues and trying to make sure that we're closing stuff out as fast as possible so bug reports should go there future requests maybe should go there support requests shouldn't go there so the issue here is not being used for support we do have Drupal-commerce.org and we have some tools pending that Randy's developed for us that I have been negligent and following up with him on but we are using forms at least for now and we're looking at how to better use Drupal-commerce.org as a support center for at least form type support and then of course if you need official paid for support there's always the aquea e-commerce support stuff that we're doing now additionally if you're looking for training and things like that commerce guys offers training in our office but there's also often training going on in conjunction with Drupal-camps and Drupal-camps so of course we did a full day of training that we sold out on Monday I think we blew some people's minds I think we had at least one person that was dissatisfied because he was already a developer and we were teaching him how to use the core modules not how to hack into them deeper but we do try to provide a broader overview of commerce and all the functionality and we are developing a more developer oriented curriculum that we've been sort of field testing on some of our partners and maturing and then there's also this commerce camp if you don't have anything to do next weekend and you're recovered from Drupal-can it's in Switzerland how do you say is it in Luzern it's in Luzern and it's two days totally free imagine that a camp about websites that make money was able to get enough sponsorship to make it free for everybody to come they'll be discussing not just Drupal-commerce it's more like the business of doing business with Drupal and there will be commerce sessions I think Peter's doing a couple and some of the commerce guys are doing training going on but maybe there is so then if you want to give back there's a lot of contributed modules that have been developed that need either co-maintainers and there's still a lot of stuff that needs to be done so my goal now that the 1.0 is out is to really dive head first into what essential contributed modules do we need to get down and get ready so that Drupal-commerce can begin to compete at the application feature set level where it's contributed modules so we'll be diving into contrib and definitely open to people that want to contribute back or help out with some contribs and stuff so if I can maybe get maybe one of each of you to go down each aisle and we have a few minutes left for Q&A if anybody would like to just pose a question what it's about developing with Drupal-commerce I know we didn't actually show any code but I'm happy to answer code questions and pull up my ID if you want but if you just have rules and views questions feel free to ask those too so you've got one right here in the front I'm interested in this customer profile when Steve got I'm working with the CRM code sprint tomorrow I was wondering is that in the standalone module somewhere that we can play with would that be worth building our CRM on top of or is it worth kind of going our own way with it and seeing where we end up we talked about integration possibilities with modules like profile 2 or core profiles at first so what we need to determine is that a customer profile in commerce is maybe a bit of a unique case because it may have an address it may not it may just be there for the purposes of collecting a tax ID it's kind of it's just like information that you need as a store to be able to complete the order and they could have a one to many relationship to users and we could have one customer profile that's shared by multiple users such as multiple people from the same organization reusing the same billing data or shipping data so for a customer module I'm not sure that it's going to be super useful for you but feel free to come look at the code afterwards if you want and I can There is an address field module that should be useful for you though so it's the standalone contrib called address field Damien's been writing that and it provides the Ajaxi multi-country address entry field for name and first name and organization name and everything so that may be useful to you then we had a question up here yeah was there any sales people or marketing oriented people involved in the development process of triple commerce any sales or marketing people other than the guys that we've had at commerce guys there hasn't been like a whole lot of contributions from that area are you thinking about in terms of just how to market the project itself or how to build the project for marketers using the site the last part okay well there hasn't been much coming in so far in fact in the core we don't actually have any dashboard widgets for example so what I've heard is that there is a company called LiveLink that's been investigating how to use commerce for marketers and how to customize the back and for internet marketers and for sales people and if we're lucky some of that work will end up in maybe a commerce dashboard module or something and I just talked to them briefly about it at a boss session so I'm not tying them to anything but they're the only people that I know of so far a lot of what we've been doing in developing at commerce guys is how to market an e-commerce framework in a world where most people are evaluating e-commerce applications so ours has been more from the sales of the actual project itself rather than how to manage the sales of the products you're actually selling so any other questions we got one two up toward the back here could you summarize please the state of play with regards to marketplace functionality so what's the best strategy in your view and are there any common pitfalls thanks Jamie I don't suppose you want to give the mic to Damien no no oh you want me to summarize it it was your boff there was a boff yesterday where people did discuss marketplace functionality so multiple stores different types of approaches to check out with that whether you need to have just different carts per store or somehow perform the checkout process twice for each of the different products there's sort of a consensus that it's going to be developed soon there's also a consensus that the core modules themselves are likely flexible enough as is at 1.0 plus one patch because I did commit a patch yesterday for that to allow multiple store entities to sell products and then to allow multiple shopping carts for the different sellers represented in a customer's current order have you actually developed a client site that uses marketplace yet okay yeah yeah so Boyan he actually had to fly home but his screen name is Boyan Z so you can find him and I think there will be a separate contrib for marketplace on commerce and then there's the core functionality it's already there there's a reasonable entity access control even down to the line item level on a given order so I don't think we'll be in sort of an access controller permissions hole it's more just adding the store entity and making sure whether that's an organic group or something else and making sure that we can tag products for that and separate out the checkout workflow so I'm pretty positive that it's going to be happening soon and Boyan's already working on it so we had a question in here I think if you could use the mic please oh yeah this guy right here yeah you're good pete yeah yeah this guy this guy up top okay we'll go for Joe first sorry is there any effort to or is there already contributing modules to integrate with ERP systems inventory systems or other accounting systems are you aware of any Damien yeah nothing generic I mean we've done some use case specific stuff for various clients but nothing generic other than to say that everything in commerce is an entity so everything that has data on it is that either a field data or a property that Drupal knows how to access through its either entity field query in core or the entity API in contrib and so that you know exposing this data whether it's through views or through feeds or you know if you're bringing it in through migrate like that's possible but there's nothing like hey this is the ERP connection module is there any thought of doing that I mean like it would be great you know but it's kind of a matter of finding a client that needs it and then finding a generic solution that works for them and can work for other people so yeah and then we had one I think like five rows back we'll do yeah if Peter you can get the mic to the guy up top and then Latuli just a small remark there's a showcase a page on your side but not all those sides are on it I guess we need to fix that there's a wiki page on DrupalCommerce.org called I think it's just DrupalCommerce.org slash showcase it's a wiki where you can just go and throw in a link and sort of add a little bit of a blurb about how commerce was used on a particular site so there's some really really sharp looking sites I mean I think that Eurocenters to me is kind of like the pinnacle of Drupal7 development I think it's a really really sharp site really complex and really puts Drupal7 through its paces but there's some other really nice sites that demonstrates the right to left functionality in a Hebrew using Hebrew and I guess it's in an Israeli store there's some other nice sites and then just sort of get you a broader feel for what people have done with commerce and I think this will be the last question because I think people are getting hungry wait I lost my question no no I got a question multi-language is always a pain in the ass how does the panel people respond to that because how do you do you have best practices or tips to handle multi-language you're standing right by the guy so I'll let Peter answer that one well we went straight for entity translation because imagine like something like a e18n note sync on 430,000 products and we have seven languages no chance but it works quite good with entity translation even if it's not really released yet um I guess I have to talk to the maintainer I promised it Jose and Gabo that I will talk to him tomorrow we've put patches into core for both entity translation and i18n right that support yeah so when you're dealing with Drupal commerce because we've separated out the definition of a product from how it's displayed and where it's displayed it's much to translate on the product itself other than the title and then if you're using attributes the attribute options when you get into that your attributes in Drupal commerce are just fields so it's just translating field data so if you're selling t-shirts and you need to have small, medium and large for the size translated into different languages you just add a field to your product type and you can have that show up on the add to cart form and then you need to make sure that Drupal knows that this is a field that should be translated well there is i18n fields although other stuff is mostly entity translation and title module so let's go ahead and close the general Q&A there and if you have any further questions for myself for the panel or any of the commerce guys we'll hang around up front until we just get so hungry we have to go and we'd be happy to hear from you talk with you we do appreciate your time and attention so good luck with Drupal commerce