 Okay, yeah, so this is, I shouldn't turn away. This is Dr. Will My Drupal 7 Commerce Site Survive the Upgrade, in which I'm going to be talking about my experience looking into that question, upgrading from commerce 1.x in Drupal 7 to 2.x in Drupal 8, how it went on my site, and some tips that anybody can use to evaluate whether they should do the migration now or later and what they might run into along that. Okay, so this is the slide where I usually put my name, but since they had that other slide, I can just explain other things about me. So my username is whiz1solutions, which explains the hat. And the logo also explains the hat. It's the little thing above the O there. I maintain the PhilPDF module on Drupal.org. I've been doing that for like, geez, like seven years now or something. And in conjunction with that, I also have this thing called PhilPDF service. It's a third-party thing that works with it to make it work if you don't want to set up extra software on your server. And I mention it because it's the site that I'm going to, it's the site I'm trying to upgrade to, to the latest Drupal commerce for various reasons that I'll tell you about. Three other things about me. I like singing, which you might know if you saw the pre-note. I got them to play a weird out song at Drupal con New Orleans on the Drupal radio hashtag, and that was fun. And I like languages, some of which are depicted here. About, yeah, a little more than six. So the site that I am trying to get upgraded or that I tried to get upgraded is PhilPDF service. It looks somewhat like this. You know, typical menu. It's a pretty small e-commerce site because mostly developers convince their clients to use this and pay for it, and then they just come, they click the pricing page, they subscribe, and that's it. And they never really have to look at the site. So I haven't focused a whole lot on the design, as you can see. It's a stock theme, basically, with some color. Pricing page looks like this. We've got some subscribe buttons. You know, prices, a little bit of a description of what it is. And this is also the upgrade downgrade page. So if people want to change their plan, go down, go up, they come here as well, and then the subscribe buttons turn into switch plan and cancel buttons. If they're logged in and the site sees that they have a subscription already. So it's doing double duty there. And then we have the beautiful profile page, which is most important in that it shows them their usage so far and when they have to pay again. That your plan renews thing at the right. And then, like, little other stuff that I just didn't take off of the page. You can see some of the very nice theming jobs that I've done on here. It's very developer-oriented. Okay, so what is this site like? How many customers and whatnot? Just about 40 subscribers, so not huge. You know, like, small, basically small, but it's nice. They're good subscribers. I'm actually on Commerce Kickstart 1 because I was lazy in the end. I was like, yeah, I'm going to do Commerce Kickstart, and then I'm going to go to Commerce and redo it like the lighter, the more lightweight way, and then I didn't because I was tired. But it works. The main sort of modules I'm using are Commerce Stripe, a module called Commerce License, and another one called Commerce License Billing, the so-called licensing ecosystem in Commerce 1. License is like to give them the role, for example, when they pay, and then billing is to make them pay money every month and handle that recurring thing on my side. I decided to do that instead of using, like, Recurly or something just because I like the flexibility. And then I have some custom code for stuff like quota management. That's how many API calls can they do before they have to upgrade their plan or whatever. And if they opt in to be able to go over their limit to charge them for that, that's the metered billing, upgrade downgrade form, the pricing page, I explain that. And apparently I'm getting the trees blink a little bit. I'll just call it the trees blink because that makes it sound cool. And then page alterations, you know, like just doing little things to the user page or whatever. I don't have much of that, but I do have it in there, so it is technically custom code. So we get to the big question. Why upgrade? And before getting into that, it's worth looking at how I got to where I am on Drupal 7. I started out on Uber cart as many people in Drupal 6 would have. And Drupal 6 was reaching end of life, like, in February 2016 or something. So I was like, okay, well, that's an excuse to upgrade. Might as well try to do it. And I did, like, on and off. I worked on and on and off over a year, about 300 hours in total for, like, everything. Probably some excess time that I logged there, but more or less that to plan and do it. And also to, like, try to go to Drupal 8 first, because commerce for Drupal 8 was getting worked on at the time, but it wasn't ready. So I was like, okay, Drupal 7, because I am only one man. And anyway, so once I did it, I used commerce migrate for basically all of the data. It actually worked really well for Uber cart. I basically got everything over. I was pretty impressed with that. I had to port my custom code that manages the actual API service that it provides, obviously. I switched to Stripe. I was on PayPal in Drupal 6, and I basically just canceled all the subscriptions, and I was like, yeah, go to your account and put in a credit card, because it's only 40 customers. So it's pretty easy to just follow up with them manually if they didn't do that, which some of them didn't. I think everyone has now, so I don't regret just doing the hard cut from PayPal like that. And I'm very happy that I'm off of PayPal, because I haven't had any inquiries on how, yeah, I want to switch my plan. They can just do it themselves. Works great. And as you see, I colorized the stock theme. So why do I want to upgrade now? Mainly for tax reasons. I have to get my VAT sorted out, and it's a little bit hard to do it in Drupal 7 and get it to work exactly like I want with all of the digital VAT that's going on now in the EU. And this is in core in commerce, too. So it'd be a lot easier to get it working there. Also, to make it easier for myself when I go to Drupal 9 later, because they're just going to remove all of the deprecated stuff, but it's not going to be a gigantic jump as much as 7 to 8 will be, so I sort of figure, okay, well, that's another reason to get it out of the way now than going to commerce 3 or whatever it is at the time will be easier. And I wanted to go to commerce 2 last time, but it was early. You know, when they said they'd have, like, a production ready beta in March or something, and then it came in September and whatnot. So it took a while to get there, but now I feel like it's there. So how does one... How does one try to do an upgrade of this scale? There are a few options, specifically for going from commerce 1 to commerce 2. You could just try to do everything yourself, and I have some images to illustrate the relative difficulty of each of these. This is probably the hardest if you don't use migrate at all. If you have a very small site, it might be practical if you have, like, two customers in, like, five orders or something, I don't know. Maybe you could just put them in by hand at that point. You could also do custom migrations with migrate, so you're still using migrate, but you're just not using commerce migrate for some reason. That's a little easier. You could use commerce migrate, which I sort of recommend, at least partially. And depending on what you have on your site, it could be easy, or it could be this. Water bottle pool shot. But, you know, most likely you're just going to have to plan it and you'll mix and match and figure something out. So, next question is, what is contrib like in commerce currently? Like, what happened to all the contrib modules in commerce 1? Are they ported or whatever? And so I picked some of the ones that are on this top 50 spreadsheet that they have telling what's happening, and mostly ones that are enabled on my site. First, commerce migrate itself. Yeah, it's not quite ready for commerce 1 yet. They're still working on it. They're working on uberkart first, because apparently that has some common stuff that's going to make it easier for them to do. The migration from Drupal 7, so they're expecting the one for Drupal 7 to be ready like mid-October or late October, so plan for December or so. That's what I'm thinking. Yeah, I just already said all that. But it is somewhat working from commerce 1 already. It's migrating orders and products like half decently. I saw a lot come through when I tried it. There's some stuff to work out there, but I have some custom stuff going on, so that's probably why. A big bug in the dev version right now is that line items and therefore orders aren't migrating properly. I patched that, so that's how I knew that the rest was working somewhat decently, and I hope that they'll commit my patch soon for that or fix it themselves, but it needs some time, so yeah, I'll talk more about how to deal with that as we go on. And some other, you know, slightly important stuff also needs to be worked on. So commerce migrate, not quite ready yet, but getting there, getting there soon. So let's look a little bit at contrib in general. Commerce shipping is still a separate module. It's got a beta release going on. I don't really use it, but it is something that a lot of people use, so it was worth mentioning. Commerce features is obviously in Drupal 8 core now and it's a version management system, so don't really need something separate for that anymore. Addressbook is almost in commerce. It almost made it, but they didn't quite finish it for the official commerce release, so it'll go into the next release or something. I was expecting to have to change this, but yeah, didn't quite make it yet. So discount and coupon are in commerce core as the promotions feature. The equivalent functionality for this commerce message for working on the emails and what not and logging of them in commerce one is in commerce core in Drupal 8 now. There's a port of this commerce auto skew module going on where it just makes up a skew for you, so you don't have to think of one when you're entering a product. I just told you about commerce migrate. Commerce reporting is not really in progress. They say that they need funding on their product page, so if you're interested in that, throw money at them. And commerce billy is going to be, this is a module for basically producing invoices like PDF invoices. I use them for PDF invoices in commerce one, and apparently that's coming in the next release of commerce, so looking forward to that. The trees flash again. Okay, and then stuff that I care about more, the whole licensing thing, because that's sort of the main part of my site, commerce license is already being ported. I'm kind of following that. And the license billing functionality is going to actually go into the commerce recurring module. Commerce recurring is going to become a module for both, for all kinds of recurring scenarios. So that's going to be nice consolidating that. And they already have architecture for it. It seems like one big name or another contributor is going to work on it, so I'm feeling good about that. It should come relatively soon. Commerce Dunning, when I asked Bullion if this was going to go into commerce recurring, he said, sure, why not? So I'm taking that as an official statement. Commerce VAT, as I mentioned, sort of about taxes and whatnot, is in core. So that's great. I don't need any of those VAT modules anymore. You can just set up taxes and it pulls all the rates and everything from some reliable source, and it works. I think in the U.S. they have this partnership with AvaTax or something, but in Europe it's in core, so that's all I really care about. Commerce Stripe already has a Drupal 8 version. Instead of using Commerce Checkout, the so-called Stripe Checkout iFrame, they're using the Stripe elements like iFrame, but it looks like it's on your site sort of thing. But you can still go with the lowest level of PCI compliance, so it's usable. And then there are a few other minor players in the payment space that have modules in Drupal 8, authorize.net, who's heard of that and whatnot. And so that's sort of an idea of where some of the modules that I care about and our big names are currently in Commerce 2. So the question is, okay, well, there's obviously a gap there. If you wanted to upgrade now, you would have to do some things yourself or figure out alternative approaches for some of that. So what questions can we ask? What can we do to get around this? So in my case, I was thinking like, okay, well, do I need all of my contrib features right off the bat? Some of them are in core, but can I just like ignore some of them to start with? Maybe some ones that people aren't using that much or whatever or that doesn't add much value to the site. You know, reducing scope as it were. Is it in Commerce 2? And can I contribute something to make it work if it's something that I really need, like commerce license or commerce recurring? That's probably somewhere where I'm at least going to test the stuff that they're doing and try to give them feedback to make it go faster. Also, can I just do custom migrations for some of it if when Commerce Migrate gets to the point where they say that it's working for Commerce 1, for example, if there's some stuff that's not coming through, can I just do it myself? Migrations aren't too hard to write anymore. So that could be a possibility. And for more information on custom migrations, I have a resources slide that you'll be able to look at once I publish these slides. So there's a good blog post there on how to do it if you want to look into that. And then also, what do I do about my custom functionality? Port it, basically. That's one thing where I can't just wait for someone else to do it, the API and whatnot. But I expected that, so that's normal. And then I have some specific thoughts on what I'm going to do about some of the specific modules that I need that aren't ready yet for Commerce Migrate, help them test it, help out with the port. We contributed one patch to that, so I'm going to keep doing that. I could fill in the gap with custom migrations, like I said. Commerce license, I'm going to help them with the port if not just trying it out and trying to get it going. It's coming along pretty well. I think it's almost there for the basic use case, at least, but they're definitely going to add more stuff to that. For recurring, basically the same thing, help out, because that's very central to my site, so I kind of need that to come along. I had an alternative, you could say, of just using the Stripe subscriptions, but I think that would take about as long total as just helping to get the Commerce recurring and whatnot modules to work, because I would have to do a whole integration with Stripe subscriptions and import my data to it and set it up and then make sure it works. I would lose the flexibility of just managing stuff right on my site and have to synchronize that and all these things and be more of a hassle than it's worth. And then, the ones that I don't care about as much or don't really need reporting, I can just use SQL queries. Commerce Billy, I can just like, I don't know, I could re-theme the invoice page or the order page for them and make sure it shows all the stuff that it needs to. Like, it doesn't have to be a PDF to be a valid invoice. Address book, they're not on the checkout page very often buying stuff, so they can just put in their information every time. It's a little inconvenient, but it's not like site-breaking. And I can type my own SKUs for products. I can spend the 10 seconds thinking of one, so I'm gonna do that. And in terms of porting custom code, it's always nice if one can save time on that, so I can also think about, like, do I need the specific feature in question? For example, I have some code that handles grandfathered users, like people from previous versions of plans and whatnot, one-time users and whatnot, and I'm probably gonna deal with them before I start porting my code, so I'm just gonna be like, yeah, one-time users, do you just want your money back? Or do you wanna get some free time on a monthly plan and just, like, remove that whole use case, so I don't have to put in... So I don't have to port that legacy code again. Stuff like that can save some time. I don't have a whole lot of features, so in my case, everyone probably uses everything, at least from the custom code point of view, on your site, maybe that's not the case, maybe there's some little used feature that you could get away with not porting right away, save some time. And also, I'm probably gonna have to put a few patches on my site to make it work, so that's pretty easy now that everything is using Composer. You can just put it straight in the composer.json file that lists your dependencies and then forget about it more or less, except when it breaks. But, you know, you should think about if you want to have patches on the site or if you just wanna wait for stuff to be official, depending on how big the site is, how official it is, how much the client tolerates dev and beta stuff, you know, your decisions will be different. And then, in my case, for the license-recurring logic, what am I gonna do to port that? It's gonna be pretty similar now, I think, because it's the same guy doing the architecture for the modules. So I think there will be a lot of commonalities. I'll, you know, have this so-called custom license type. It's not really that important what that is, just that I have one and that I'll still have one. For billing, obviously, I'll be going to Commerce Recurring because that's what Commerce License Billings functionality is moving into. But I don't know exactly how that'll look from a code perspective because there was some talk of having a user interface for more of the metered billing stuff so you might actually just be able to set it up somewhat in the UI, at least, and that would be nice. That would save me time. This was probably the most difficult part in Drupal 7, getting this to work properly and figuring out all the APIs because I think there's like five people who use the functionality. I'm probably in the top 10 of understanding how this works in Drupal 7, at least, just from having implemented it. So I hope it'll be easier in Drupal 8. And then the whole upgrade, downgrade, cancel functionality for plan management. I think it'll still be custom. I hope that there will be new APIs that make it easier to do because that took a long time as well because there was no real templates for it in Drupal 7, and I never got a chance to try to extract what I had done and make something either, so hopefully other people will do that for me in Drupal 8. This one's easy, the visual tweaks. It's just twig, and that's basically the answer. I also, when I was going from Drupal 6 to Drupal 7, I had some custom data that I had to move over in migrations, and maybe you would have something similar, so I thought I would mention that. Obviously it's done with the migrate module, but for those of you who are a bit familiar with migrate, just know that migrations are plugins now, so you don't, if you look at old information, it used to be configuration, and then if you're like me, you'll spend two hours trying to re-import the configuration to use the new migration, and then realize you just had to rerun it and feel very, feel very silly. So some examples of custom migrations that I had and will probably, will mostly still have, giving users who are on the old site, like this grandfather D7 or D8 role or whatever, just so I can identify existing customers, because I usually change up the plans every time I do an upgrade, so I can control what they see on the pricing page, make sure that they can subscribe and switch over to the new plan or whatever, or not if they can't, think little things like that. Very important migrating the subscribers so they can still use the service seamlessly after I do the final upgrade, although I do hope that that'll just be done for me in commerce license or commerce recurring, and I don't have to migrate API keys because I made them a field in Drupal 7 and fields are already working in the general Drupal 7 to Drupal 8 upgrade process, so that's nice. It's nice when things get added. So, getting a little bit into the, I guess you could say the intermediate part of the session, dealing with rules, which is like, I think it's one of the big questions, and in fact, in Boeon's session yesterday about looking back at the commerce development process, someone asked him this question, so I'm gonna answer it again in a little more detail. What happened to the rules? Instead of using rules in commerce too now. They, oh, I was already showing that. Yeah, they went into these four things. We have events which are the symphony, the whole symphony event subscriber thing, that they have now instead of the hooks from Drupal 7. We have these things called resolvers, like price resolvers and tax resolvers, order processors and configuration entities. I'm not going to into each of these things, so don't worry if that doesn't make sense yet. So, first we have events. Events are things like order state changes, modifying the entity, deleting the order, adding an item to the cart. When stuff happens, as it may sound like. And this is done with code, a lot of stuff is done with code in commerce too now. And this is an example of how that might look. So this is from the commerce cart module in commerce core. What it's doing is it's just before it's going to go to the place status, which means that the customer has placed the order, it does some work to finalize the cart. So whatever that is, that's what it's doing, because obviously they're using a little Drupal 8 service here to actually do it. They're finalizing the cart when the order is about to be placed, probably putting stuff in the database and making sure the status is right and all that. The second thing is resolvers. Now what's important about the concept of resolvers versus the next thing is that these determine the price of a single thing. So like a single product in the store. For example, if you're adding VAT to a specific product, then this is how it would be done. In that case, it's a tax resolver. And there are also resolvers for tax and shipping. And these are all separate things because with a resolver, the first one that runs and tells commerce that it has something to do is the one that wins. So whatever returns a price, that's what the price is going to be and then it ignores the rest of them. So this is what that looks like. The service in the services.yaml file of the module. In this case, it's the commerce price module just with this default price resolver that it uses, which probably just checks the price on the product and shows that. Nothing fancy. And then we also have these things called order processors. Order processors determine adjustments to the entire order. So if you have like a 10% off the entire order, regardless of what's in it, then you would use an order processor to deal with that. In this case, it can actually remove the... it can do other things to the order and then change the price as well. It can remove it from the cart. So again, it's a service that defines where it is. And then this code is saying, if this thing is out of stock, don't let the person buy it, which is a pretty reasonable thing to do. Because then you won't have to cancel the order and make them upset. It's order processors. And then finally, we have the so-called configuration entities and conditions. And in Drupal 7, this was for things like selecting the payment method, which may have confused some of you. I know it did me the first time when I had to use rules to set up the ability to pay, but now it's easy. You just go to the payment gateway's configuration screen, select what you want, and then you can select the conditions in which it shows. So you can limit it by these things. You can also limit it by some stuff having to do with the order. You can say if you need one condition or all to pass and whatnot. So it's very much more in commerce than it was before. And I think that for this case and for the other cases, it probably makes more sense than using rules, especially now because rules isn't ready. Hopefully you'll also be able to use rules for some things later on once it actually works. I'm certain that that'll be the case because it lets the end user configure a little bit more and not have to write any code. But this is how it's done right now, and there's definitely benefits to it. And it's possible to add your own conditions as well, obviously, if you have some that are not covered in these. So that is where the rules went. In terms of who may benefit from upgrading now, obviously it depends. I mean, what else can I possibly say? Everyone's site is different. But I do have some thoughts on the timeline of when to migrate. If you have tons of money, you might as well start now because you could probably pay for whatever you need to. And not saying that I'm biased or anything, it would probably be good to contribute to commerce migrate. I'm completely... I wouldn't benefit from this at all, just for your own benefit. Do that. Or just pay a developer to write custom migrations. That would also be possible. I mean, if you have a lot of money, you can just do whatever, right? Not really, but bigger budgets can obviously contribute more, and I think they should. If you're me, probably don't migrate yet. Wait a little longer for commerce migrate to come along mid-October, late-October, or whatever realistic time that actually comes out. Alpha 3 is the version that you're waiting for. If you're sort of in between and you have some weekends or some time to contribute, then do like I plan to do and help test or write some code, contribute to these modules. That'll help it come along further. And you'll avoid being in a situation where you've done a whole bunch of custom stuff and then the official stuff comes out and you're kind of in your own world and either you're just stuck there until Drupal 9 or forever or have to sort of cross migrate to the official stuff. That's why... And then that is an additional maintenance burden as well. And if you're in this situation, you probably don't really want to maintain too much custom stuff because it takes time. It's better to have someone else think about the hard stuff. Yeah. So the main points. Have realistic expectations for the upgrade. It could take a while. On and off for me. It took me a year last time, so I'm not expecting to get done in a few months. I would love to, but it probably won't happen. I thought it would be a few months last time as well. You know, everything takes longer than it takes, as they say. Collaboration pays off for the reasons I just said. It makes upgrades easier and it makes your stuff work with other modules in the ecosystem more easily without having to integrate it yourself. That's why it's called an ecosystem. And use commerce migrate. It's probably going to save you time just to wait a bit for it rather than doing everything yourself because that'll take a couple months anyway and it could be out and then you'll be like, why didn't I just wait? Just spent all this money doing this. And questions? Please ask me some questions. Just come up to the microphone if you have some. So what were some of the major roadblocks you hit along the way outside of commerce migrate itself? And your migrations? Well, the main roadblock was commerce migrate. So that was kind of the starting point for me and when that didn't work, then I just looked in general at the other stuff that I would have to think about along the way, but not that much actually. I mean, installing with Composer went really well. And I pretty much have plans for everything else. It's just mostly that I need to get the data over so that I don't have to write some hackety system for people to get their old invoices or have them email me and be like, yeah, I need this invoice from 2014 and then I have to fire up some virtual machine or something and download it and send it to them. It's nicer. I was really happy that when I went to Drupal 7 most stuff came through and it was just there. So waiting for Drupal 8 to reach that point. I know that wasn't exactly the answer to your question, but it was the only answer I could give. Yeah, please. So if your site was still running on Drupal 6 and UberCart, what would change? Then you don't have to wait as long because UberCart is coming first into commerce migrate. You only have to wait basically for the next release, which I guess would be pretty soon if they're targeting Alpha 3 in October. Yeah. Did you have a comment, Matt? Okay. Sounds a lot like Commerce 1 as well. Yeah, so for the... Yup, yup. So the summary of what they just said that you might not have heard because of not being on the microphone is that it should be around end of Vienna or they're targeting kind of end of Vienna for an Alpha 2 release of Commerce Migrate to get UberCart working. So pretty soon. At worst case, matter of weeks. And then sometime after that, the next version in which they will have built a lot of the building blocks to make the migration from Drupal 7 work, the next version will include that, a lot more of that. Next question. Hi. This is maybe not a related question to migration. I'm starting a Drupal 8 commerce site right now. I'm going to find a difficulty find modules which have been ported or have not been ported. Do you have any suggestions on where to find them? Yeah, so I'll just skip ahead for a moment. So I have a link to the status of at least the 50 most popular, which is a spreadsheet. It's also pinned in Channel Commerce on Drupal Slack, which will give you some idea if you're wondering about one that's not on here. I'm sure that somebody there knows Boeon. Thank you very much. Wow. So you get 10 for free in the top 50 list. And then you might have seen there was a separate one for payment gateways, as well. And then there's also this section that some guy wrote about adapting from 1.x. So it's definitely in progress, but coming along. So you'll be able to look at all this stuff once I publish my slides. Next question? About the migration or just Commerce 2 in general, stuff that I might not have answered that you're wondering about? Going once? Going twice? Okay, sold. Right. So the off-dimensioned resources slide, I've already explained three of these, and then this last one is that blog post that I was talking about, which, as by the lack of a date in the URL, is like this evergreen explanation of how to write custom migrations for Commerce 2. And it's pretty detailed. I think we're going to need one. Definitely look at that. Oh, I think Bullion is going to add something. Yeah, just wanted to say that we now have a list of all-to-the-text payment gateways on docs.truplecommerce.org in the developer guide, and there's over 30 of them on the list. So it's probably better to focus on the ones we have than the ones we don't, at least. This was for payment gateways or tax? Yeah, for payment gateways. For payment gateways, yeah. There are a lot of payment gateways in Commerce 2. There are a number of available and un-ported gateways and more and more ported ones. Great. Any other comments from the Commerce guys in the audience? No. Thank you. So you'll be able to look at that. Thank you to all of these people for help with this presentation, reviewing it and giving me input and whatnot. Do not miss the presentation sprint tomorrow. If you're going to be here, I'm going to be there mentoring. So come along. And you can give general feedback on the conference at this link here. It's just SurveyMonkey R, DrupalCon Vienna. And also if you go to this session's page, you can give an evaluation of the session. Please do. Tell me everything that sucked or was nice so I can improve it. And this is just my contact information. It's basically just one word for most stuff. And if there are no more late-game questions, then that's it. Now you have extra time to chill out before the next session.