 Is that working? Oh, there we go. I can hear that. So it's just about 1045, so I think we should probably get started. People may dribble in. First session is always a little slow getting started, I think. So Guten Morgen! Eins bei dry Exprekendicht. Deutsch, Deutsch! Exprekendicht, Deutsch! Yeah, that's it. You have my entire German repertoire there. I actually lived in Germany for two years, but it was a long time ago, and I did not learn German, although I did try. But I found, fortunately for me, that it's possible to get around quite well speaking English and waving your hands around. So I survived that way, but I love southern Germany, so I was really excited to come back and be in southern Germany. So the present day, I'm Karen Stevenson. I am a maintainer of CCK and Dayton calendar and lots of other things. A lot of modules, so I guess it's appropriate for me to talk about modules because I write them. And if you're around Drupal very much, of course, you always hear the expression, there's a module for that, right? Whatever you want to do, there's a module for that. But the fact of the matter is, sometimes there's a module for that, and sometimes there's not actually a module for that. So I wanted to talk about that in the process of finding modules, figuring out whether they suit your purpose, figuring out what to do if they don't quite suit your purpose, or if you can't find a module, and what your alternatives are at that point, and kind of this whole thing of solving that problem. So this is where we are a lot of times. We've got a website, or we have a bunch of wire frames, or we have something, you know, this is the site, and we want to move this thing to Drupal somehow. So how do we go about that? What's the exercise that we want to go through? Well, we could download and install Drupal Core. Does anybody know of a production site that's actually running on nothing but Drupal Core? Because I don't. Drupal Core is wonderful, there's lots of great stuff there, but I don't know of any situation where that's been enough to do everything that somebody needed to do. So that's where Contrib comes in. We have a lot of Contributed Modules. We have a lot of Contributed Modules. So, yeah, there probably is a module for that, whatever that is that you want to do, but there's a heck of a lot of modules, so where do you start, right? Where do you start? So we have a little process that we need to go through. So basically we started with this website, or these wire frames, or whatever, and we're trying to figure out how we're going to make this thing into Drupal. And so basically what we have to do is iterate over the site. We have to say what are the things that need to be on this site, identify each of these problems or requirements for the site, find a module or modules that solve that problem, evaluate whether or not they're actually suitable for as a solution. In many cases we're going to find more than one module and we have to choose between them and try to figure out which one makes the most sense. And sometimes we find that none of them quite work and we actually have to roll our own solution. So first of all, how do we go about finding modules that solve the problem? Well one really good starting place is you go to Drupal.org and there's this download and extend button that shows up at the top and if you click on that you get this page and you can do things like you can look for distributions or themes or translations or most installed or new modules or module categories or module index. There's all different kinds of ways that you can search through things. My starting point is the most installed. So number one is if you ever have to go through this exercise more than once and most people end up going through it more than once, a good starting place is to know, I say the top 20, but you probably even need to know more than that, the ones that are most installed are most installed for a reason and you ought to know what those modules do so you can figure out whether or not they're appropriate to solve your problems. There's another place that you can go, if you go to Drupal.org slash project slash usage you get to this page and this page is this is the most installed again and it's got dates, but you can see exactly which modules are installed on most of the sites. And at least the top 20, like I said, you should figure if most sites are using these modules and I'm not, maybe I should figure out whether or not one of these is a suitable solution for one of my, you don't necessarily need all of them but there's a reason why they're the most installed. And then if you go back on that first page, the other option besides the most installations is an option to go look at the module category. So you can also come in this direction looking for modules. This is kind of useful, but it's basically subject to, each module, each project page decides for itself how it wants to categorize itself. So the module, the project may categorize itself. There's a lot of modules and a lot of projects that don't categorize themselves at all and they won't show up here. There are some that like throw themselves in every possible category so it's not particularly useful. They may or may not categorize themselves the way you would have categorized them, but it's something, right? And so for instance, if you know you want to find something that works in views, you can go to the views category and hopefully some of the useful modules will have at least categorized themselves that way. My favorite place though, this is usually where I go to and you actually have to click through about three times to get to here but the URL is just drupal.org slash project slash modules. I find this to be the most useful way to search through things because this sort of gives me the best of all worlds. So I can say what category do I want to search through all categories, again realizing that people may or may not have categorized things appropriately. I can choose the version because there is no reason in the world why I want to find results for Drupal 5 if I'm building a Drupal 7 website. That's not going to help me much. The status one is really interesting. The options in the status one are all projects, full projects, or sandbox projects. For this particular search, you want full projects. Full projects means projects that have releases, they have recommended releases, they're being used on production sites or intended to be used on production sites. You don't want to start with sandbox projects, but there actually is a point later where we're going to talk about where sandbox projects can be really useful. So you want to search through full projects and I should have put that on the screen instead of all projects. You really want full projects and then you can put in some text of terminology or some term or something like that. And then you can sort by, I think almost always, you want to sort by most insults. So in other words, I want to be able to say I'm looking for modules in a certain category for a certain version of Drupal. I only want full projects, I don't want sandbox projects, I want to have certain terms in them and I want the most installed and then I'll get my list of results. And that's a really good starting point for taking a look at these things. But that's not enough because the only thing that does is it searches through the information that's on the project page and that may or may not, again, how complete is the project page? Some are really complete and they have a lot of information on them and some may or may not have information on them. Even if they're really complete, they may not have the terminology that applies to what you're looking for. So you can also just do a general Drupal search because a general Drupal search is going to take you through issues as well and sometimes the way that I have found really useful modules was not by looking through the project pages at all, but I searched for a term that floated up in an issue and it turns out there was this issue discussing that thing that I was trying to figure out how to do and I click on that issue and then I go see what project that issue was in and I say, oh, this is the module that would solve my problem. So that's another way to go through. This by itself is not good enough because the very first thing that I'll just point this out, the very first thing that shows up is this carousel module and it says this project is abandoned. So obviously that would not be a good solution for your project. I'm guessing it's probably some really old version too. So you need a combination of different ways of going through these things to get to this. And then Google is your friend, right? I still end up going back to Google because sometimes there's a really good, you know, I'm looking for a module that will do blah, blah, blah, blah, blah, and I put that, you know, something like that into a Google search and I always put the word Drupal first and then whatever it is I'm looking for when I search on Google and usually that works pretty well because sometimes what comes up is a really great discussion of your exact problem on somebody's blog post somewhere. It's not on Drupal.org at all, but it has a discussion that says I was trying to find a module that would do blah, blah, blah, and I found such and such, you know, and so sometimes really interesting things will show up that way. So you go through all this and there's, you know, it just takes time to go through that and you get done and then you have a solution or solutions, probably more than one because there are 16,000 modules. So then the next thing that I do is then I want to... I've got a couple of options here. I'm trying to figure out if any one of these options makes sense. So the first thing I do is how well maintained is this thing? So there's a number of things that I can do. I can look at commits, I can look at bugs and issues, that kind of code quality, so let's talk about this. So if you go to the project page for any project on Drupal.org, there's a sidebar that shows you commits and links to the issue queue and so this is abused and I can see up here that there were 33,241 commits and the last one was 14 weeks ago and then there was another one six weeks ago and I cut off the top of it, some that were more recent than that. So I can see that there's lots of activity here, right? I can tell this is a really active module. Lots of commits, lots of things going on. Recent commits that tells me that it hasn't... probably hasn't been abandoned. I can come down here and I can see that there's 2,000 open issues. Well, that's a lot of open issues but views is a really, really complex module so that by itself, and it's not the number of issues. It's how much activity is there, how complex is it, what is the ratio of the open issues to the total issues? So yeah, there's 2,000 open issues but there's 17,000 closed issues so that's not so bad really. That's probably as good as you can expect because views is actually maintaining multiple versions so we've got issues across multiple versions that in some cases, some issues that have been out there for a long, long time bouncing around. And then if you look at the bottom of the page you can see all the releases. And we have green and yellow and red and so green are the recommended releases and if you're building a production site you're going to start with whatever the recommended releases are. And then there's other releases and so views is a really interesting case because views has a 6.2 release and a 6.3 release and the 6.2 release is marked as the recommended release and the 6.3 release is marked as another release but it's not an alpha or beta, it's a full release. So it says that's a production ready release, it's an alternative. And the reality of the fact is that the way that our system works is there's no way to do two recommended releases in the same branch, so it's not possible to say both 6.2 and 6.3 are production ready, you have to mark one or the other. But that's actually the case in views, is both 6.2 and 6.3 are production ready releases that are being used on a lot of sites. The reason for this and the clue is the fact that when you see that a release, there's two releases with two completely different branches, so 6.2 and 6.3, there are some important differences between the way a 6.2 and 6.3 releases. 6.3 has new features, it has additional functionality. So the clue, I have a clue by seeing that that number has increased that tells me that there's something significantly different about 6.3. If I was running a 6.2 site, I wouldn't just automatically drop 6.3 on there and assume that nothing else was going to change. I would have to say something is significantly different about 6.3. I might want to run it, but I would certainly want to test to make sure that everything else that I've got still works. I wouldn't just blindly drop it on there and run. 6.3 as it happens is the release that has all the current activity. Look at the dates on there, you can see the 6.2 release hasn't been touched since 2011, the 6.3 release has got recent activity. So what's happened, and you can kind of tell that picture, is 6.2 was the stable release, lots of production sites are on it. The fact that it's still marked as a recommended release means if you've got a production site running at 6.2, you're good to go, he's not saying get off of it, it's still good, it's still fine. But there is the 6.3 branch now that has lots of new features and functionality, and you can use it. And in fact, if I'm building a new site, a new 6 site, I would go with 6.3 because I can see, that's where all the action is right now. So I would start with 6.3. But I would know that if I have a 6.2 site, I wouldn't worry about it. And 6.3, I can tell by the version number, 6.3 is also the basis for 7.3, and that in fact is what happened. So 7.3 has, you know, what's in 6.3 and is using that. Oops, let's see. And then down here, we've got maintenance status. I can see that it's marked as being actively maintained and that it's under active development. You might see modules that say that they're not. They may say that they're not being actively maintained. They may say things like seeking a new maintainer. That's not necessarily a bad sign. I'll tell you again, as we go along, there are places where that could become important, because, you know, for instance, if you want to take it over, you know, it's the module that would solve your problem and you're willing to commit some resources to potentially, it's a module you could just take over. Lots of downloads. Lots of reported installs. And if I click through on the reported installs, I can see a graph and I can see what's going on and I can see that now Drupal 7 usage has surpassed Drupal 6 usage. So if I was trying to evaluate, is this thing ready for Drupal 7? Well, clearly everybody else thinks it is. It's being used. If I saw that the Drupal 6 line was up here and the Drupal 7 line was way down here, I'd say, okay, apparently people aren't really using the Drupal 7 version yet. So I might think about that. Another thing that I like to do is I like to look at code quality. And I'm a developer, so I can actually look at code and try and evaluate whether, you know, how it works and what it's trying to do. Even if you're not, you can tell a little bit by looking at the code. Is there documentation? Does it look like they're trying to explain how things work? Some code is really good and it provides lots of internal documentation about how it works. That's good. That indicates that the person that wrote it is thinking about making sure that anybody else that uses it understands what's going on. It'll be helpful if somebody has to take it over later. It'll be helpful if you have to debug it later. That's a good sign. Does it comply with Drupal coding standards? Some of the Drupal coding standards are kind of nitpicky. You know, like, is there one space or two spaces before or after a dot, you know, and I don't worry so much about those kind of things, but kind of general, at least general compliance with Drupal coding standards is a good thing because some of the coding standards are around security issues. And if they're not paying attention to the coding standards around the way the code is written, potentially they're not paying attention to the coding standards around security issues. I just think it's a good idea to go with modules that are paying attention to the coding standards. It indicates that they're paying attention. Is there a lot of commented out code? Every once in a while I open up a module that I'm evaluating this great big swath of code that's just commented out. That scares the pants off of me. So all kinds of issues, right? Like, first of all, why is it commented out? You know, maybe they copy pasted something in and they just totally broke and they rather than figure out why they just commented it out or they were trying to add a new feature and it's not working, so they just commented it. And the really scary thing about commented out code is what if they come in one day and uncomment it? What's going to happen? Is everything going to blow up? I don't know. It just commented out code worries me. In my opinion, the developer should either say this is in or it's out. If it's not good enough to be actual code that works, it shouldn't be in there personally. That's my opinion. So then you need to look at, you know, how well does it work? Got some module, code looks okay, looks like it's kind of, you know, used by a lot of sites. How well does it actually work? So now we get to the issue queues, right? So now we start looking at the issue queues and we can do a bunch of things. Obviously, first of all, the only thing I care about is issues that relate to the version that I'm working on. So the very first thing I want to do is I want to filter down to that. If I'm doing a Drupal 7 site, I don't really care what the Drupal 6 issues are. That's kind of irrelevant to me. The Drupal 6 branch and the Drupal 7 branch could be dramatically different. Drupal 7 could be a total rewrite. There might have no resemblance to each other at all. So I don't care about other issues on other branches. I can look at status, the status will be things like active, where you can see what their needs review, closed, fixed. So I like to do any and get a big picture, and then I also like to do open. Open is saying, you know, which issues are not yet resolved? Because if I see a lot of closed, fixed issues, again, that makes me feel good. That makes me feel like I've got a maintainer in there and you've been trying to deal with things. And then I also care about how many things are still open. So then I flip it back to open. And I'm looking for major bug reports, major or critical bug reports. If there's a whole bunch of major or critical bug reports, that starts to make me a little nervous. I might start scanning the titles of the reports to see what kinds of things are they talking about. More than once, I have been evaluating a module because I wanted this module to do a certain thing. And then I see an issue that says, this module will not do blah. Okay. There's a pretty good clue that this is not my solution. The other thing is you can filter feature requests. If you see a module that has tons of feature requests, it's actually telling you the opposite, right? It's telling you lots of people are using this module and want to do more with it. So I see that as a positive thing. And again, we can go back to Google. Google has access to things that are not on Drupal.org. And so, for instance, if I was looking for a path auto module, I can see that I see the path auto module on Drupal.org. I see an issue on Drupal.org. And then I see I got a blog post someplace else that was talking about how the path auto module works. This is a really good way to evaluate a module without going through the work of installing and trying it out yourself is to find a blog post where somebody else tried that module out and you can just kind of scan through, get a general idea of how it works and how it's configured and what did this other person think of it? And I think that can be really useful. So when looking at documentation, what kinds of things can you look for? Well, one thing is you can look and see if they have a readme.txt or an install.txt in the file. If they have one, you should actually read that. Usually there's a reason why they're there. Look for... In Drupal 7, this was not true in Drupal 6, but in Drupal 7, if you look at your module list, when you install a module, let's say you pull a module up and you're going to try it out and you install it and you're trying to figure out how it works, you look at the module list and you'll see, in some cases, a little link next to it that says configure, or you'll see a little link next to it that says help. So the help takes you to any help that they provided that's available, so you can click on that and get help. And then the configure is supposed to be a quick link to wherever it is you set this module up. And I don't know about you guys, but more than once I have been trying out a new module and I install it and then I'm going like, okay, now what? I can't figure out what it's... I don't even know where to set it up. I don't know what it's doing. I don't know where to set it up. So that's... Go here and see if they have these things. You can try the advanced help page. You can look for... Look on the project page. There's supposed to be a place where they can put a link to documentation. It's in the right sidebar and it says documentation. So there should be a link there. Not all projects do it, but that should be a link to Drupal.org documentation pages. You can try the advanced help module. Some modules have better advanced help than others. Some don't use it at all, but there might be good help there. Search through Drupal.org and groups.drupal.org. A lot of times, interesting things will pop up on groups.drupal.org. And when all else fails, I look for hook menu. And what hook menu tells you is hook menu... You see something in the code that is module name underscore menu. It's a list of the URLs where this module is doing something. If I can't figure out where the heck to go to see what this module does, I go in and find hook menu and say, okay, it says there should be something at the path, admin settings, whatever, and then I just type that into the address window and see what's there. Okay, so let's say we got this far. And we found several alternatives, or a couple alternatives, and now we got to figure out which one of these... They both look good. Code quality is good. They're widely used. They pass all those tests that we wanted to pass. How are we going to decide which one of them is actually the best for our purpose? So the first thing is there's this page right here, which is super helpful. And this is a drupal.org page where they're starting a collection of comparisons of contributed modules, and there's a whole list of things. So sometimes this is how... I said it's super helpful. It can be helpful and it can be less helpful. The problem is some of these comparisons are really outdated. Some of them may be for older versions. They may or may not be appropriate. But it's certainly a nice place to start because a lot of these links will take you to something like comparison of image handling modules. And it'll be something like a list of all the modules that do something with images, and then some sort of a grid of how... what features they have or don't have or whatever. So this is a really useful place to go. But not everything is on there. So you can also Google. And so, again, I do something like drupal carousel modules. Very first thing that pops up is a comparison. I sometimes even use the word comparison in my search terms. So Google through and see if you can find it. Okay, so let's say we got that far. We got two modules. We've done the comparisons. We've done all this kind of stuff. They still both look like potentially good possibilities. So let's say one of those modules does exactly that thing that I wanted it to do, but nothing else. And then the other module does that, but actually might also solve another problem on my site. Maybe I could use this other module to replace something else that I was doing. Maybe there's a... one of these modules could solve two or three problems instead of just one problem. I'd probably go that direction. Another good lesson. Don't fight the community. Okay, so let's say I found two possible modules. Both of them look really, really good to solve my problem. One of them is used on 20,000 sites. One of them is used on four sites. The one that's used on 20,000 sites is a really, really good module, but it doesn't do exactly what I wanted it to do. And the one that's used on four sites looks like it's got this one really cool feature that was exactly the thing that I wanted to accomplish. So there's a temptation to go with this one that's only used on four sites because it's perfect. Right? I have been burned by this more than once. Other people will tell you the same thing. Believe it, it's true. Don't do it. Don't take the perfect module that nobody's using over the less perfect module that everybody's using. It's not worth it. If only four people are using that module and you find that there's a bug, who's going to fix that bug? Who's going to maintain it? What if that maintainer gets tired of it and walks away and you have now built your site around it? What are you going to do? Whereas the one that the community is supporting, you're less likely to have to worry about that. So don't do that. Another good question, and we didn't used to ask, even think about this question, but it's a really good question now, is it exportable? So let's say I've got two sites. So exportable means... Are people familiar with features in exportable? Is anybody that doesn't know what I'm talking about when I say exportable? Okay, so there's a module called Features that lets you package code... Save functionality into code. So you can, for instance, set up content types and fields, and then you can save the way that you have set all that up and it creates a little module and then you can go put that module on another site and basically they'll have all the same content types and fields. It's a really nice way to move functionality from one place to another. You can use it for deployment from development to stage, you can use it to move functionality from one site to another site. Really, really handy stuff. Even if you're not using features, lots of other people are. And if there are two more or less equivalent solutions and one of them has a way that it can be used in features and is exportable and the other one is not, more people are going to use the one that's exportable because that's the way that people are trying to work. So again, it's not finding the community, it's finding the solution that the community is getting behind because you're going to have more support that way. Sometimes you just need to take it for a ride, right? You're down to the point, they both look good. You really can't tell if they're going to solve your problem without setting up a little site and giving it a shot. So I do this all the time. I do these spin-up teardown sites a million times a day. I mean, I do this all the time. Create a new Drupal instance. Don't clutter it. Don't try and do this on your site. You'll end up with all these modules and then you'll try and uninstall all these modules and you'll have all this crap out of you. Don't do that. Don't do that. Clean Drupal installation. Just put enough on it so that you can try this thing out, whatever this thing is that you're trying to do. Add the module to it, set it up, see how it works, try it out. Use Devel Generate. Anybody not familiar with Devel Generate? Okay. So the Devel module has a submodule that comes with it called Devel Generate. Devel Generate lets you create dummy content. It's a really, really, really fast way to set up a little prototype site. So you can create a content type in fields and then you can use Devel Generate and create some content, and now you've got a site with content and you can go do views or whatever you want to do. Very, very nice for prototyping. A couple of clues. If I want to see how these, you know, let's say I set up a... Let's say I'm trying to test a carousel site and I want to have some images. Devel Generate actually even generates images. It's very cool. So let's say I want to create an image content type and then I want to try it out in a carousel to see if that's going to work the way I want it to. I would create my image content type. I want to make the field required, even if it wouldn't have been a required field on my production site. If it's not required, Devel Generate is going to give me half the fields that have values and half the fields that don't... I don't want to see fields that don't have values. I want to see fields that have values. So make it required and that'll just force Devel Generate to do that. And then if I want to generate images, you can go into the image setting for the field and you can do a min-max size. If I really am planning on having a site that has 600 by 400 images, put that in and Devel Generate will create all the images of that size. So a couple of clues. So this is the way I try... this is the way I prototype. And the other advantage of this is it doesn't get into issues about what if you've got some incompatibility with that module and some other module that you're using. You're not messing up your site with a bunch of stuff that you're going to have to later remove. Just spin up a little prototype site, try it out. If it looks like something you're going to use, then you'll go ahead and try it out on your site. But don't do your prototyping on your actual site. So that's a lot of work. It is a lot of work. Unfortunately, you know, there's no way around it. There's a lot of stuff to look at. It takes time to do it. I don't have a way to make this not be work. So let's say we get through that whole exercise and say, we're coming up empty. I couldn't find a module. The modules I found didn't work. There's bugs. The release is shaky. I don't think that it doesn't look like they've got a stable release. Let's talk about some of the kind of problems that we can run into. What are we going to do about this? Well, first of all, are there bugs? Bugs are a different kind of a problem than its feature. It doesn't have the features I want. So possible that it actually works fine. You just don't know how it works. You know, I mean, that is possible. If I'm trying a module out in a prototype site and it doesn't seem, it seems broken, but I'm not seeing issues on the issue queue that says it's broken, that leads me to think that it's actually not broken and I'm missing something. So the next thing to do would be try the development version. Back in that screen where we had the development, those snapshot releases, the red ones, that's the development version. That's like the bleeding edge of all the latest fixes, all the latest features. Try that. See if that works better. See what that does. Look on the issue queue and see. Maybe somebody's already found the problem and there's a patch and it's out there and you could try the patch and see if the patch actually solves them. You know, if it's solving your problem, it looks like a great solution. The only thing keeping you from using this module is this one bug and there's a patch. Try the patch out. If there's not a patch, can you write a patch? Do you have the ability to do that? If there is a patch and you try it out, do everybody a big favor and mark that patch ready to be committed so that somebody gets it committed. You know, that's the whole point of it. Sometimes patches sit there for a long time and the only reason they don't get added back into the module is nobody bothered to go back and say this patch works. So do that. And then, again, as I mentioned before, let's say you found this module. There's some really important functionality that you want. This module really, really comes close to solving exactly what you want, but it is kind of broken and it says it's looking for a co-maintainer. If this is important to you, maybe your solution is jump in there and offer to be the co-maintainer. You can make it into what you need it to be. You can get the bugs fixed and you can use it. Different kind of problem. What if it's got the wrong features? I found a module. It looks pretty good. It does most of what I want it to do, but I've got this requirement that it needs to do this and this module just won't do that. So what do we do about that? Well, one thing is can you go back and adjust the requirements? Sometimes the requirements are written by people who have no idea how Drupal works. I've run into this over and over again, right? I mean somebody's just sitting there and just isolation saying, boy, I think we should have a website that does this. Sometimes you can go back to them and say, actually Drupal doesn't do that, but Drupal could do this. Here your prototype site could come up and you could show them, this is what we actually can do. This is what the module will do. Can we get away with doing that instead of doing what you said you wanted to do? It accomplishes the same goal. It's a little different than what you said you wanted, but what about that? Another thing to do is see, is there a feature request? Maybe somebody else wants to do exactly what you wanted to do. Maybe there's even a patch out there for it. If there's not already a patch, maybe, you know, is this something where you could visualize how this could be fixed to do what you wanted to do and propose a patch? If the maintainer is willing, that's great, right? Everybody wins. You patch it, you've got a module you can use, everybody's happy. And then the other thing that I've done this a lot as a way to solve the problem is to go back and say, okay, we've got a hard deadline of X. We've got a module that almost does what we need it to do, but it won't quite, and if we stop right now and invest the time to make it perfectly do exactly what the original requirements are, we can't possibly hit our deadline. But we can take the module that does this and we can do this and hit our deadline and then we can do a phase two where we roll back through and say, now let's come back and see how we can tweak it. And I've been able to make that fly a lot, especially when you say we will miss the deadline. Sometimes that gets a response. Okay, so we've done everything. We've tried it all. We've tried all these solutions. We've got all these modules. We've gone through the list. We've prototyped them. We've looked through the issues. We've tried patching. There just isn't a good solution for our problem. So now we're back down to, maybe we're going to have to roll our own solution. We should not be talking about rolling our own solution unless we've gone through that whole exercise. You shouldn't even be thinking about rolling your own solution if you haven't already done this. And there's a lot of reasons for that and I'll talk about some of that too. So Google again. Be sure there's not something else out there that you can do. Maybe now at this point we go back and we're Googling for issues and in this case what we're looking for this time is we're looking for a place where somebody else had the same problem that we're trying to solve and they did something like come up with some code. And I've run into this all over and over again. I find an issue someplace and somebody's got a code snippet. If you did this, it would work. Say, well, I could take that code snippet and run with it. I could just go ahead and use that as the basis for the solution. Sometimes you'll run into issues where somebody has gone through kind of the thought process of how would you solve this problem while I tried out this and this and this and that didn't work. And you have like a whole bunch of work that's done for you about how to address the problem and how to solve the problem. Now I go back. This is the point where I go back to Drupal.org, that search page that I showed you earlier. Now I look through sandbox projects because there maybe is a sandbox out there on Drupal.org that is devoted to solving this problem that I wanted to solve. When I'm using a sandbox project, I know I'm not using a production project. I'm not using production code. I'm taking responsibility for it. I'm going to adopt it or copy it or something. But at least it might give me a really good starting point for whatever custom code I've got to do. The issue with the code snippets, I talked about that. Another thing to try to do is... We're getting pretty good at this at Drupal. We've got a lot of kind of general use modules that can be used in lots of different ways where you basically just need to sort of add a little glue to things. So you use... I could use views and I could do this and I could do this with this, you know, in these special fields and that gets me like 80% of the way there is a little custom code on top of that to sort of finish it off. That's a good... That's a very Drupal way to solve a problem is to do that. And then another one is can you phase a custom solution in? Again, this is kind of going back to this two-phase thing. Can we go with what works out of the box as a starting point, get the site up, get that much working that is going to be coming back and doing the custom functionality? Now, if you've done all this work, let's say you've done all this work and you've actually created some custom code, you could contribute it back. You know, that would be a really nice thing to contribute it back because if it was a problem you had to solve, there's a possibility that other people need to solve the same problem. But that's the question, right? Is this something that's so you would ever use it? Not much you can do with that. But most of the time that's not the case. Most of the time you've got... You're solving the same problems other people are solving and maybe you've uncovered something that nobody else has solved. And if that's the case, think about contributing it back. There are a lot of reasons why advantages to contributing that code back. You need to think about it when you're writing the code, if you're thinking about writing code that you will contribute back. It's a little more generic. Don't hard code your variables, you know, that kind of stuff. But there are a lot of advantages because let's say you come up, you have solved a problem that nobody else has solved. You've created some custom code that solves that problem. Other people have that problem. So if you keep that as your own proprietary code, it's yours. It's on you now to keep it up. You're going to have to maintain it until Drupal changes APIs or some new thing comes out and suddenly your code doesn't work again. It's going to be your problem when it comes time to go from Drupal 7 to Drupal 8. You're going to have to figure out how to port that code. You're going to own it. It's yours. If you contribute it back, other people can help with that process. That is huge. Other people can also be testing your code. That's huge. Other people can tell you about bugs that we even knew they were bugs there. That's great. So think about that. Is there an existing module that does something similar? This is the time you need to be a little careful. Let's say I created a module that will do this and there's a widely used module out there that does something really, really close to that. We don't really need a whole lot more really, really similar modules. At that point, you should probably, rather than writing custom code, you should be thinking about, can I go back to that other module and add a new feature or a new submodule or package this in with that other module as opposed to trying to start a whole new project? And then, of course, you have to be able to write code that's general enough for wide use. The thing about this, though, is even if you don't intend to contribute it back, that's really going to push you in the right direction because it's going to change over time, even internally. And if you write custom code that only you understand and then you leave, well, maybe you don't care that you just screwed the next person, but anyway. So think about it. But there's other ways to contribute back. So if you've gone through this whole exercise of comparing modules, let's say you were trying to figure out the best way to solve such-and-such a problem and you did this comparison of all the modules that solved that problem and you figured out how they compare. And you couldn't find that information out there. You looked for it and it didn't exist and now you've created it. Write about it. Tell people. Let some poor schmo benefit from that work that you did. Post it someplace. Go back and add documentation on Drupal.org about it. Post screenshots about how it works. I couldn't figure out how to do this. Post screenshots, explain it. Let somebody else benefit from what you learned. Do a screencast. You can test and bump patches. Again, you found that there's a bug in the module. There's a patch out there. The patch works. Let somebody know. Bump it. Add comparisons. If you write comparisons, add them to Drupal.org. Validating your decisions. So be worried if you jump straight to custom code for an existing solution because you're going to own it and you're going to be sorry. If you avoided a time-tested solution because it was missing one tiny feature, don't do that. You didn't do your due diligence. Let's talk about some real examples. So, because it's kind of interesting, I think, to say, how does this actually play out in the real world? For instance, this is a Drupal 7 site. I'm looking for something that has an address field and does geolocation. And I found two possible ways to solve that problem. I found that there's this location module and it does everything. It's this gigantic module that does everything. And then I found that I could use this collection of modules, an address field module that creates an address field and then there's a geofield module and it creates a field that contains a geocode and it doesn't do anything else. And there's a geocoder module and the geocoder module will look up an address and find the geocode for an address and then drop it. And it works with the geofield module so you can say, get the address from the address field and drop it into the geofield. And then they depend on this geophp module. So first of all, you can look at the size of the code. And you can see well, you can do the math that that requires more modules but significantly less code. Right? So just on the code size alone I kind of lean in that direction just because I prefer not to have gigantic modules with lots of code if I don't have to. But let's say they both completely solve my problem either one would solve my problem and in this the example that I'm talking about, they would. I'm leaning that direction. This is actually kind of the Drupal way now is we used to have a lot of these in location modules, an old module. We used to have these gigantic monolithic modules that did everything. There was a image module that did everything you might ever want to do with images. And a whole lot of things you probably didn't want to do with images. And then there was that's the heritage of the location module. Everything you might a whole lot of things you won't want to use but a lot of things. So I lean that direction. If I click through and I look at the usage on the location module I can see that in Drupal 6 we had 25,000 almost 26,000 sites using it. In Drupal 7 it's about 17,000. So there's less sites using it in Drupal 7 than there were in Drupal 6 and this is a point in time where Drupal 6 and Drupal 7 are actually Drupal 7 has passed Drupal 6. So that says something. That says people are kind of moving away from it. And in fact if I flip over and I look at the usage on the address field module I can see that it's used by 27,000 sites which is more sites than we're using the Drupal 6 location module let alone the Drupal 7 location module. The path is clear, right? So the second solution is the one that's kind of taking off and the first solution is kind of doing this. And so based on that I went with the second solution. Another example and this was several years ago. So I needed this. I needed to have a view that had subtotals. I looked all over the place because I really didn't want to write it but it didn't exist. Nobody had it, didn't exist, couldn't find it. So I wrote a module called ViewsCalc that solved this problem and I posted it on Drupal.org. So other people can benefit from it. It's great. I'm still using it. Other people are still using it. I actually benefited from that in interesting ways. So I did this back in I think Drupal 5 maybe was when I originally did it and I ported it to Drupal 6 and then I got busy with other things and I didn't have time to port it to Drupal 7 and then Views 3 came out Views 6.3, remember we had Views 6.2 and Views 6.3 and actually what happened was basically Views 6.3 kind of broke it and it didn't work right with Views 6.2 but it didn't work with Views 6.2 so it needed to be rewritten so that it would work with 6.3 and it needed a port to Drupal 7 and I didn't have to do either of those things because somebody else did. So other people came on the issue queue they gave me the port to Drupal 7 I had to tweak it a little bit but I didn't do most of the work they gave me the code to make a version that worked with Views 6.3 that's the whole benefit of this I got something out of it I gave something back and then I got more so it's just a wonderful thing another example looking for alternative solutions for multilingual sites so I have somebody that was developing a Drupal 7 multilingual site turns out at the time very poorly documented it was very hard to tell how multilingual worked in Drupal 7 and it turned out when I did figure it out that there are actually two completely different ways of doing multilingual sites in Drupal 7 completely different systems and it was not at all clear what the differences were or how do you decide which one to use I ultimately figured all this stuff out and in this case what I did is I wrote articles about it and posted them on lullabot.com and I have pages of links to all the stuff that I found as I was doing the research because I couldn't find it another kind of question so organic groups in Drupal 7 so organic groups was completely rewritten from Drupal 6 to Drupal 7 everybody know organic groups? yeah completely rewritten from Drupal 6 to Drupal 7 rewritten to use the new entity system very cool very cool, really interesting and that was a 7.1 version I started doing a little bit of work with 7.1 and there were actually some problems with the way that 7.1 worked it was really complex and the problems started happening when you tried to do views because you couldn't do proper relationships back so it was hard to bring group information into a view there were other issues it was confusing there were a number of things so then there was a lot of discussion on the issues about that and actually I did an article about 7.1 so I wrote the article about 7.1 after I figured out how that worked and then there was all this discussion about these problems that were kind of emerging in 7.1 so I decided to do a new 7.2 branch and as I said before the fact that there's a completely different branch 7.1 to 7.2 is an indication that there's significant differences between them so there were a lot of new features a lot of new functionality that was going to go into 7.2 it was actually kind of he took advantage of the entity reference field and used that to connect the groups together it was a completely different approach it was really interesting liked it a lot but there was this period where 7.1 was the recommended release and 7.2 was sort of in development it was the other release and I think it still is not yet the recommended release but all the work is going on in 7.2 and in fact 7.2 is hands down the one I would go with at this point it's very production ready it's as production ready as 7.1 is and I think he's going to be doing a release that indicates that pretty soon but there was this confusion about how do you know which one to use and how does 7.2 work because as he was making all these changes what I found was there was all this stuff out there about how 7.1 worked but there was nothing about how 7.2 worked so nobody knew how it worked and so we did some videos for Drupalize Me about 7.2 to explain how it worked and then in the process of doing it I found that there were some things that you used to be able to do on Drupal 6 that you couldn't do anymore in Drupal 7 and so I created a project called OG Extras to bring back some functionality that was missing in there so that was how I contributed back on that one so other examples like I said sometimes you can do a bunch of existing modules and then a little bit of glue around them there's a project called Views Gallery Module I don't know if that really needed to be a project or not but it's kind of an example of how you can create a feature that does this and it was based on Jeff Eaton did a blog post about how you build a gallery a photo gallery using views and it's complicated it takes like you know there's like 10 modules and there's all this configuration that you have to do and everything and actually you can use the features module to sort of lock all this stuff up and you basically just have to enable the module and it all works so Views Gallery was that it was making that into a feature and sort of making that really a one step thing but that's an example of how you can do something like putting a combination of things together with a little glue and one last thing and then where I think we're just about to the end of our time choosing between alternative CCK versus FlexiNode anybody around in FlexiNode days you have to go way back in Drupal to remember FlexiNode so back in Drupal 4.6 there was a module called FlexiNode which was the first way of creating adding custom fields to your content types it was really interesting but it didn't scale and the guy that wrote it actually said and people loved it jumped all over it but the guy that wrote it said I did it all wrong we need to completely rethink it and a bunch of people went into a room basically to figure out how we're going to do fields in the future and they came up with the idea of CCK and so they started the CCK module in Drupal 4.7 so in 4.7 you had a choice of using FlexiNode which was the established solution CCK which was the brand new thing and it was completely broken I mean it was completely broken it was so badly broken I can't even tell you I was looking at that that was the point where I was trying to build my site and I said clearly CCK is the future I should go that route rather than FlexiNode totally was the right decision because the original plan was that there would be an upgrade path to FlexiNode to CCK but that never happened but anyway so I got into CCK but it was broken it was completely broken so I started submitting patches and trying to fix it I knew people wanted to use it other people started diving in there lots of people started diving in there and we made it work so again just another example of sometimes the solutions there so so that is that's all I've got if I had extra time I was going to do an open mic and see if other people had other ideas but I have I apparently talk too much so please do an evaluation it helps the Drupal, the convention people do future things and I appreciate your time we'll talk to you up here though yeah yeah yeah well the problem is if things work well first of all it's more complicated I mean you can you can I think well for one thing it's hard to figure out what the new module is doing when you've got a lot of other modules doing things so if you do a clean install it's really obvious what is that module doing what's it changing what's different about the way that things work by then if I've got all these other things going on your module seems to be actually breaking the new module but you don't know that your theme could be breaking the new module and there's lots of other things so it's hard to evaluate the module thank you unless now at some point if you decide that that works then you do have to see how it goes so that's that's going to be another step right yeah yeah yeah yeah yeah yeah yeah yeah yeah