 Good afternoon. My name is Joshua Turton. I'm with phase two. Today is how, when, and why to patch a module. We're going to be covering one of the fundamental Drupal skills, in my opinion, that you need to know how to do in order to both work with and work within the Drupal community. So let's get started with a very basic question. What is a patch? When you're working on a code platform like Drupal, there may come a time when you need to change some code that you didn't write or that you don't control. Patches are how we do that. They're a universal standard in the software world, not just in the web world. Video games, enterprise business applications, and operating systems all use patches to make changes on the fly. At their heart, patches are small files that contain a list of the changes you wish to make between the existing code and the code the way you want it to run. They are applied to the existing code and make permanent changes to that code. This is an example of a very small patch file. Let's take a closer look. The most important lines are the ones that are highlighted here. The plus and minus signs on the left tell us these lines are the ones that are changing. Minus is a line that's being removed. Plus is a line that's being added in its place. On the right, where the arrow is highlighting, you can see the actual changes to the text that generated the change, or that triggered the change. When and why would we do this? In the Drupal community, we don't hack core, and we really shouldn't hack and trip, either. There are two main reasons. Forward compatibility. If a feature, if a new feature or change or, most importantly, a security release comes out for a module that you've tinkered with, you can't take advantage of that without losing your changes. The second reason is developer friendliness. If your changes introduce a bug down the road, other developers are not going to look in that module because they're going to assume you didn't mess with it. This will cost them time and frustration. Don't do it. But sometimes we need to. Sometimes you just, you need to make that change. That's where patches come in. They're a way to modify core and trip code in a way that's maintainable, this feature friendly, and this reproducible. And it will save the kittens. So what's the difference? What is the difference between a patch and a hack? Fundamentally, the difference is method. When I say hack a module, it means I'm changing module code directly. Then I'm either uploading it straight into my site repo or worse onto the production server and running it as it is. It's the cowboy way of coding. Okay? Changes like this are really pretty invisible to other developers because there's nothing there to tell them that anything changed. When I say patch a module, it means the changes that I've made are in a separate text file which is applied to the module when the site is assembled. These changes are easily accessed. They're easily reviewed. They're obvious because they're in a separate text file but sitting there saying, hey, I'm a list of changes. This tiny methodology difference actually means a really huge amount in practice. A module that's been hacked is very difficult to use in the long term. The changes made to it are often not recorded at all anywhere or they're recorded somewhere nobody's ever going to look again. Let's face it, once the project is launched, that wiki page you put up with the list of all the things you changed, it's invisible. It's gone. No one is ever going to look there. So these changes are essentially lost forever. Now, if someone comes along and updates that module that you've made changes to, your changes are gone. They're erased and now the bug that you fixed or the feature that you added doesn't work anymore. It's poof, gone. Goodbye. So when should I patch? Well, here's a good set of reasons. Number one, you found a module that does most of what you need. Not quite everything. Or you found a bug in the module. This is actually quite common. Or you need to integrate custom functionality into that module. But it doesn't have the right API or the right hook functions or the right this or the right that. So it's almost. But you need to tweak something. Or you need to change right now and the module maintainers on vacation. Now, when should I not do this? Well, if the module provides hook and alter functions or event listeners in the new Drupal 8 that will allow you to do what you need, then use them. Drupal alter is an incredibly powerful thing and it's in a lot of places in existing modules. So if that function is there and it gives you the ability to access what you need to change, use that instead. If the module only really does a little of what you need and a whole bunch of stuff you don't need, you may be better off writing a custom module or finding a different contributive module that'll do what you actually need to do. There's no sense in patching 80% of a module and because you need this much of it. Or the dev version of the module has what you need or there's a patch already in the issue queue that will allow you to do what you want to do. At that point, we'll lead us to the next section. How do we do it? Well, step one in anything in software most of all is work smarter. This is a community. It's quite possible that somebody out there in the gigantic Drupal world has the same need as what you do and has already done what you need to do. Check first, save yourself some work. It is well worth an hour of your time researching changes to this module that may have already been made rather than spending 10 hours writing a change only to find out a year from now that somebody did that and you wasted your time. If you're not already using the dev version of the module, try it. You know, there's kind of a stigma about using dev modules in production. This is Drupal and most modules are in dev forever and ever and ever. Odds are you're going to wind up using dev modules, dev version modules in production. There are ways you can mitigate the risk with that, we can talk about that later. But the bottom line is you're probably going to wind up doing it at some point. So suck it up and try it. If that doesn't work, the links that are highlighted on this module page lead to the issue queue where you can find other people's bug reports, other people's feature requests, support requests, and best of all patches that have been written for those modules. So go in there, look around and see if somebody else has said, well, I need it to do this. And you're like, hey, I needed to do that. And you look and they've already written the code to make it do that. Great. If you find a pit patch that looks promising, you skip like half this presentation right to the end, where we talk about applying a patch. Alright, no luck. We've looked through the issue queue. Maybe somebody else has reported that same bug. Nobody's fixed it. Now we go to the next phase, edit and patch. Step two, check out the module. You need to be working from a Git repo in order to make a patch. Technically that's not entirely true. The easy way to do it is check the module out from the repo and work with it that way. Just downloading it is much more difficult. So find and click the link on the modules page that says version control. That's this one right here. Make sure click it takes you to the second screen over there. Make sure that the version to work from form item says dash x at the end. That's the dev module. That's the dev version. Okay, if it says 1.0, 1.2, 2.3, that's not the dev version, which means you won't be using the latest greatest most current code. Then copy and paste that text line into your terminal, run it, and you'll have checked out the module. You will now have a directory. You'll have a directory filled with a module. Now you can in fact check this out into the sites all modules directory of your working site. So Git can handle nested repos can handle folders within folders. Go ahead and check it out in your working directory if you think that'll be easier. Step three, the hack. Now's your chance. The magic source control means that you are not going to screw up everything beyond all recognition. You're not going to wind up with an unusable module. You can always rewind, throw out your changes and start over, wipe the slate clean and start over if you absolutely have to. We'll also show you the changes you've made so you can look at it and say, oh, well, there's the problem. Debugging in that case can actually be much easier. Then enable the module and test it, repeat it until it works the way you want it to. And the good news is the kittens are safe because you're doing this the right way. Now two things to remember. Number one, please, please, please, make sure you are working against the dev version of the module. When you are cutting new code for a module, you want to be working against the latest and the greatest because there could be something that affects what you're working on. If you're working on adding a new database field and somebody else has already added a different new database field and it's in the dev version, but it's not in the production version, you're going to run into a conflict. There's going to be problems when you try and integrate your code with a later version down the road. Work against the dev version, save yourselves in trouble. When you get to around to contributing it to the issue queue, which we will cover in a minute. The first thing, if you don't work against the dev version, I guarantee the first thing you will be asked is re-roll your patch against the dev version, please. Absolutely 100% guaranteed. Second, please, and this applies to all of your coding, but if you're working on someone else's module, don't introduce security goals. Follow the best practices in Drupal. Use form API, use database abstraction, sanitize your texts, all of the good things, we know how to do, we always do, we should follow the rules, especially when you're working on someone else's module. The last thing you want to do is introduce a security hole to something that isn't yours. There's lots of good reading, I'm not going to go into security in patches. There's lots of good reading on that topic and I encourage you to explore it. Step four is make the patch. Now there's two ways to do this. The command line way in the directory, get diff, caret, patch file name. This is actually really simple. This will create a file, in this case called patch underscore demo dot patch that contains all the changes that you've made to your files, to all of the files in that module directory. Now there's command line options that only includes certain files to compare different directories, so on and so forth. Personally, I favor a different way. Source tree. This is a GUI interface for the management of your repositories and it's awesome. It's also free. It's made by Adlesian, the same company that makes Jira, which is ticket management, Confluence, which is a wiki, and Bitbucket, which is a repository very much like GitHub. We at phase two use all three of those things extensively. We are really kind of big fanboys of Adlesian. It's sort of shameful. It is reliable, regularly updated, easy to use, and it's free, that I mentioned it's free. It's a really, really good product. It lists the files you've changed that you have changed. It shows you line by line the changes to the files. Green is stuff I've added. Pink is stuff I've taken away. If there's a pink line and a green line together, it means I changed one of those lines. Now you can see, especially here in the bottom, this looks very much like the patch file we saw earlier. Well, there's a reason. It also allows you to create a patch just like that. The best part of creating patch and source tree is it will ask you which files to include. Pops up a nice little menu, whole list of check boxes. Boom. If you've made changes to five files, but you really only need to do changes to three, you can do only changes to three. This is so much better than trying to figure out how to specify all of this on the command line. And in the end, source tree is so completely compatible with Git that if you go back to the command line, everything that you've done in source tree is reflected in the repository on the command line. So they are perfectly integrated. It's a wonderful, wonderful tool. It's free. I suggest you use it. All right. Step five, submit your work. So we've rolled a patch. We found a bug in a module. We found a necessary change in the module. We've checked the module out. We've edited the module and it didn't explode. We followed security practices. It now does the thing we need it to do or it doesn't do the thing we need it not to do. What do we do with it now? Well, part of the Drupal community is we're a community. We work together. So go back to the issue queue. You should already be familiar with this from searching through it. Click create a new issue. This will pop up a form. It looks just like a Drupal administration form. Fill it all out. Make the title descriptive. That's the important part. You want the title to say in 10 words or less what the problem is that you're trying to solve. And the summary should be a good explanation of what it is, what you've tried, how it works. If it's a bug, what you need to recreate it, particularly interacting with other modules, so on and so forth. Tell the maintainer of the module what you need in order to recreate the problem or what you want it to do. Don't attach your file just yet. We're not attaching it just yet because Drupal has the Drupal community has created a standard for naming files, naming patch files. This is the standard. Now it looks a little complex. We'll walk through the steps of how you get all of this information. So the standard is module name dash short description of what your patch does dash issue queue number dash comment number dot patch. Okay. Module name and short description are fairly self-explanatory. Let me show you where to find the numbers. So when you create an issue queue, an item in the issue queue, you are creating a node on Drupal.org. As you know nodes have NIDs. So the issue number is actually the NID of the issue that you created in the issue queue for that module. It's right there in the URL should know how to find it. Now in order to add a patch to the issue node, we attach it to a comment. So your comment number will be one more than the highest number of comments that are already on the on the node. If there aren't any, it will be number one. It is not the comment ID. The comment ID is a very long number in the URL. Don't use that. It is the actual visual display number right there. Use this plus one. Now you have the numbers. You can rename the patch. In our example here, the patch file that we are creating is for the patch demo module, we are adding a job field to the database. It is issue queue number two zero five six zero zero one and there were two comments already on the issue queue node. So our patch will attach to comment number three dot patch. So we rename the file. Do this in the finder if you're on Mac OSX or whatever the Windows equivalent is. Make a comment on the issue queue node. Usually it's something like, hey I did it. Patch is attached. Please review and upload it. Congratulations. You are now a contributing member of the Drupal community. This is a huge deal guys. Okay. Think of all the kittens that you have saved by doing this the right way. Step six, bringing your work together. Okay. This is where we put all the pieces that we have all together in the same place. Now we started off, get conversational here for a minute. We started off with a problem. So we had a website. We built it on dev. We've had it in production and it caused us a problem. Now the problem could be a client came to us and said hey this is great but I wanted to do this other thing too. Or the problem could be hey when I do this and this and this weird thing that nobody's ever done it goes kaput. So we had a problem to solve. Now there's two ways we can do it. We can hack and hack and hack until it works or we make a patch. We've made a patch. So we've checked out the file, checked out the module, made our changes, compared them against the existing code with a tool called get diff which is what Source Tree runs on the background by the way when it makes a patch. It's created a file for us that lists out very very succinctly all the changes we've made. We've sent that back to the module maintainer and it's now existing on Drupal.org for our reference. But what do we do with it? Because so far we haven't actually launched that change. It's just sitting on our dev server or it's sitting in a text file on our on our local laptop. Well here's what we do. We bring all the pieces together. This is a Drushmake file. Now if you don't know Drushmake I'm not going to go into all the details of the incredible amount of things that Drush can do but it is well worth the time that you will spend becoming familiar with it. If you don't know it go learn it because it's one of the most powerful back-end tools that you can possibly imagine and it's not hard to use. Now a lot of us are afraid of the command line and Drushmake is Drush and Drushmake are command line tools. The command line is in that that scary terminal. The black with a white text. It's kind of creepy and freaky. It's not. It just takes a very specific set of requirements so it is worth the time to spend to learn it. Now I'm not going to go into all the details of all the incredible amount of things that it can do here but I'm going to talk about Drushmake. So the history of Drushmake essentially what happened is somebody said hey Drush is a great tool wouldn't it be great if in addition to all these other cool things it can do. It could take a list of stuff that we specify in a file and assemble a website out of that stuff and so they hacked on it and they hacked on it and this is what they have. Now this is a Drushmake file. It's a very simple one but it makes site building work the way it really should. Now in combination with other tools it also allows us to avoid committing changes. It allows us to avoid committing entire modules and the whole of Drupal Core into our own repository. We commit this file and then we run that file and it assembles the website for us along with our custom code. So let's take a closer look here. It also, and this is a key note for us here today, it allows us to specify patches that we apply to modules. So not only does it assemble a website for us based on a list of stuff that we're going to download, it also downloads patches, applies them for us, and then gives us the end result. This is incredibly powerful because it means we don't have to go through the getDiff and getApply process manually every time we assemble our website. Okay, so running Drushmake on this file will download Drupal. You can see that up at the top. Drupal Core, ProjectsDrupalTypeCore, version 7.30. That is a little out of date. Now I suggest you make sure you're downloading the latest version, but this slide's a little old. It puts all of the projects and libraries in the contrib sub directory within sites slash all slash modules. So all the stuff you're downloading. It downloads the features module. You can see right there under contrib which is underlined in red because my text editor thinks it's misspelled. So it downloads the feature module, our patch demo module. It chooses a specific URL, a specific type, get, picks the dev branch. That's the line right above the orange where it says 7.x-1.x. You could in fact specify 1.0, 2.3, 7.4 if they've gotten that many versions. I don't think anybody's up that far. And then in the orange is the patch that we are applying. Now this number, am I going to run out of cord? This number right here, you'll note, is also the issue queue number. It's the same NID as we've used before. It's also right here in the file name. So that is a patch. It will download that patch, it will apply it to the module after it's been assembled. It will report whether or not it worked, and it will assemble the entire site together. That's all there is to it. Once we've run this, drush, make, and then the file name. And then I think you can specify a folder to put it all in. It downloads core. It downloads the features directory, the features module, downloads patch demo module, downloads our patch, applies the patch to patch demo module, puts it all together, and hands you a directory. It says here you go, website. And that's the point at which you can run installed.php. Now if you've already built your website, and this is a reiteration of it, because for example, core has gone up a version, and you're updating, then it builds with the new version, and you apply it over the folder that's already there, and you have a new, a new website. Now there's a couple of caveats to that. You don't want to overwrite your settings file, so make sure you move that around and all that. You guys can figure that out. But we didn't have to manually change anything. We didn't go into a repository full of somebody else's code, such as Drupal Core. Make changes to it, and then put it up on our web server. See, because the whole philosophy here is that your repository should only ever contain your code, shouldn't contain Drupal Core, shouldn't contain Bob down the streets modules, should only contain the custom stuff you've written for your site, your theme, your CSS, your modules, and your make file. You're working with someone else's code. You're working with someone else's module. That's kind of the definition of working in the contrib space. When you put an issue queue, when you put a node in the issue queue, out there, when you put an issue out there, and you say, hey, this is broken. I tried to fix it. Here's my fix. Well, you're handing someone else your work. And they may or may not like it. They may or may not code the way you do. They may or may not think that it's a safe patch. So there's one of three possible responses. The first response, best case scenario, hey, that worked. Thanks. Now it's rolled in and it's in the new dev version. Cool. That's a great feeling. The first time it happens to you, you suddenly feel like you've, like, you've gone up a level. You, uh, you're now a real developer. Second, yeah, no, that doesn't fit with my, with my vision for this module. Thanks. Closed. Goodbye. Okay, that sucks. But here's the best part. Drupal.org doesn't ever delete anything. So that file is still on Drupal.org slash files, meaning you can still use it in your make file. Just because somebody else didn't like it doesn't mean you can't still use it. I have put up many, many, many, many patches that I knew would not get approved because I needed it to work this way and that's the end of the story, right? Because somebody was paying me to make it work that way. Oh well. Now if they come to you and they say that's great but you just introduced a huge security hole that my neighbor down the street could use to take over your website, okay, don't use that patch. But if it's just a philosophy thing or if it's just a, yeah, that takes things in a direction I really wasn't going, nobody cares. You can still use it. There's, there's a third response and this is where the community part comes in. That's the discussion. They can say, that's a great idea. Maybe it would work better if we did this and then somebody else comes in and says, well yeah, I like that but you know the standard is this way and you know, seven issues later somebody else submits a patch and maybe it's a little better than yours. It works a little differently but it does the same thing. Okay, well great. Change your make file. Done. Now that process can drag on and on and on and on and on and on. There are issues in the issue queue that are literally tens of pages long that are six and eight years old or more. If you get into core development you will find those issues and nobody has ever been able to solve the problem to the satisfaction of everybody involved. This is where we go back to this part, the outlined in orange part. You find when you like and you use it. Sometimes it's an interim solution, sometimes it's not the best solution but it's your solution and it works. Don't be afraid of that. Okay. Oops, too far. Now here's the other question. Why bother? Why would we go to all this trouble? Because there's a lot of extra steps there compared to cowboy coding where you hack the module on your site and you throw it up on your server and you're done. Okay. Show of hands who here has done that. We've all done it. Some of us just don't want to admit it. Okay. I get that. I do. And if you're a one person shop and you're working on your grandma's website for her knitting projects, just do it. Nobody's going to care. Right? I will admit my personal website, not the phase two site, my personal site, probably has a couple of hacks on it. Well, the reason we do it is because of the community. The reason we do it is because of the other developers. There's a saying which says code as if the next person who gets your code is going to be very, very angry because they will when they see the bad things you've done with it and it will probably be you. I can't tell you how many times I've come back to something six months later and gone, what? What was I thinking? What did I do? Why did I do this? This doesn't make any sense. Code as if someone else has to inherit your work because that's what happens. That's why we do patches. Okay. Because after you've applied the patch, it looks exactly the same as if you cowboy coded it. But the patch allows us accountability. Accountability is huge when it comes to working inside a team. Okay. Well, okay. That's great. But. Drushmake can download a patch from anywhere that's publicly accessible on the web. You can put it on your company's file server. You can put it on your personal website in a download directory that nobody ever looks on. So why go through the issue queue and start the argument? Well, because each of us, no matter how inexperienced, no matter how new, no matter how totally ninja badass, can contribute and help make this community and our product stronger. Communities work best when everyone contributes. You know this is true. You look at a community that's got six. How many of you? Okay. Another show of hands. Sixth grade group project. How many of you were that one guy that carried everybody else on your team? Uh huh. Okay. How many of you were somebody else on the team? Uh huh. Don't be that guy. That's why we contribute. They work better when communities work better when everybody's pulling their weight. Okay. Now your patch may not be accepted. Or it may. Or it may lead to a discussion that completely revolutionizes how we do Drupal. Okay. You get into the core issue queues. You start talking to the guys who made the decision to move to Symphony. They revolutionized how we do Drupal. Okay. So you could spark a discussion that leads to something entirely new and entirely cool. Even if it isn't in. Even if it's never accepted, it's still in the issue queue. Even if the threat is completely ignored, nobody ever does anything with it. It's not closed. The bot comes by two weeks later and closes it for lack of activity. And the maintainer ignores it entirely and nobody ever comments on it. It's still on the file server. So you can still use it. On a more personal note, contributing in the issue queues helps you get known in the Drupal community. This is fantastic for your career. Okay. Many times I have heard many, many stories of HR director getting in a resume of someone they've never heard of. Passes it off to the CTO who looks up the person and goes, Oh, I know that dude. He's contributed 18 patches to my module that I maintain. He's a rock star. Hire him now before somebody else does. Okay. I can name people at Phase 2 that have done that. So it's great for your career. It's great for the community. It's great for Drupal, the product. There's no downside. And the truth of it is, it doesn't take that much longer, especially with a tool like SourceTree and Drushmake. All right. Some very important links. Top one, Drupal patch contributor guide. This is the quote unquote official community guide to basically everything we've talked about. Second one, a blog post from 2008, which is still incredibly applicable as to why we don't hack or and contribute. Pretty much covers the first part of this session. I drew a lot from it. So Joshua Brower, if you're here, thank you. If you're not, thank you. The actual documentation for GitDiff, a link for SourceTree, a blog post which covers pretty much all of this on the Phase 2 blog. And finally, session feedback is at events.drupal.org slash node slash 775, which will re-resolve to the name of this session. So please leave session feedback. If you liked it, if you didn't, please leave session feedback so we can all get better. Again, contributing, being a community. Again, I am Joshua Turton. Thank you so much for coming. I'm with Phase 2. You can reach me at that email or that Twitter handle or at our booth in the exhibit hall. So please do leave session feedback. You'll also be able to download the slides there, which will again also link to the blog post I think. And I think they will also put the recording up. If you would like a demo of this process, if you would like to walk through this in real time with me, find me at our booth. We can hook up an informal demo. I'm already prepped for it. I've got a demo module in my sandbox. We can go right through these steps. I would be happy to do that for you. Last thing, plug for Drupal Camp Costa Rica. It's happening in San Jose. I'm on the organizing committee. It is awesome. Costa Rica is very cool. If you are interested in speaking, session submissions will be open soon or you can contact me directly. Sponsorship opportunities will be available. Talk to me for more info and come join us. It's a good, good time. And you're in Costa Rica. Alright, we have time for questions. So there's a microphone back there. Why don't you come to the mic so that it's on the recording? There are a couple of ways of doing that. The first one is basically on the command line. It's kind of the inverse of the get diff. I forget the exact command, but I think it's like get apply and then the file name. You have to be in the right directory. Source tree can also apply a patch directly, which is how I usually do it if I'm manually doing it. So either of those two options will work. Very good question. So if you didn't hear it, the question was what happens with the module when you, or what happens with the patch when you upgrade the module? And basically it's one of two things. Either it will continue to apply or it will go completely. So that's the short answer. The longer answer is get is very, very smart about how it applies patches. So it will, when you look at a patch file, and I'm going to scroll back to the patch file really quick at the very beginning and I'll come back to the links, you can see it has line numbers. There are a few lines above the orange. 125 comma 7 plus 125. So that tells get where to look, but get is very, very smart. So it kind of uses some fuzzy logic and tries to find the lines that you're changing. Now you'll notice around the orange box there are a few lines of code that aren't changed. That helps it find it. So if you upgrade a module and some code has moved around but it hasn't changed, then your patch will still apply and it will report oh it was offset by seven lines. Now if you have a module that changes the lines of code that you were trying to patch, it's going to report a failure and then it's on you to fix it again. The good news is Drushmake is smart enough to exit when that happens and say dude it broke and then you get to go fix it. Now this will absolutely happen when your patch gets accepted to the dev version. So module maintainer comes along says hey that's awesome let's put it in and it puts it in. Well now somebody's changed the lines you're trying to change and it gets confused and can't sort it out so that will absolutely happen in your best case scenario. That's a good thing for you. So then you go to your make file and you take out the patch, the line that specifies the patch, and you say okay use this dev version. Gold done. So yeah it will break that does happen. It's kind of on you to fix it. But the good news is that you have the patch file that tells you what changes needed to be made and why you have the issue queue number where you can go research what happened because issue queue number remember is in the Drushmake file and on the file name. So you go research why did they make this change and you can reroll the patch against the new version and it's much easier than if you had to go through the whole process all over again. So that's again why we use the issue queue that's why we use the patch files that's why we put the issue queue number in the patch file name so that we can find all of that information again. Yeah so that should answer the question I think. Next you fix it. I mean that's the the bottom line is this process gets you so much further but eventually as things continue to evolve it will break down and as developers it's on us to either redirect and reroll the patch that we've had the code that we're trying to change or accept the new direction and work around it work within that. So eventually yeah eventually all patches will break because code is an evolving thing Drupal is an evolving thing this allows us to continue to work within it now if you want to there are ways within Drushmake to pin to a specific commit so you can feed at the commit hashtag you can look up how to do that in Drushmake but you can say okay I want the dev version on this date at this time on this commit and so you're using that exact thing that you know your patch applies to and nothing past it so no matter how far it goes how many years into the future you will continue to use that one little bit of code as it was on that day at that time. Now there are pros and cons to this. If you commit or you pin to that one commit and six weeks later somebody finds a security hole in that module patches it fixes it new dev version uh-oh you're still back over here so there's pros and cons and you need to monitor that. Drupal itself has very good monitoring of updates of modules particularly for security releases very good notification if you are not on at least one of your servers using the I think it's the update module that tells you these things turn it on because you need to be aware of those things. So I think that should does that does that answer your question? Okay perfect. So I guess like everyone else I have more of a question about Drush Bake I guess. It's a wonderful tool go ahead. Yeah so um I really like your philosophy of using the make file uh we're starting to head in that direction but we have a lot of sort of inertia of having the whole core plus custom completely in our repo. Is there a way to have like a Drush make file that just improves the patches and somehow automatically apply them after you run Drush up? Or is that like witch prep? I can see by your face that it's witch prep. The thing with Drush Make is that it expects to assemble a website for you. So I suppose you could I'm not sure if it would work. You could skip the line where you're telling it to download core. At which point it would assemble really only the contrives directory and then apply it. I think what you're asking is beyond the scope of what Drush Make can do. That if you really need to go that direction you'd be better off looking at some sort of a bash script that is run by Jenkins. Jenkins is a continuous integration tool way beyond the scope of this talk largely because I don't understand it entirely. We have people who are really good at that. If you want to talk Jenkins come to the booth we will set you up but it's a basically a tool that automatically runs a bunch of stuff. When we at phase two when we use Drush Make it's wrapped in a script that Jenkins runs for us. And on our dev sites when we make it it monitors the repo. And so when we make and commit a change to the dev branch so pull requests and all of that when changes happen in the repository it rebuilds the site automatically for us. So what you're asking is more likely to be handled by a custom Jenkins script that looks at your repo and then slaps a bunch of stuff on it. But honestly if you're committing contrived modules to your repo you may as well just patch them and put them in there. And then save the patch file in a list of you know in a directory of these are applied to this. Yes it is it is a big yeah it is a big intellectual leap to to make the jump to only contrived only committing your your your code. There is there's an insecurity feeling there that has to be dealt with. It's it's honestly it's more of an emotional thing than anything else in my experience. It's the devs have to come to terms with the idea that not everything is there and they can't just put their hands on it. So yeah there are ways to do what you're asking Drushmake is probably not that way. Yes I totally should. When you submit a patch to an issue queue node as a comment you you attach the patch file to the issue queue. You set the issue status it's one of the fields on the form set the issue status to needs review. That will trigger a bot that runs on Drupal.org to come by attempt to apply your patch to the dev version of the code. Again this is why we use dev it's another reason. It will attempt to apply that patch and report whether or not it worked. Now very frequently it won't for reasons of syntax or very detailed you know this or that. If you're in a situation where you've applied more than one patch to a module and so the code lines are all different it'll just go what no and so there's any number of reasons why that wouldn't work. Generally speaking if you're looking through an issue queue and you see a report of a patch that failed unless there's a whole lot of comments saying yeah the bot failed this for some stupid reason but it works for me don't use it. That's generally an indication that it's not going to apply very well. Are you on? Yeah. Oh well I will have the slides up so if you want those links which I'm trying to get to the slide anyway. If you want the links then you can find them on the website. So yeah so that's basically pass and fail in a nutshell. I believe there is. Forget what it is but I'm pretty sure that it might even be a command that you can issue to Drushmake that says look at this and try and assemble something. There are also a few online tools that I have seen that allow you to fill out a form where you specify the Drupal version and you specify the you know the contrived modules that you want from a list of a bunch of really common contrived modules and you know possibly a few libraries and it'll spit out a good starter. So either one of those things I'm fairly certain there is a command line tool that will analyze the directory and try and spit out a Drushmake file. I would use that with some caution but yeah the tools for that do exist. I think so yeah that's something that would probably be answered by a fairly easy Google search. I have time for a couple more questions if there are. There's usually a lot of questions on this session which is why it's kind of short. How would your suggested workflow be modifiable if you're releasing a code or do you have to get permission for my legal requirement? In other words, I can't contribute things back because my policy prevents that. Is there some way to do this thing where if you're saying you can post the file locally or something like that? Yes. There's a couple of solutions to that. You can put it on if you're working in a essentially contained closed environment where right as long as Drushmake can see the file can follow the file path to that then it can apply the patch. So you don't have to put it in the issue queue you can just host it on your server internally as long as Drushmake has access to that URL path. I believe it is also possible now for Drushmake to take a local file path for those. So you could in fact host it on the same server and possibly even put it in your repo. I recall that being kind of complicated. I haven't tried that in a while but I think it's possible. So you could in fact patch the module that way. That in my opinion now we get kind of back to that question of well why don't you just at that point hack the module. I think you're still better off with the patch file methodology because of the accountability and the future proofing. So I still suggest that you go through that you know go through most of this process without the submission to the issue queue. I'm fairly certain that it is possible now to locally host those kind of files. I know you can do it with libraries and I know that you can do it with some other things that Drushmake deals with. I haven't tried it with a patch in a really long time but I'm pretty sure you can do it. So that's probably the solution that you would want to look for. The projector is still not on. Did I kick it?