Transcription of a free-to-watch video on Vimeo. Translaters see footnote. Best seen on another screen but this is the ebedded version
https://vimeo.com/33628943
HI - I guess we'll go ahead & get started. You are in the
Practical Drupal Commerce Session. I am Ryan Schama of Commerce Guys. I live in Louseville Kentucky but I - I've been to two Drupal Camp rosters. I went to the first one two years ago. I don't know why we didn't make it out last year, but I was pretty bummed, and so I pushed hard for us to come this year.
And what I'm going to be doing today is not talking about Drupal Commerce so much as showing what it would actually look like to set up a site using Drupal Commerce. And I have a couple of demo sites that I'll also use to show you examples. I'm going to treat it like I've just been given a project by a client to build a Dallas Cowboys fan site. Just selling some Dallas Cowboys Merch[andise] . And if you want to introduce some Scope Creep as I am building this site feel free to raise a hand, and we'll take in a different direction. So feel free to introduce some scope creep on me this one time only!
1' [one minute]
[screen: let's build a cowboys fan site that .....
But I said I didn't want to talk too much [7-8"] about Drupal Commerce sort of high-level without just digging into a site. But we're going to do that now and this is sort of the template that we're going to follow here.
7'22"-7'44" repeats screen
I really do want this session to be practical & hands-on, so if you do have any questions just raise your hand and I will call on to you.
7'55"
And I'm also going to show this off. So this is my Do It With Drupal site that's a clone of Apple's online store. So I use this to preface, I guess, how we are going to sort of build stuff. I'll give you a visual sort of how-we-are-going-to-build-stuff that we can look at while we are waiting for our Drupal site to install.
Alright: so. Lets flip-over to the browser, because the first thing we are going to do is install Drupal Commerce. So I just got handed this project; I just got tasked with it. I need to build a store quickly, and one of the fastest ways that you can get up and running with Drupal Commerce is with Commerce Kickstart. It's an installation program that I maintain. That will install Drupal Commerce with all of its dependencies. That includes Views, Rules, Addressfield, C[haos]tools and ... [screen shows a progress bar and lists of modules installing]
So it will install all its dependencies and a couple of modules and configue to make sure that your shopping cart block is showing, to make sure that your permissions have been granted properly and everything else. And it will also give me an opportunity to set-up some sort of example store content.
So while that progress bar is going, this is the Pinapple store that I built for
9'
Dua Drupal. And as you can see it looks strikingly similar to store.apple.com And the lions' share of the work in this web site was actually (- oh it's not adaptive apparently. It wasn't disigned for a xxxx display -)
So the lion's share of work in this site was theming. So I spent about 40 hours building this website. Maybe five of those was throwing the Drupal site and Commerce and Views together. The other 35 hours would have been making it look like apple.com. And learning some tricks along the way. So if you're curious about those tricks feel free to find me afterwards but I'm not a great theme writer. I did put my "themer" sticker on [for the conference seminars] but I'm very much amateur. This is my first theme ever. So I'm guessing that some of you could do this much faster than I did.
So I'm interested in that we're going to sell just regular merchandise. So we have just a regular product page. We do have some of those on this website. And you can go to the piPhone, and then click-over to select our piPhone,
10'
- not responsive. Looks great on 1074 x 758px. And Apple has these sort of splash pages that then redirect to their actual product pages. And this would be - once it loads - just a basic product page to select some attribute of the piPhone, whether it is your colour, or your hard disc size. As you select the colour you will see the image update. This is just core Commerce functionality using the new Ajax framework in Drupal 7. The price will also update on the screens - that's way down here in the corner! But if I upgrade my hard drive to 64GB the price is going to shoot-up and I am going to add that to my card. So we'll demonstrate how I built this using the different sizes of the jerseys that we're going to be selling.
And I also said that we can do customisable products. With Drupal Commerce it's quite easy to take an add to cart form and expose additional fields that must be filled out. [screen shows buttons and titles overlapping on big scale] Wow that looks awsome! In the add to cart form.
11
So what we have here: I'm interested in that Drupal Commerce does not force a particular type of product display on you. So we had in the one instance the iPhone where we had all the different options and you select them and it's one add to cart form . For the iPods I actually had a separate product page for each model which is what Apple does for some reason, and now this is just a View of my actual product display nodes. So I have a separate node for each of my ipod models, and this is just a view that's displayed as a grid, with some custom theming on the links and what-not.
So you pick your model and then once you go there you actually have to customise your ipod. So this is where you do things like specify your custom name of custom number or whatever.
So this is done by attaching fields to the line item that's actually going to be added to my shopping cart whenever this product is added to my cart. So I'll demonstrate how I set that up. And then I won't bother going to checkout because I'm sure it looks horrible and it costs $600 and because Commerce Kickstart has done installing.
So has anybody here not used an installation profile before?
12
A few haven't. It's kind of like getting more and more privelidged inside of Drupal to the point where you can include not just module installation but additional steps. So you can install and configure themes during the installation process, and I guess there are probably some other things you can do with them but those are the main things you can do with them. And then Drupal.org itself will let you include a .make file with your installation profile so it can actually bundle everything into one tarball for you including Drupal Core. So this is the way that people will begin making distributions of Drupal. Is by taking an installation profile, all the modules and custom theme and basically creating a custom experience for a particular business model or type of product. Package it up into one discreet tarball that somobody that is really new to Drupal - doesn't know how to click through everything and set it up - they can go and grab and start selling immediately.
And so one of the best examples that I've seen so far for Drupal Commerce is
13
Open Deals App. It's just Opendealsapp.com. And they've actually taken Groupon and cloned it into Drupal using Drupal Commerce with their kind of straight-on rip-off Groupon theme, and you just download their app and you have a Drupal Groupon kind of site that you can start to customise and quickly deploy for your clients. This is actually a fairly common feature request in our queue at least - I don't know how many of you guys get those requests. Honestly if I got a request like that; if somebody asked them to build a Groupon clone I'd just say go use Groupon, but maybe you have a newspaper or a local organisation wants you to build something like this so you can use Opendealsapp as your launch point.
And the idea here is you're trying to give or we're just trying to give site builders and new users just a very basic starting point to customise the Groupon site so you don't have to do the same stuff over and over again for every Drupal site you're building.
Now the same holds true for Commerce: we have Commerce Kickstart which is designed to get you up and running with just the core Commerce modules as quick as possible
14
Right now we don't even have a custom theme. I'm just using Bartek. I am using the Admin menu with the Admin Menu toolbar that it comes with, so it makes it look like the core toolbar but it's not really. I should probably disable that for the purposes of this demonstration. I'm just going to go back to the core - you know I'm scrared to go back to this because I'd have to go back to this sort of five times...
Alright so we have our Kickstart site. The project was first we were going to start off selling autographed merchandise.
So as you can see Commerce Kickstart did start off creating three basic products for me, numbered one two three with nodes displaying them. What you see here is actually a node that's set-up by commerce Kickstart. It's a node type called Product Display. This node type has a product reference field on it. So the actual product data if I were going to edit this node, you're not going to find a product price or SKU field or anything. What you have instead is this product reference field, where by putting in the SKU, this field associates product three with this particular node. If you're familiar with the way that fields work either in [Drupal] six or in [Drupal] seven, you have a widget where you specify how does this field's data get entered, then you have a display formatter that detirmines how that data, once it's attached to this node, is going to be displayed in different view modes. So: how will that product reference field be displayed in a teasier versus a full node. And one of the display formatters that comes with Commerce is an add-to-cart-form display formatter. So the way this add to cart form shows up here in this node is that this node is associated with product three: the display formatter says
"hey! make me an add to cart form for product three". And it throws it in here.
So what I can do is on, I guess, the product list side , if we go to Store Menu; I have a view of products, I have products one two and three, so lets get started and edit product three and lets make this into just
16'
an autographed football. So I think I have a football autographed by Troy Akeman. [types TROY-AKEMAN into the SKU field of the edit view for product three] I can type quicker with two hands. [puts microphone on stand] holds it here.... Right: so we have a Troy Akeman football [types into teh Title field] I have an image here. By the way these image fields have been set-up for us by Drupal Commerce - you don't have to use that but most people when they're trying to test-out an ecommerce application they want to find that so we put them in there. And the image field is actually attached to my product.
16'39"
You can either attach the images to the product itself or the node that's displaying the product. It's really kind of up to you and the products that you're selling. In this case it probably wouldn't matter. I could have just thrown this image field on the node itself because I'm only going to have one image, or at least one set of images for the football. There aren't multiple different footballs that I'm selling. But imagine if I had different colours
17'
and different styles of football. The brown, or the blue and white, or the Dallas Cowboys celebratory whatever football, you know maybe I would have an option to choose what colour football I want , and so I would want to have a different image appear based on that. So like I showed you with the pinApple store, as I chose a black versus a white piPad or piPhone, I mean it was actually changing the image on the page, because it was pulling that data straight from the product that's actually selected on the form.
17'27" [long pause for question] Yes agreed. Yes it's very impractical huh. Yes: no no.
17'53" Just so everbody heard.
The feedback here was that the architecture makes sense. Like we know that we need like a discreet set of product data [18] that exists somewhere, that isn't tied to any particular disciplin. Like you might have multiple ways of displaying the product; multiple languages, and you might want to keep each language display associated with one discreet set of product data.
But for just the casual store owner. When they come and see this thing, like [they ask] "Wait: why am I going to adminsiter my product data in one place and then manage how its connected to stuff in another place?"
And it is frankly, that we expected and anticipated that this would be the main negative feedback for Drupal Commerce, for [version] 1.0 and it's going to lead into infinity, so you've got to say, look, we can get the archetecture right and then lets throw usability modules on top of it that sort of give us a more expected workflow.
And so what you have is there's a module called the Product Display Manager that lets you manage your display nodes from the back end.
And then what I'm working on is called the Inline Product Form Module that can...
Instead of having two separate places [to edit product display and product data],
you would just edit the node and on your node form you'd have the product added to that as well. I think that's what people are expecting and I think it's what you'd expect.
19
And so the goal was to get [version] 1.0 out-the-door, and see these other modules, sort of get developed that can address these usability concerns.
Some people have also taken to gluing these things together using Rules. And so they've made a Rule Set that whenever you create a new product node it would create a new product in the back end. And associate that with this product reference field that they hid from their users. I'm not a huge fan of that approach because it is tying quite a bit of your logic into Rules, that doesn't really need to be [tied-in]. So my hopes are really set on the Inline Product Form Module. I think that's probably the major-use case for just setting-up a store. Any other feedback?
19'43"
Any other feedback or questions about architecture or whatever?
The question was "Is there a sandbox for that?"...[not transcribed as temporary. By the way "updation" is a good word, newly invented below]
20'
If you go to my user page, I'm https://drupal.org/user/49344. You can get the links to my sandbox from there, and I'll get it promoted as soon as it's ready. Right now - I don't want to get off the rabit trail too much. But I have a lot of fun trying to figure out how to handle the creation, updation, and deletion of entities inside of another entitie's form, without committing all those changes before the main entity's form is submitted. So my module handles that but it doesn't actually have a product display node. So it's just ready for it, but I haven't had time to get it done. But the other stuff are done . The product display manager is available. The Rule sets are available niches [specialised options]. And then there's also a module that I was going to get to in a minute but now I've mentioned the others
20'44"
There's the bulk product creation module. That lists multiple options of products all at once. The module is [called] "commerce_bpc". So that's throw-up like all six different sizes and colour combinations instead of one product at a time. And you know it will get to that.
21'
So we do have our one product here - the Troy Aitken Football that's good to go. We can sell that. I've just added it to my shopping cart. I can go to checkout now and I can purchase this football. Let's talk about the jerseys. Because the jerseys are going to have multiple sizes. I'm going to have my small medium large and extra large jersey. And so the way I want to accomodate that is by first of all creating a new product type, because I am going to have to add an attribute field to it. I think that if you've done ecommerce before you're familiar with product attributes? These are the kinds of things that are basically user select-able options. So whenever they go to add to the cart , you have these groups of the different sizes or the different colours or wattages or whatever it is, you know, that you're selling (between apparrel or equipment or whatever) they can choose on the add to cart form the attribute that matches what they want.
Let me go to my product types here. It's kind of hidden here. Sorry about that. But I'm going to go to my product types tab and add a product type.
22'
The default one: well the default one that you have here [is called] product. It may be the only sort of product that you need. If you are only selling one sort of product on the site you can just go ahead and add whatever user fields you need to that; use it, and if you don't want it at all you can just delete it and create your own product types. It's really just there for new users to use, or for you to use if you only need to use one generic product type.
In our case we're going to add a jersey product type though. And I'm going to [presses a button marked save and add fields next to save product type and cancel under description and explanation or submission guidelines] save and add fields. And on the jersey I'm going to add a size [clicks on add new field button and fills in field marked label] size [fills-in field marked field_] size. [selects a drop down marked type of data to store an selects list]. This is going to be a list text because, you know, I am going to have a discrete number of options available for this. [moves to the last drop down on the line called select list] And this field - I'm just going to leave it as select list.
[moves the line of data up the screen a little by clicking and draggint an x-shaped anchor]
[scrolls to an allowed values list which is the heading over a large blank box above some text saying "the possible values this field can contain"]
Right, now for my allowed values I'm just going to do my
S/Small
M/Medium
L/Large
XL/Extra Large There we go
23'
[presses save] We also have as fields attached to products we have our own custom set of setting here. So these are: this whole set of fields here is called Attribute Field Settings. And whenever I'm adding a field to a product type I can choose to have that field function on add to cart buttons as an attribute. You don't have to expose it if you don't want it to be [exposed]. But in our case I do want this size field to be available on add to cart forms as a selectable option. And then I can choose whether I want it to be a select list or radio buttons. I'll go ahead and leave it as select list but for theming purposes you may want it to show up as radio buttons. And one example I threw-up onto this site before the session is that there is a cosmetics site that is selling lipstick. They want, for each of their options, a colour-splash to show up. Instead of the name of the colour they want people to a actually click on the colour that they want to purchase. And so they would use radio buttons. And then theme the radio buttons to use their colour swatch. And then like hide the actual radio button itself. And it all functions great.
24'
And the way they did that was that instead of using like a list text field, they used a taxonomy term reference field, and they put in their different colour options as taxonomy terms, and because terms are now entities in Drupal 7, they can add an image field to them. So they would put in the name of the colour, they would attach the image to that term, then use that as their attribute on the add to cart form, and then just swap-in the actual colour swatch for the name of the taxonomy term. It worked great! It was great to see that happen. Nobody has made a generic module out of that yet, but in a situation where you need to do that, just know that there are one or two issues [like this] in the cue that are go through the whole process of show example code, and hopefully we'll get that boiled down into an actual helpful module or a tutorial or something.
24'47"
Here we go. I've just exposed - or: I've just added a field to my custom product type that will be exposed to the add to cart form . Let's just create a jersey. Let's go ahead and start off with our
[SKU filed of] TONY_ROMO_S. And we'll do small. And as I mentioned, normally we wouldn't have to set here and type every single one of your different options.
[Title field of]Tony Roo Jersey, Small. I didn't have one of the most recent version of the bulk product creation module available, so I'm just going to go ahead and type a couple of them: I won't do them all.
[SIZE field: Small S]
And these things go for like rediculousness or something - like $80 or $70? And it's Tony Romo. So it's like: $65. I know, honestly I don't have much room to speak because I'm a Colts [sports team] fan. I don't have any room to speak because I'm a Colts fan. [this is the sort of thing you say to fit-in in Texas]. They're leading right now? Oh they're playing the Redskins [team]. OK, I was totally a guess but they're playing the Redskins. I reckoned they would be leading OK. So I'm just going to do two so I don't take a whole lot of time filling in all these different options. But I now have two different
26'
Jerseys available. I'm going to go to the front end now and create a new product display. I'm going to go through content [on the bar at the to of the admin screen] to node content [drops down]. You'll see that I have my new node type here. So lets add a new one. This will be our Tony Romo jersey. And I'm going to put the size and the title. And instead what you can see is if you enter the SKU it does the auto-complete so I'm going to choose my small. And medium in Tony Romo Jerseys. And when I click save and view the node, I should now have a select list. Oh and I forgot to upload the images. Oh well. We have a few things going-on here. One thing we're going to have to change. But first of all you can see that my attribute field is showing up here for me to select something that I can add to the cart. And the way that this works is that the add to cart form looks at all the products that are set to display here, and it says "Hey! These are all the same type. So these should have all the same fields on them. So instead of showing a select list -
27'
instead of having just one select list that said sort of Tony Romo Jersey Small; Tony Romo Jersey Medium, it know that both of these products have a size field on them, and so it can extract from that the name of the field, and the options available, and lets you actually chose them from a select list. And it can do this for any number of attribute fields. So if you were doing this for size and colour and they were dependant, so you only had small medium and large available in red but you had small medium large and extra large available in blue, it would only show valid product combinations. It uses Drupal 7's sort of Ajax stuff to sort of select the appropriate one as you change options on the form. And then behind the scenes it knows exactly which product ID it is referencing,. So when I change this to medium there's a hidden product field or whatever. So I think the product availability was 3. It changes it to 4. And if those products had different prices, then it would re-render that [price] field. So actually I reckon it's good that [inaudible] because we can see that this [size] has been re-rendered, so it says medium instead of small. I call it product field injection. So evey time you have a product reference field, and its displaying in an add to cart form, whenever that add to cart form changes, you can tell Drupal Commerce to update any visible modules from that product on the node, so this node, whenever its content array was being rendered or whatever. I'll see if we can go to development and show you. Maybe not. I haven't looked before. Maybe. Maybe not. Maybe it's not worth looking. Right: it's not worth looking right now. But any time a node or a user or a taxonomy term or any kind of entity that has a product reference field on it is rendered, the product reference field module will also say "Hey! Do any fields from the product itself also need to rendered into this output?" And that lets you show on the page any field from the product
28'
or any attribute of it like the title of the product or the SKU. And so all that stuff is governed by the fields when you attach them to your product and by the display node. So it's honestly this is still like that this is a confusing thing because you have like two different field interfaces [UIs]. You have the field_ui for the node type and the field_ui for the product type. And knowing where to go to change a particular type of display or a particular action can be confusing. So I won't belabour it too much other than to hop-in real quick and disable the size field because you [programmer] don't really need it because I [shop customer] know which size it is because I'm selecting that in the add to cart form.
And so if I go to my content types [from admin menu, drops down from "content"] Oh, lets try the next one that's "structure> content types> product display" I'm going to go-manage my display. You can see in here all the fields that are coming from the product. So the product image, the product price, product is the actual product reference field that shows-up as the add to cart form.
30'
And if you get-on from there you can see the product size field. I don't want it visible so I'm just going to mark it hidden. You know if I wanted to I could show the SKU, I could show the title. Those things are hidden by default. And then I need to do that for my other view node as well. So for Teaser we'll go in here and hide size.
30'30"
Yes: the question was actually how is the reference handled for prouduct data from like a node or a user or whatever? And it's actually a custom product reference field. It pre-dates both the relatation and the reference and everything else. Maybe for [version] 2.X we're looking at depending on entity reference or something similar, but right now it's just a product reference field. The scheme has just one database column. That's product id. And then from that product ID we create the add to cart form or a list of skus or titles or whatever else. Um Yes. So there we go. Yes. Follow-up question over here: red shirt.
31'
So the question was: What exactly is happening with the image field?
And you see I actually forgot to attach an image field to my custom product type here. So lets go ahead and do that just so I can demonstrate. Will the image be spoft[?] in as well? And the answer is Yes. As long as the image is attached to your product type then any field, again, that is coming from the product , if it is visible on the page will be re-rendered whenever that default button on the add to cart form is changed.
So if I go to image and add - I'll just make sure I have an image field - and then if I go edit my jersey products. I'll just use two different jerseys: one that's blue and one that's white for obviisity. There. We have Jaon Mitten. And we do have a Tony Romo I think. Yes there we go. Alright. So if I come back to the product display that has the two different products referenced on it, we'll see the small. The jersey looks really big. And if we change to medium, the jersey looks even bigger. So it's re-rendered as well.
33'
So again this is just a demonstration of what elements Drupal Commerce lets you bring to the table to let you build your product displays. If you get Drupal Commerce out of the box; if you just grab Commerrce from Drupalcommerce.org/projects/commerce. It isn't going to set-up product node types, it isn't going to set-up product types for you. This stuff is happening because we are using Commerce Kickstart. And the idea once again is that we did not want to make any assumptions about what kind of products you are selling. But we do get a lot of tools to build very dynamic add to cart forms. In Ubercart you had to use two or three different modules to get images showing-up, or to produce option images. You couldn't really render fields from your product data into the node. You just couldn't do this. And now we can because of fields and because of entities and because of, specially, the new ajax framework baked-in to the forms api.
Lets move-on to a cusomisable jersey. We're going to go to a Store>add a product. Oh - you know: just for the sake of time I'm going to re-use my basic product type, and just show this.
admin/commerce/products
34'
So not only can we add fields to our product types in our add to cart form. We can add line item types and have those show up on the add to cart form. So let me come over here to Store>configuration>line items. And you''ll see that I have one product line item type. And the way that the cart works and the way that the orders work in Drupal Commerce is that when you ad something to the cart, a product line item is created for it , and attached to an order. So as soon as somebody clicks add-to-cart they have a full order object. There is (like) no pseudo-cart order object thing. It is like a full order with revisions that keeps track of additions, deletions; it saves what ever data you try to add on the checkout form as soon as possible, so you're not loosing a lot of that valuable marketing data that we weren't tracking before.
34'50"
And so a line item is anything on the order that feeds into the price. It could be your products, or, once I install the shipping module, it could be a shipping line item. For certain kinds of discounts it could be a discount line item. Also for those fields - you can add fields to them and expose them to the add to cart form. So that before somebody submits add to cart they actually specify additional data to store with that product line item in the order.
I don't want to use my one basic product type and add fields to that, because then every time I add products to my web site they going to have the customisation options. It doesn't make sense to ask for somebody's last name to customise a football - their autographed football. So I want to use a different product line item type from my customisable stuff versus my basic products. I have a module that's sort of in the works. I need to finish it up (I'll install some other stuff as we go). I have a module called customisable products - if I can find it! - oh there's the inline product form module - that will let me create additional product line item types for use with different types of customisation. And other areas you might need this would be things like a donation form where you want someone to specify a custom donation amount. And use that amount they specify as the sort of unit price of that line item in the shopping cart. If you go to commerceguys.com there's a great tutorial by Randy Fey that demonstrates that right now. You might also use it for event registrations where the product is a different level of event registration, and then the different fields they have to fill-in our their name, attendee name if they're registering other people, email address, company name, or whatever else. You know - "name on the badge" versus "name on the form".
And so there are many different use cases for creating custom product line item types. We originally developed it for one of our clients that was selling customisable T shirts and lighters and whatever else. They needed to store these design tags with their line item but they had other products that didn't need that stuff. And so we needed multiple types of line items that would function as products in the cart.
37'
And you see now I have installed my shipping module so you see I have my shipping line item type. I've also installed customisable products , so I have this new "add a customisable product" link that I can use to add a customisable product line item type. Well we'll just go ahead and use custom jersey because it's available. Save that line item type. And now I have two types of product line item. So that means that when somebody clicks add-to-cart , we can use either one of these things. The customer jersey line item type or just the basic product line item type. Lets go ahead and edit this one because I am going to go and add my text field. This is for custom jerseys to capture the [add a text field] custom name. And we'll make this just a basic text field. And save. Alright So: we've got the next link [button marked "save product fields"] and so just like with the product fields we had that additional field set where you had your add to cart form settings with fields attached to line items.
38'
You're also going to have add-to-cart form settings. And this one is just a single check box that says "include this field on Add to Cart forms for buy items of this type." So I am going to go ahead and save this and then go and view our products. Lets go back to our Troy Aikman Football. And if you look at this add-to-cart form you will notice that there is no - you know - no name field visible. We can add this to the cart. It doesn't ask me for my name even though I made that a required field. And the reason being: this add to cart form is using the basic product line item type. It does not have any additional fields associated with it.
Let's go an refocus on Product Two. Product two is - let's see - our custom jerseys. Let's go ahead and add a product. Make this a jersey. And this is our custom jersey. Let's write that (SKU) down again. And this is a small jersey. And this is very expensive. Click image. Choose a file. Choose "custom". Right. Now I've got a product now that I want to use my custom jerseys. Now what I want to do is figure out how I want to get this product associated with the different product line item type. Usually what you do is add another separate type of product display. One product display is for my regular product line items. The other one is going to be for my custom product line items. The reason for that is the setting that lets you specify which product line item you want to use is tied to this add to cart form. And this add to cart form is coming from a display formatter. So you have to have a separate node type to have a different set of display format settings. I know this is kind of confusing. Lets go ahead and add this. A new content type called a custom product display node. We're going to add fields to it. In this case just a single product reference field.
40'
Oh and here's the checkbox here underneath "required field" which directs you to "include some reference products". Again there are so many things that we are injecting into the field forms that I know that all of this is going to fly right over your head until you use it, but at least you are aware that this is how Commerce works. It is working through the existing field system. And then you pull all these Commerce pieces together. But if I go to look at my display, I have my product field here. Let's go ahead and hide its label. And it is displayed as an add to cart form. You scroll over here to the right. This is new for Drupal 7 so if you haven't yet used Drupal 7 you don't know about this, but you can have settings for any sort of display formatter now. And in this case the settings for the add to cart form are: should it have a quantity of Widget? Let people say they want 1, 2, 3 of these at once? What should the default quantity be? Should like items be added to the same product that's added to the same cart? Should it show up as a separate line item or should it just increment the quantity of the existing line item? And then the very last one is the add to cart line item type. That's set to Product because that's just the default. Lets go ahead and edit this. Change it from using Product to Custom Jersey. So when I hit update. I go create products of this node type. You'll see the add to cart form with the little name text field. Lets go add one. Add content. Custom product display.
Its making me nervous having that thing next to the computer - my last mac was trashed by electronics falling on the laptop.
I'm not going to go through the full setup here because it's taking a lot more time than I anticipated. But you see now that the add to cart form has a custom text field that I didn't have to specify. And this data, because it's just field data. It's not like we're attaching it to an array and then serialising this data and adding it to the product in the cart. That's what Ubercart does with its attributes. Instead this is field data that can be attached to the line item of the product in the cart. You can get to this data using Views; you can get ot this data using Rules. Whatever you need. So if I was usingthis system for event registration, I could build a massive list of all the people registered for my event by just producing a View of this particular Field. And in this case this field maybe shows the order number that that came from, and whatever else you need to do with it. And according to Randy's tutorial on donations (you know: custom donation products), because this is field data: Rules has access to it. And with Drupal Commerce you can add product pricing rules, that will take the price and alter the price of the product before its added to the cart based on whatever parameters you need. So that could be: you just look at the field like the custom price that somebody specifies as their donation amount would be the price of that product added to the cart.
The question at the back.
43'23"
The question was pertaining to custom pricing and discounting and what-not.
What Drupal Commerce does is that it runs every custom-pricing rule through a single event that it calls "calculating the sell-price of a product". And so this is all done through Rules right now. There are reasons for it that I can explain afterwards. But you have under your Configuration Menu a product-pricing-rules-item, and that lets you set-up your discounts, sales-tax, fees, price lists, currency conversion: whatever, all using Rules. In this case, lets go ahead and just make this a "half off day: half off everything". Save. [curser hovers over "add an action" link] And what I am going to do is add an action to this, called "multiply the unit price of a line item". Because whenever you calculate the sale price of a product, it's done through a pseudo-line item. So when Commerce is about to display a product price, what it asks is "what would the price of this product be, if it were in your shopping cart, right now". So it creates a line item that doesn't save that would reference your order and reference the product, and it passes it through Rules so that anything can operate on that to change the price, add tax, whether it's VAT or sales tax or whatever, and then spit that final price out as your purchase price for the product.
So we're going to thumb-through the line items. I am selecting a "line item action". That's going to multiply the unit action called "multiply the unit price by some amount". In my case I'm going to multiply it by 0.5. And I am going to say that this should show-up on the checkout form as a discount. And I'll choose how that should be rounded, if at all. And now if I go back and look at my product page. I had some footballs in my cart. They automatically got updated to be ½-off, so that's $30 instead of $60 (they'd be cheaper if americans didn't bother with leather, silly arses) and notice that whatever is going to be in your shopping cart is always going to show the most recent price. That's called the "shopping cart refresh". So somebody won't have stale data in their cart if they come back a month later and prices have changed: it's always going to be updated. If you go to checkout: you can actually see that this will show-up on my checkout form as my half-off discount. So all that stuff is tied together and done through Rules.
The same is true for taxes so if I go back to store>configeration>taxes , lets add a Texas sales tax. I think it's 6.25% is that right? 8.25% - oh it's changed. Move to Kentucky it's cheaper [the UK's NHS service runs for only 10% of GDP so although taxes are higher it's cheap too]. And now that I have that tax on there, of course, go-up, and it's an error! This always happens, doesn't it, on tech-demos. OK. It sill still show-up here. I'm going to have to debug that later. I haven't fully tested everything against the latest version of entity api apparently, but you can see that I have my sales tax, which if I am not mistaken is going to come-up at a discounted price but I can't do the Math that quick. So here we have my Texas sales tax. Total $34.95. And all this stuff is coming from a price field attached to the order and it just shows the breakdown. We have what we call "price components" so every price, whether it is a price on a line item or a unit price, or a product sell price, or or the order in total price or the order itself. All these prices have in themselves a change-log of how that price got to where it was. What pieces went-in to making this-price this-price. That includes the base price of the products, discount that came off it, the sales tax that was added, and you can use that to build custom price displays to run your reports on how much tax was collected or whatever else.
Question up front?
The qustion was: Can we have a tax by product? [47.08]
Yes. You just use Rules to change the conditions for the applicatbility of that tax.
So if I went to my store menu again (and I have kind of run-out of time or I would have cruised-through a lot of this stuff) if I go to my taxes menu [bottom item] you can see my tax rates. You can see there is this ambiguous operations link here [right hand side] which is called "configured component" and in Rules-speak what that is is a kind [?] subtlety that detirmines whether this tax should apply to something. So if I go in there, you'll see the full Rules user interface where you can add conditions that detirmine whether this particular tax should be applied to the line item. So I can make this detirmined by some atrribute of the product itself: maybe food items aren't taxed and jerseys are. I can make that detirmined by the shipping or billing address of the customer. Most places it's detirmined by where you're shipping it to. So I would want to go and check the shipping address and make sure that it was Texas before applying the Texas sales tax. So that, again, is all done through Rules. And this all comes through the product pricing system. So product pricing rules is your main point for adding discounts, and taxes, swapping-in prices and custom prices, and price-lists, and everything else.
I can't remember the other objective I set myself for showing this site. I was going to show discount shipping. I don't have time to go through this and build it. So just real quickly I can show you on realmilkcheese.com. Actually this is my first ever personal e-commerce web site. And it actually is responsive so lets see if it works for us right here. The pressure's on [typing and waiting]. Realmilkcheese.com is just a very rushed-out website selling an Amish farmer's cheese. So it's selling raw milk goods, it's kind of yummy, but it's kind of expensive. So what we're trying to do is simplify bulk purchasing. If customers buy $100 of more of his cheese they can get free shipping. What I did was I used the shipping module and the flat rate module . This is Shipping [module version] 2.X. If you are about to use a commerce site use the 2.X branch not the 1.X. And then another module called Flat Rate. Also confusingly, this is not the Shipping Flat Rate Module; just the Flat Rate Module. I'll have that all cleaned-up on the shipping project page soon. So what we did was use the Shipping Module and the Flat Rate Module to - oh! security updates! Great! I've just gone and shown everybody that I have an insecure website! I have my Flat Rate Shipping Method and if you look at the services that I have defined for Flat Rate, I have a "Standard" and a "Free" shipping method. So my "Standard" is 16 bucks or something; free is going to be $Zero. Free is only going to be available for orders that total over $100. So that's easy enough to do.
Just like with Taxes you have a Configure Component link; you have it here for shipping as well. So I just go in here and add a simple Condition. That evaluates, or compares against the order total: "Is it greater than $99.99?" (These comparisons are done in the minor unit of the currency so comparisons are done in pennies or cents or whatever else, so just remember that when you are setting-up your pricing rules). In this case the order is over $99.99. The free shipping should show-up. If it's under $99.99, then standard shipping should show-up. The problem that I ran into was "What if someone selects Standard Shipping and that bumps-up the total to over $100? - then suddenly free shipping becomes available". What we had to do was we added some conditions into the shipping module itself that lets you also specify: "Is the order total over $100 in itself, and the order doesn't have shipping applied to it?". So if you're setting-up rules for shipping, just remember that you have to have that exlusion, because someone could go forward and checkout, save their order, and then come-back and choose the free option and go for it. You don't want that to happen. So you have got to use both things: the data comparison, and also the check that they don't already have shipping applied to their order.
That's how we set-up free shipping. With the Flat Rate module it's very simple to add just as many flat rates as you need. Then with the Shipping Rates again once the base rate has been calculated, coming from that flat rate, you also run that through Rules again, to manipulate the rate further. So if you do weight-based shipping where it's $5 + $3/pound [of weight]. You do the same thing by setting-up a flat rate for $5, and then you use rules to add a conditional $ to it per pound or $3 per pound. There's a lot of stuff you can do using Rules and using the Fields about those Rules that we have set-up [pointing at a part of an admin screen under config>workflow>rules>components - worth looking at at full screen mode] headed "Conditions" and then boxes for "ELEMENTS", "OPERATIONS", repeated under another heading of "Actions".
And we are out of time here and I regret running out of time and I regret that we haven't really cracked the demo. If you have any questions, I'll stand out in the hallway and feel free to come and bug me with them
you're welcome to bug me with them about Drupal Commerce. Thanks for paying attention and for bearing with me, and I'll see you guys next time.
[answers another question - Oh yes? What's that? Sure, Sure]
Two things.
Transcription: translators see this footnote
Some of the jargon is italicised, more or less at random.
Speaking style is Germanic English with maximum hyphenated-together-words.
Sentences are unstructured and meaning depends on context a lot.
Some apologetic linking words like so and and are added to the starts of sentences. I have taken a few of them off again in transcription. Translaters will have trouble.
https://vimeo.com/33628943
HI - I guess we'll go ahead & get started. You are in the
Practical Drupal Commerce Session. I am Ryan Schama of Commerce Guys. I live in Louseville Kentucky but I - I've been to two Drupal Camp rosters. I went to the first one two years ago. I don't know why we didn't make it out last year, but I was pretty bummed, and so I pushed hard for us to come this year.
And what I'm going to be doing today is not talking about Drupal Commerce so much as showing what it would actually look like to set up a site using Drupal Commerce. And I have a couple of demo sites that I'll also use to show you examples. I'm going to treat it like I've just been given a project by a client to build a Dallas Cowboys fan site. Just selling some Dallas Cowboys Merch[andise] . And if you want to introduce some Scope Creep as I am building this site feel free to raise a hand, and we'll take in a different direction. So feel free to introduce some scope creep on me this one time only!
1' [one minute]
So just a little bit of background about myself. I have been with Commerce Guys since 2009. We were just three guys and now we are up to about 36 based in the US & Paris. Part of that growth came out of a merger with the french company AF83 that put-on Drupalcom Paris if you were there. Their Drupal guys came-in to Commerce Guys and we started afresh in Paris. Which is why I am a cheese fan and have brought some cheese with me.
Whenever commerce first started I was the project lead for Ubercart for Drupal 5 and Drupal 6 and we were getting close to thinking about Drupal 7 Ubercart, and that's about when Commerce Guys started, and I quickly because Drupal Commerce. So I am no longer the project lead and maintainer of Ubercart; instead I am the lead developer for Drupal Commerce. Which is a complete re-write of Ubercart, with a functionally equivalent feature-set on Drupal 7, taking advantage of Drupal 7's Core Entities and Fields and Rules2 and Views 3, and so-on, and so-forth, and everything good that has come accross the Drupal world in the last couple of years
My last Ubercart presentation was here in Drupal Camp Austin in 2009. Vimeo.com/9322909
I said"here is what you can do with Ubercart" because we had an application mind-set in which what really mattered was the out of the box experience.
What you could do once you had installed the actual modules themselves.
What kind of store would you have?
How few steps would have have before you started selling your stuff online using Ubercart?
I guess that what that sort of mind-set got us was a lot of application dead ends for developers to really customise what they could do with their ecommerce web site. And so you had challenges with multi-lingual sites; multi-currency web sites. We had challenges with sites where you didn't have traditional product models : where you didn't need a product page for example; where you just wanted a sort of product floating somewhere like an event registration or a membership or something else that's not a traditional product-page-type-of-thing. You were really tied to Ubercart's understanding of your business model or understanding of your product presentation or checkout workflow. You couldn't customise the checkout. You couldn't rip the checkout and the cart in the checkout apart. But if you installed everything at once and needed a store to run as Ubercart ran it was great! It still is. If you need to build a site right now, using Ubercart on Drupal 6, you can probably get going quite quickly. A lot of the contrib[uted module]s are there that you would need. It's still very application focused. If you think about Drupal: how many other modules do you use on a consistant basis, where all you really care about is how the module works once you install it?
4'
There are some smaller-feature modules were that is true, but you don't just install Views, and expect not to have to tinker with Views. You install Views because you want a system that you can customise how you are displaying your content on different parts of the web site. Or your RSS feeds or your export feeds or whatever. Or if you think about Content Construction Kit (CCK) at the time. You didn't just install CCK out of the box. The major contributed systems in Drupal were more about giving you a tool set or a framework for building a different kind of thing, whether it was your content type or your display page or perhaps your organic group system or whatever else.
Drupal 7 has really privelaged us to think again about how we can build an ecommerce framework (we call it) that focusses less on what you can do with it out of the box and more on what you can build with it. We took queues [ideas] from Views and CCK. At the same time Rules and Organic Groups [modules] also did this. We were focussing more on the components that you need to drive your ecommerce web site, and how they are loosely-coupled but can be adapted and mixed-and-matched to create the ecommerce experience that you need for your website.
What I like to say is that Drupal Commerce will give you a store out of the box if you just install all of the modules. But it is going to make hardly any hard-coded assumptions about your business logic; about your business model, about whatever it is that you are selling, about how you need to display it. Hardly any hard-coded assumptions. There are less tools for you as a developer to work against; more tools for you to work with.
We have let people from the git clone [?] use Drupal Commerce for a wide variety of sites. The very first one that was really big and publicised was Eurocentres.com, which if you want to check it out is ...res.com instead of ers.com because it is a European site.
6'
What they did was they were selling language learnig courses all over the world with a multi-lingual, multi-currency site, with highly custom add-to-cart-forms and custom checkout processes. It was just a very custom web site that was built because of Drupal Commerce. They could not have done this it on Drupal 6. They really needed the new data models and the flexibility of fieldable entities and the changes in rules to make their stuff happen.
And quickly after that, like way on the other side of the map was a donation-based web site where it was donation campaigns. It was kind of a Kickstarter.com for green initiatives in different boroughs in New York City called IOBY.org. And next thing was they're creating a totally custom add-to-cart process, where you're able to specify a donation amount for the project, map it to a campaign, and then they had their Views you know, taking all the payments for this one campaign, and sort of filling-up their "progress meters" and all this stuff. Because all they knew they needed was a way to track a monetary amount linked to a line item which references in itself some campaign. And then they could do all the visualisation and reporting that they needed to do. And because of the flexibility of Drupal Commerce's pricing system they were easily able to sort-of change the price of whatever donation product was in the shopping cart to match whatever the customer said. And I can actually demonstrate that although how that fits-in to selling Cowboy shirts I'm not sure!
[screen: let's build a cowboys fan site that .....
- sells autographed merchandise
- sells official team jerseys
- lets you customize a jersey
- charges flat rate shipping
- offers bulk shipping discounts
- collects 6.25% Texas sales tax]
But I said I didn't want to talk too much [7-8"] about Drupal Commerce sort of high-level without just digging into a site. But we're going to do that now and this is sort of the template that we're going to follow here.
7'22"-7'44" repeats screen
I really do want this session to be practical & hands-on, so if you do have any questions just raise your hand and I will call on to you.
7'55"
And I'm also going to show this off. So this is my Do It With Drupal site that's a clone of Apple's online store. So I use this to preface, I guess, how we are going to sort of build stuff. I'll give you a visual sort of how-we-are-going-to-build-stuff that we can look at while we are waiting for our Drupal site to install.
Alright: so. Lets flip-over to the browser, because the first thing we are going to do is install Drupal Commerce. So I just got handed this project; I just got tasked with it. I need to build a store quickly, and one of the fastest ways that you can get up and running with Drupal Commerce is with Commerce Kickstart. It's an installation program that I maintain. That will install Drupal Commerce with all of its dependencies. That includes Views, Rules, Addressfield, C[haos]tools and ... [screen shows a progress bar and lists of modules installing]
So it will install all its dependencies and a couple of modules and configue to make sure that your shopping cart block is showing, to make sure that your permissions have been granted properly and everything else. And it will also give me an opportunity to set-up some sort of example store content.
So while that progress bar is going, this is the Pinapple store that I built for
9'
Dua Drupal. And as you can see it looks strikingly similar to store.apple.com And the lions' share of the work in this web site was actually (- oh it's not adaptive apparently. It wasn't disigned for a xxxx display -)
So the lion's share of work in this site was theming. So I spent about 40 hours building this website. Maybe five of those was throwing the Drupal site and Commerce and Views together. The other 35 hours would have been making it look like apple.com. And learning some tricks along the way. So if you're curious about those tricks feel free to find me afterwards but I'm not a great theme writer. I did put my "themer" sticker on [for the conference seminars] but I'm very much amateur. This is my first theme ever. So I'm guessing that some of you could do this much faster than I did.
So I'm interested in that we're going to sell just regular merchandise. So we have just a regular product page. We do have some of those on this website. And you can go to the piPhone, and then click-over to select our piPhone,
10'
- not responsive. Looks great on 1074 x 758px. And Apple has these sort of splash pages that then redirect to their actual product pages. And this would be - once it loads - just a basic product page to select some attribute of the piPhone, whether it is your colour, or your hard disc size. As you select the colour you will see the image update. This is just core Commerce functionality using the new Ajax framework in Drupal 7. The price will also update on the screens - that's way down here in the corner! But if I upgrade my hard drive to 64GB the price is going to shoot-up and I am going to add that to my card. So we'll demonstrate how I built this using the different sizes of the jerseys that we're going to be selling.
And I also said that we can do customisable products. With Drupal Commerce it's quite easy to take an add to cart form and expose additional fields that must be filled out. [screen shows buttons and titles overlapping on big scale] Wow that looks awsome! In the add to cart form.
11
So what we have here: I'm interested in that Drupal Commerce does not force a particular type of product display on you. So we had in the one instance the iPhone where we had all the different options and you select them and it's one add to cart form . For the iPods I actually had a separate product page for each model which is what Apple does for some reason, and now this is just a View of my actual product display nodes. So I have a separate node for each of my ipod models, and this is just a view that's displayed as a grid, with some custom theming on the links and what-not.
So you pick your model and then once you go there you actually have to customise your ipod. So this is where you do things like specify your custom name of custom number or whatever.
So this is done by attaching fields to the line item that's actually going to be added to my shopping cart whenever this product is added to my cart. So I'll demonstrate how I set that up. And then I won't bother going to checkout because I'm sure it looks horrible and it costs $600 and because Commerce Kickstart has done installing.
So has anybody here not used an installation profile before?
12
A few haven't. It's kind of like getting more and more privelidged inside of Drupal to the point where you can include not just module installation but additional steps. So you can install and configure themes during the installation process, and I guess there are probably some other things you can do with them but those are the main things you can do with them. And then Drupal.org itself will let you include a .make file with your installation profile so it can actually bundle everything into one tarball for you including Drupal Core. So this is the way that people will begin making distributions of Drupal. Is by taking an installation profile, all the modules and custom theme and basically creating a custom experience for a particular business model or type of product. Package it up into one discreet tarball that somobody that is really new to Drupal - doesn't know how to click through everything and set it up - they can go and grab and start selling immediately.
And so one of the best examples that I've seen so far for Drupal Commerce is
13
Open Deals App. It's just Opendealsapp.com. And they've actually taken Groupon and cloned it into Drupal using Drupal Commerce with their kind of straight-on rip-off Groupon theme, and you just download their app and you have a Drupal Groupon kind of site that you can start to customise and quickly deploy for your clients. This is actually a fairly common feature request in our queue at least - I don't know how many of you guys get those requests. Honestly if I got a request like that; if somebody asked them to build a Groupon clone I'd just say go use Groupon, but maybe you have a newspaper or a local organisation wants you to build something like this so you can use Opendealsapp as your launch point.
And the idea here is you're trying to give or we're just trying to give site builders and new users just a very basic starting point to customise the Groupon site so you don't have to do the same stuff over and over again for every Drupal site you're building.
Now the same holds true for Commerce: we have Commerce Kickstart which is designed to get you up and running with just the core Commerce modules as quick as possible
14
Right now we don't even have a custom theme. I'm just using Bartek. I am using the Admin menu with the Admin Menu toolbar that it comes with, so it makes it look like the core toolbar but it's not really. I should probably disable that for the purposes of this demonstration. I'm just going to go back to the core - you know I'm scrared to go back to this because I'd have to go back to this sort of five times...
Alright so we have our Kickstart site. The project was first we were going to start off selling autographed merchandise.
So as you can see Commerce Kickstart did start off creating three basic products for me, numbered one two three with nodes displaying them. What you see here is actually a node that's set-up by commerce Kickstart. It's a node type called Product Display. This node type has a product reference field on it. So the actual product data if I were going to edit this node, you're not going to find a product price or SKU field or anything. What you have instead is this product reference field, where by putting in the SKU, this field associates product three with this particular node. If you're familiar with the way that fields work either in [Drupal] six or in [Drupal] seven, you have a widget where you specify how does this field's data get entered, then you have a display formatter that detirmines how that data, once it's attached to this node, is going to be displayed in different view modes. So: how will that product reference field be displayed in a teasier versus a full node. And one of the display formatters that comes with Commerce is an add-to-cart-form display formatter. So the way this add to cart form shows up here in this node is that this node is associated with product three: the display formatter says
"hey! make me an add to cart form for product three". And it throws it in here.
So what I can do is on, I guess, the product list side , if we go to Store Menu; I have a view of products, I have products one two and three, so lets get started and edit product three and lets make this into just
16'
an autographed football. So I think I have a football autographed by Troy Akeman. [types TROY-AKEMAN into the SKU field of the edit view for product three] I can type quicker with two hands. [puts microphone on stand] holds it here.... Right: so we have a Troy Akeman football [types into teh Title field] I have an image here. By the way these image fields have been set-up for us by Drupal Commerce - you don't have to use that but most people when they're trying to test-out an ecommerce application they want to find that so we put them in there. And the image field is actually attached to my product.
16'39"
You can either attach the images to the product itself or the node that's displaying the product. It's really kind of up to you and the products that you're selling. In this case it probably wouldn't matter. I could have just thrown this image field on the node itself because I'm only going to have one image, or at least one set of images for the football. There aren't multiple different footballs that I'm selling. But imagine if I had different colours
17'
and different styles of football. The brown, or the blue and white, or the Dallas Cowboys celebratory whatever football, you know maybe I would have an option to choose what colour football I want , and so I would want to have a different image appear based on that. So like I showed you with the pinApple store, as I chose a black versus a white piPad or piPhone, I mean it was actually changing the image on the page, because it was pulling that data straight from the product that's actually selected on the form.
17'27" [long pause for question] Yes agreed. Yes it's very impractical huh. Yes: no no.
17'53" Just so everbody heard.
The feedback here was that the architecture makes sense. Like we know that we need like a discreet set of product data [18] that exists somewhere, that isn't tied to any particular disciplin. Like you might have multiple ways of displaying the product; multiple languages, and you might want to keep each language display associated with one discreet set of product data.
But for just the casual store owner. When they come and see this thing, like [they ask] "Wait: why am I going to adminsiter my product data in one place and then manage how its connected to stuff in another place?"
And it is frankly, that we expected and anticipated that this would be the main negative feedback for Drupal Commerce, for [version] 1.0 and it's going to lead into infinity, so you've got to say, look, we can get the archetecture right and then lets throw usability modules on top of it that sort of give us a more expected workflow.
And so what you have is there's a module called the Product Display Manager that lets you manage your display nodes from the back end.
And then what I'm working on is called the Inline Product Form Module that can...
Instead of having two separate places [to edit product display and product data],
you would just edit the node and on your node form you'd have the product added to that as well. I think that's what people are expecting and I think it's what you'd expect.
19
And so the goal was to get [version] 1.0 out-the-door, and see these other modules, sort of get developed that can address these usability concerns.
Some people have also taken to gluing these things together using Rules. And so they've made a Rule Set that whenever you create a new product node it would create a new product in the back end. And associate that with this product reference field that they hid from their users. I'm not a huge fan of that approach because it is tying quite a bit of your logic into Rules, that doesn't really need to be [tied-in]. So my hopes are really set on the Inline Product Form Module. I think that's probably the major-use case for just setting-up a store. Any other feedback?
19'43"
Any other feedback or questions about architecture or whatever?
The question was "Is there a sandbox for that?"...[not transcribed as temporary. By the way "updation" is a good word, newly invented below]
20'
If you go to my user page, I'm https://drupal.org/user/49344. You can get the links to my sandbox from there, and I'll get it promoted as soon as it's ready. Right now - I don't want to get off the rabit trail too much. But I have a lot of fun trying to figure out how to handle the creation, updation, and deletion of entities inside of another entitie's form, without committing all those changes before the main entity's form is submitted. So my module handles that but it doesn't actually have a product display node. So it's just ready for it, but I haven't had time to get it done. But the other stuff are done . The product display manager is available. The Rule sets are available niches [specialised options]. And then there's also a module that I was going to get to in a minute but now I've mentioned the others
20'44"
There's the bulk product creation module. That lists multiple options of products all at once. The module is [called] "commerce_bpc". So that's throw-up like all six different sizes and colour combinations instead of one product at a time. And you know it will get to that.
21'
So we do have our one product here - the Troy Aitken Football that's good to go. We can sell that. I've just added it to my shopping cart. I can go to checkout now and I can purchase this football. Let's talk about the jerseys. Because the jerseys are going to have multiple sizes. I'm going to have my small medium large and extra large jersey. And so the way I want to accomodate that is by first of all creating a new product type, because I am going to have to add an attribute field to it. I think that if you've done ecommerce before you're familiar with product attributes? These are the kinds of things that are basically user select-able options. So whenever they go to add to the cart , you have these groups of the different sizes or the different colours or wattages or whatever it is, you know, that you're selling (between apparrel or equipment or whatever) they can choose on the add to cart form the attribute that matches what they want.
Let me go to my product types here. It's kind of hidden here. Sorry about that. But I'm going to go to my product types tab and add a product type.
22'
The default one: well the default one that you have here [is called] product. It may be the only sort of product that you need. If you are only selling one sort of product on the site you can just go ahead and add whatever user fields you need to that; use it, and if you don't want it at all you can just delete it and create your own product types. It's really just there for new users to use, or for you to use if you only need to use one generic product type.
In our case we're going to add a jersey product type though. And I'm going to [presses a button marked save and add fields next to save product type and cancel under description and explanation or submission guidelines] save and add fields. And on the jersey I'm going to add a size [clicks on add new field button and fills in field marked label] size [fills-in field marked field_] size. [selects a drop down marked type of data to store an selects list]. This is going to be a list text because, you know, I am going to have a discrete number of options available for this. [moves to the last drop down on the line called select list] And this field - I'm just going to leave it as select list.
[moves the line of data up the screen a little by clicking and draggint an x-shaped anchor]
[scrolls to an allowed values list which is the heading over a large blank box above some text saying "the possible values this field can contain"]
Right, now for my allowed values I'm just going to do my
S/Small
M/Medium
L/Large
XL/Extra Large There we go
23'
[presses save] We also have as fields attached to products we have our own custom set of setting here. So these are: this whole set of fields here is called Attribute Field Settings. And whenever I'm adding a field to a product type I can choose to have that field function on add to cart buttons as an attribute. You don't have to expose it if you don't want it to be [exposed]. But in our case I do want this size field to be available on add to cart forms as a selectable option. And then I can choose whether I want it to be a select list or radio buttons. I'll go ahead and leave it as select list but for theming purposes you may want it to show up as radio buttons. And one example I threw-up onto this site before the session is that there is a cosmetics site that is selling lipstick. They want, for each of their options, a colour-splash to show up. Instead of the name of the colour they want people to a actually click on the colour that they want to purchase. And so they would use radio buttons. And then theme the radio buttons to use their colour swatch. And then like hide the actual radio button itself. And it all functions great.
24'
And the way they did that was that instead of using like a list text field, they used a taxonomy term reference field, and they put in their different colour options as taxonomy terms, and because terms are now entities in Drupal 7, they can add an image field to them. So they would put in the name of the colour, they would attach the image to that term, then use that as their attribute on the add to cart form, and then just swap-in the actual colour swatch for the name of the taxonomy term. It worked great! It was great to see that happen. Nobody has made a generic module out of that yet, but in a situation where you need to do that, just know that there are one or two issues [like this] in the cue that are go through the whole process of show example code, and hopefully we'll get that boiled down into an actual helpful module or a tutorial or something.
24'47"
Here we go. I've just exposed - or: I've just added a field to my custom product type that will be exposed to the add to cart form . Let's just create a jersey. Let's go ahead and start off with our
[SKU filed of] TONY_ROMO_S. And we'll do small. And as I mentioned, normally we wouldn't have to set here and type every single one of your different options.
[Title field of]Tony Roo Jersey, Small. I didn't have one of the most recent version of the bulk product creation module available, so I'm just going to go ahead and type a couple of them: I won't do them all.
[SIZE field: Small S]
And these things go for like rediculousness or something - like $80 or $70? And it's Tony Romo. So it's like: $65. I know, honestly I don't have much room to speak because I'm a Colts [sports team] fan. I don't have any room to speak because I'm a Colts fan. [this is the sort of thing you say to fit-in in Texas]. They're leading right now? Oh they're playing the Redskins [team]. OK, I was totally a guess but they're playing the Redskins. I reckoned they would be leading OK. So I'm just going to do two so I don't take a whole lot of time filling in all these different options. But I now have two different
26'
Jerseys available. I'm going to go to the front end now and create a new product display. I'm going to go through content [on the bar at the to of the admin screen] to node content [drops down]. You'll see that I have my new node type here. So lets add a new one. This will be our Tony Romo jersey. And I'm going to put the size and the title. And instead what you can see is if you enter the SKU it does the auto-complete so I'm going to choose my small. And medium in Tony Romo Jerseys. And when I click save and view the node, I should now have a select list. Oh and I forgot to upload the images. Oh well. We have a few things going-on here. One thing we're going to have to change. But first of all you can see that my attribute field is showing up here for me to select something that I can add to the cart. And the way that this works is that the add to cart form looks at all the products that are set to display here, and it says "Hey! These are all the same type. So these should have all the same fields on them. So instead of showing a select list -
27'
instead of having just one select list that said sort of Tony Romo Jersey Small; Tony Romo Jersey Medium, it know that both of these products have a size field on them, and so it can extract from that the name of the field, and the options available, and lets you actually chose them from a select list. And it can do this for any number of attribute fields. So if you were doing this for size and colour and they were dependant, so you only had small medium and large available in red but you had small medium large and extra large available in blue, it would only show valid product combinations. It uses Drupal 7's sort of Ajax stuff to sort of select the appropriate one as you change options on the form. And then behind the scenes it knows exactly which product ID it is referencing,. So when I change this to medium there's a hidden product field or whatever. So I think the product availability was 3. It changes it to 4. And if those products had different prices, then it would re-render that [price] field. So actually I reckon it's good that [inaudible] because we can see that this [size] has been re-rendered, so it says medium instead of small. I call it product field injection. So evey time you have a product reference field, and its displaying in an add to cart form, whenever that add to cart form changes, you can tell Drupal Commerce to update any visible modules from that product on the node, so this node, whenever its content array was being rendered or whatever. I'll see if we can go to development and show you. Maybe not. I haven't looked before. Maybe. Maybe not. Maybe it's not worth looking. Right: it's not worth looking right now. But any time a node or a user or a taxonomy term or any kind of entity that has a product reference field on it is rendered, the product reference field module will also say "Hey! Do any fields from the product itself also need to rendered into this output?" And that lets you show on the page any field from the product
28'
or any attribute of it like the title of the product or the SKU. And so all that stuff is governed by the fields when you attach them to your product and by the display node. So it's honestly this is still like that this is a confusing thing because you have like two different field interfaces [UIs]. You have the field_ui for the node type and the field_ui for the product type. And knowing where to go to change a particular type of display or a particular action can be confusing. So I won't belabour it too much other than to hop-in real quick and disable the size field because you [programmer] don't really need it because I [shop customer] know which size it is because I'm selecting that in the add to cart form.
And so if I go to my content types [from admin menu, drops down from "content"] Oh, lets try the next one that's "structure> content types> product display" I'm going to go-manage my display. You can see in here all the fields that are coming from the product. So the product image, the product price, product is the actual product reference field that shows-up as the add to cart form.
30'
And if you get-on from there you can see the product size field. I don't want it visible so I'm just going to mark it hidden. You know if I wanted to I could show the SKU, I could show the title. Those things are hidden by default. And then I need to do that for my other view node as well. So for Teaser we'll go in here and hide size.
30'30"
Yes: the question was actually how is the reference handled for prouduct data from like a node or a user or whatever? And it's actually a custom product reference field. It pre-dates both the relatation and the reference and everything else. Maybe for [version] 2.X we're looking at depending on entity reference or something similar, but right now it's just a product reference field. The scheme has just one database column. That's product id. And then from that product ID we create the add to cart form or a list of skus or titles or whatever else. Um Yes. So there we go. Yes. Follow-up question over here: red shirt.
31'
So the question was: What exactly is happening with the image field?
And you see I actually forgot to attach an image field to my custom product type here. So lets go ahead and do that just so I can demonstrate. Will the image be spoft[?] in as well? And the answer is Yes. As long as the image is attached to your product type then any field, again, that is coming from the product , if it is visible on the page will be re-rendered whenever that default button on the add to cart form is changed.
So if I go to image and add - I'll just make sure I have an image field - and then if I go edit my jersey products. I'll just use two different jerseys: one that's blue and one that's white for obviisity. There. We have Jaon Mitten. And we do have a Tony Romo I think. Yes there we go. Alright. So if I come back to the product display that has the two different products referenced on it, we'll see the small. The jersey looks really big. And if we change to medium, the jersey looks even bigger. So it's re-rendered as well.
33'
So again this is just a demonstration of what elements Drupal Commerce lets you bring to the table to let you build your product displays. If you get Drupal Commerce out of the box; if you just grab Commerrce from Drupalcommerce.org/projects/commerce. It isn't going to set-up product node types, it isn't going to set-up product types for you. This stuff is happening because we are using Commerce Kickstart. And the idea once again is that we did not want to make any assumptions about what kind of products you are selling. But we do get a lot of tools to build very dynamic add to cart forms. In Ubercart you had to use two or three different modules to get images showing-up, or to produce option images. You couldn't really render fields from your product data into the node. You just couldn't do this. And now we can because of fields and because of entities and because of, specially, the new ajax framework baked-in to the forms api.
Lets move-on to a cusomisable jersey. We're going to go to a Store>add a product. Oh - you know: just for the sake of time I'm going to re-use my basic product type, and just show this.
admin/commerce/products
34'
So not only can we add fields to our product types in our add to cart form. We can add line item types and have those show up on the add to cart form. So let me come over here to Store>configuration>line items. And you''ll see that I have one product line item type. And the way that the cart works and the way that the orders work in Drupal Commerce is that when you ad something to the cart, a product line item is created for it , and attached to an order. So as soon as somebody clicks add-to-cart they have a full order object. There is (like) no pseudo-cart order object thing. It is like a full order with revisions that keeps track of additions, deletions; it saves what ever data you try to add on the checkout form as soon as possible, so you're not loosing a lot of that valuable marketing data that we weren't tracking before.
34'50"
And so a line item is anything on the order that feeds into the price. It could be your products, or, once I install the shipping module, it could be a shipping line item. For certain kinds of discounts it could be a discount line item. Also for those fields - you can add fields to them and expose them to the add to cart form. So that before somebody submits add to cart they actually specify additional data to store with that product line item in the order.
I don't want to use my one basic product type and add fields to that, because then every time I add products to my web site they going to have the customisation options. It doesn't make sense to ask for somebody's last name to customise a football - their autographed football. So I want to use a different product line item type from my customisable stuff versus my basic products. I have a module that's sort of in the works. I need to finish it up (I'll install some other stuff as we go). I have a module called customisable products - if I can find it! - oh there's the inline product form module - that will let me create additional product line item types for use with different types of customisation. And other areas you might need this would be things like a donation form where you want someone to specify a custom donation amount. And use that amount they specify as the sort of unit price of that line item in the shopping cart. If you go to commerceguys.com there's a great tutorial by Randy Fey that demonstrates that right now. You might also use it for event registrations where the product is a different level of event registration, and then the different fields they have to fill-in our their name, attendee name if they're registering other people, email address, company name, or whatever else. You know - "name on the badge" versus "name on the form".
And so there are many different use cases for creating custom product line item types. We originally developed it for one of our clients that was selling customisable T shirts and lighters and whatever else. They needed to store these design tags with their line item but they had other products that didn't need that stuff. And so we needed multiple types of line items that would function as products in the cart.
37'
And you see now I have installed my shipping module so you see I have my shipping line item type. I've also installed customisable products , so I have this new "add a customisable product" link that I can use to add a customisable product line item type. Well we'll just go ahead and use custom jersey because it's available. Save that line item type. And now I have two types of product line item. So that means that when somebody clicks add-to-cart , we can use either one of these things. The customer jersey line item type or just the basic product line item type. Lets go ahead and edit this one because I am going to go and add my text field. This is for custom jerseys to capture the [add a text field] custom name. And we'll make this just a basic text field. And save. Alright So: we've got the next link [button marked "save product fields"] and so just like with the product fields we had that additional field set where you had your add to cart form settings with fields attached to line items.
38'
You're also going to have add-to-cart form settings. And this one is just a single check box that says "include this field on Add to Cart forms for buy items of this type." So I am going to go ahead and save this and then go and view our products. Lets go back to our Troy Aikman Football. And if you look at this add-to-cart form you will notice that there is no - you know - no name field visible. We can add this to the cart. It doesn't ask me for my name even though I made that a required field. And the reason being: this add to cart form is using the basic product line item type. It does not have any additional fields associated with it.
Let's go an refocus on Product Two. Product two is - let's see - our custom jerseys. Let's go ahead and add a product. Make this a jersey. And this is our custom jersey. Let's write that (SKU) down again. And this is a small jersey. And this is very expensive. Click image. Choose a file. Choose "custom". Right. Now I've got a product now that I want to use my custom jerseys. Now what I want to do is figure out how I want to get this product associated with the different product line item type. Usually what you do is add another separate type of product display. One product display is for my regular product line items. The other one is going to be for my custom product line items. The reason for that is the setting that lets you specify which product line item you want to use is tied to this add to cart form. And this add to cart form is coming from a display formatter. So you have to have a separate node type to have a different set of display format settings. I know this is kind of confusing. Lets go ahead and add this. A new content type called a custom product display node. We're going to add fields to it. In this case just a single product reference field.
40'
Oh and here's the checkbox here underneath "required field" which directs you to "include some reference products". Again there are so many things that we are injecting into the field forms that I know that all of this is going to fly right over your head until you use it, but at least you are aware that this is how Commerce works. It is working through the existing field system. And then you pull all these Commerce pieces together. But if I go to look at my display, I have my product field here. Let's go ahead and hide its label. And it is displayed as an add to cart form. You scroll over here to the right. This is new for Drupal 7 so if you haven't yet used Drupal 7 you don't know about this, but you can have settings for any sort of display formatter now. And in this case the settings for the add to cart form are: should it have a quantity of Widget? Let people say they want 1, 2, 3 of these at once? What should the default quantity be? Should like items be added to the same product that's added to the same cart? Should it show up as a separate line item or should it just increment the quantity of the existing line item? And then the very last one is the add to cart line item type. That's set to Product because that's just the default. Lets go ahead and edit this. Change it from using Product to Custom Jersey. So when I hit update. I go create products of this node type. You'll see the add to cart form with the little name text field. Lets go add one. Add content. Custom product display.
Its making me nervous having that thing next to the computer - my last mac was trashed by electronics falling on the laptop.
I'm not going to go through the full setup here because it's taking a lot more time than I anticipated. But you see now that the add to cart form has a custom text field that I didn't have to specify. And this data, because it's just field data. It's not like we're attaching it to an array and then serialising this data and adding it to the product in the cart. That's what Ubercart does with its attributes. Instead this is field data that can be attached to the line item of the product in the cart. You can get to this data using Views; you can get ot this data using Rules. Whatever you need. So if I was usingthis system for event registration, I could build a massive list of all the people registered for my event by just producing a View of this particular Field. And in this case this field maybe shows the order number that that came from, and whatever else you need to do with it. And according to Randy's tutorial on donations (you know: custom donation products), because this is field data: Rules has access to it. And with Drupal Commerce you can add product pricing rules, that will take the price and alter the price of the product before its added to the cart based on whatever parameters you need. So that could be: you just look at the field like the custom price that somebody specifies as their donation amount would be the price of that product added to the cart.
The question at the back.
43'23"
The question was pertaining to custom pricing and discounting and what-not.
What Drupal Commerce does is that it runs every custom-pricing rule through a single event that it calls "calculating the sell-price of a product". And so this is all done through Rules right now. There are reasons for it that I can explain afterwards. But you have under your Configuration Menu a product-pricing-rules-item, and that lets you set-up your discounts, sales-tax, fees, price lists, currency conversion: whatever, all using Rules. In this case, lets go ahead and just make this a "half off day: half off everything". Save. [curser hovers over "add an action" link] And what I am going to do is add an action to this, called "multiply the unit price of a line item". Because whenever you calculate the sale price of a product, it's done through a pseudo-line item. So when Commerce is about to display a product price, what it asks is "what would the price of this product be, if it were in your shopping cart, right now". So it creates a line item that doesn't save that would reference your order and reference the product, and it passes it through Rules so that anything can operate on that to change the price, add tax, whether it's VAT or sales tax or whatever, and then spit that final price out as your purchase price for the product.
So we're going to thumb-through the line items. I am selecting a "line item action". That's going to multiply the unit action called "multiply the unit price by some amount". In my case I'm going to multiply it by 0.5. And I am going to say that this should show-up on the checkout form as a discount. And I'll choose how that should be rounded, if at all. And now if I go back and look at my product page. I had some footballs in my cart. They automatically got updated to be ½-off, so that's $30 instead of $60 (they'd be cheaper if americans didn't bother with leather, silly arses) and notice that whatever is going to be in your shopping cart is always going to show the most recent price. That's called the "shopping cart refresh". So somebody won't have stale data in their cart if they come back a month later and prices have changed: it's always going to be updated. If you go to checkout: you can actually see that this will show-up on my checkout form as my half-off discount. So all that stuff is tied together and done through Rules.
The same is true for taxes so if I go back to store>configeration>taxes , lets add a Texas sales tax. I think it's 6.25% is that right? 8.25% - oh it's changed. Move to Kentucky it's cheaper [the UK's NHS service runs for only 10% of GDP so although taxes are higher it's cheap too]. And now that I have that tax on there, of course, go-up, and it's an error! This always happens, doesn't it, on tech-demos. OK. It sill still show-up here. I'm going to have to debug that later. I haven't fully tested everything against the latest version of entity api apparently, but you can see that I have my sales tax, which if I am not mistaken is going to come-up at a discounted price but I can't do the Math that quick. So here we have my Texas sales tax. Total $34.95. And all this stuff is coming from a price field attached to the order and it just shows the breakdown. We have what we call "price components" so every price, whether it is a price on a line item or a unit price, or a product sell price, or or the order in total price or the order itself. All these prices have in themselves a change-log of how that price got to where it was. What pieces went-in to making this-price this-price. That includes the base price of the products, discount that came off it, the sales tax that was added, and you can use that to build custom price displays to run your reports on how much tax was collected or whatever else.
Question up front?
The qustion was: Can we have a tax by product? [47.08]
Yes. You just use Rules to change the conditions for the applicatbility of that tax.
So if I went to my store menu again (and I have kind of run-out of time or I would have cruised-through a lot of this stuff) if I go to my taxes menu [bottom item] you can see my tax rates. You can see there is this ambiguous operations link here [right hand side] which is called "configured component" and in Rules-speak what that is is a kind [?] subtlety that detirmines whether this tax should apply to something. So if I go in there, you'll see the full Rules user interface where you can add conditions that detirmine whether this particular tax should be applied to the line item. So I can make this detirmined by some atrribute of the product itself: maybe food items aren't taxed and jerseys are. I can make that detirmined by the shipping or billing address of the customer. Most places it's detirmined by where you're shipping it to. So I would want to go and check the shipping address and make sure that it was Texas before applying the Texas sales tax. So that, again, is all done through Rules. And this all comes through the product pricing system. So product pricing rules is your main point for adding discounts, and taxes, swapping-in prices and custom prices, and price-lists, and everything else.
I can't remember the other objective I set myself for showing this site. I was going to show discount shipping. I don't have time to go through this and build it. So just real quickly I can show you on realmilkcheese.com. Actually this is my first ever personal e-commerce web site. And it actually is responsive so lets see if it works for us right here. The pressure's on [typing and waiting]. Realmilkcheese.com is just a very rushed-out website selling an Amish farmer's cheese. So it's selling raw milk goods, it's kind of yummy, but it's kind of expensive. So what we're trying to do is simplify bulk purchasing. If customers buy $100 of more of his cheese they can get free shipping. What I did was I used the shipping module and the flat rate module . This is Shipping [module version] 2.X. If you are about to use a commerce site use the 2.X branch not the 1.X. And then another module called Flat Rate. Also confusingly, this is not the Shipping Flat Rate Module; just the Flat Rate Module. I'll have that all cleaned-up on the shipping project page soon. So what we did was use the Shipping Module and the Flat Rate Module to - oh! security updates! Great! I've just gone and shown everybody that I have an insecure website! I have my Flat Rate Shipping Method and if you look at the services that I have defined for Flat Rate, I have a "Standard" and a "Free" shipping method. So my "Standard" is 16 bucks or something; free is going to be $Zero. Free is only going to be available for orders that total over $100. So that's easy enough to do.
Just like with Taxes you have a Configure Component link; you have it here for shipping as well. So I just go in here and add a simple Condition. That evaluates, or compares against the order total: "Is it greater than $99.99?" (These comparisons are done in the minor unit of the currency so comparisons are done in pennies or cents or whatever else, so just remember that when you are setting-up your pricing rules). In this case the order is over $99.99. The free shipping should show-up. If it's under $99.99, then standard shipping should show-up. The problem that I ran into was "What if someone selects Standard Shipping and that bumps-up the total to over $100? - then suddenly free shipping becomes available". What we had to do was we added some conditions into the shipping module itself that lets you also specify: "Is the order total over $100 in itself, and the order doesn't have shipping applied to it?". So if you're setting-up rules for shipping, just remember that you have to have that exlusion, because someone could go forward and checkout, save their order, and then come-back and choose the free option and go for it. You don't want that to happen. So you have got to use both things: the data comparison, and also the check that they don't already have shipping applied to their order.
That's how we set-up free shipping. With the Flat Rate module it's very simple to add just as many flat rates as you need. Then with the Shipping Rates again once the base rate has been calculated, coming from that flat rate, you also run that through Rules again, to manipulate the rate further. So if you do weight-based shipping where it's $5 + $3/pound [of weight]. You do the same thing by setting-up a flat rate for $5, and then you use rules to add a conditional $ to it per pound or $3 per pound. There's a lot of stuff you can do using Rules and using the Fields about those Rules that we have set-up [pointing at a part of an admin screen under config>workflow>rules>components - worth looking at at full screen mode] headed "Conditions" and then boxes for "ELEMENTS", "OPERATIONS", repeated under another heading of "Actions".
And we are out of time here and I regret running out of time and I regret that we haven't really cracked the demo. If you have any questions, I'll stand out in the hallway and feel free to come and bug me with them
you're welcome to bug me with them about Drupal Commerce. Thanks for paying attention and for bearing with me, and I'll see you guys next time.
[answers another question - Oh yes? What's that? Sure, Sure]
Two things.
- There's real milk cheese here if you want it, right up here. Actually I have half a brick of smoked pepper and applejack so if you want some of that come and ask me.
- We're doing a full three million dollar training down in Florida next month .... go to ctraining.commerce on Drupal for that. There are also (paid for) videos on Lynda.com and (paid for) videos on Drupalise.me so there are all sorts of resources out there to teach you how to use Drupal Commerce. [+ https://www.ostraining.com/blog/drupal/ for non-commerce text instructions]
Transcription: translators see this footnote
Some of the jargon is italicised, more or less at random.
Speaking style is Germanic English with maximum hyphenated-together-words.
Sentences are unstructured and meaning depends on context a lot.
Some apologetic linking words like so and and are added to the starts of sentences. I have taken a few of them off again in transcription. Translaters will have trouble.
Transcribed videos about Drupal 7 and Ubercart 3 which are meant to provide a quick way of writing an ecommerce site: - [Drupal 7 / Ubercart video tutorial 7 of 10 showed how to use the default catalog module] [Drupal 7 / Ubercart video tutorial 8 of 10 showed an alternative flexible method of showing a catalog] [Drupal 7 / Ubercart video tutorial 9 of 10 shows how to use product kits, stock, and order states] [Drupal 7 / Ubercart video tutorial 10 of 10 shows a simple checkout, reports, and suggests a theme]
No comments:
Post a Comment