1. I'm Chris Shattuck and this is Welcome to Module Building. In this video we'll talk about the benefits of module building and we'll create a two minute module. If you look closely at the Drupal development learning curve you'll see that it is actually made of of a number of tiny steps. When you are on the curve it's kind of hard to tell exactly where you are, so consider this video a little "You Are Here" sticker.

2. By simply pressing the play button, you have said a lot about the steps you have taken already. For example, you know what a module is and you either suspect or you know that to get the functionality that you are looking for, you need to build a module of your own. But why do you need a module? I mean, why not simply download Drupal and start tweaking the code directly? It is open source after all.

3. By doing so, couldn't you sidestep a lot of the time that it takes to learn the layers and API's of Drupal and get what you need done more quickly? I'm sure you already know the answer to this, but just in case you jumped over a few of those learning curve steps along the way, let me fill you in on just what you get by wrapping up the code in a module instead. So if Drupal is a nuclear power plant, then adding modification to the source code is a lot like trying to power your vacuum by plugging it directly into the reactor. First of all, as far as I know, nuclear reactors don't have that kind of interface for supplying power to household appliances.

4. And secondly if you try to plug it in anyway, you are likely to cause a giant explosion and kill a lot of people. This metaphor might seem a little extreme but it is surprisingly on point. Just as electrical power becomes useful only when it is channelled through an outlet of some kind, the power of Drupal is channelled through its API's.

5. And the more you monkey with the inner workings of Drupal, the more likely it is to melt down. Next, working with a modified code base really kills the joy of upgrading Drupal. Upgrading should be a pleasure.

6. I mean, you are absorbing all these free bug fixes, improved security and added functionality for free. And not only should this be celebrated but regular upgrading is an essential requirement for a lot of my projects. With a modified code base though, instead of just dropping in the new files and replacing the old ones, you instead need to carefully extract and reapply all of your modifications to the new version.

7. And if your changes aren't well documented, it is easy to lose something along the way. It's even possible that you would find yourself avoiding upgrades all together and once the bit rot sets in after a few upgrade cycles you could actually find yourself in a position to completely abandon or simply rebuild your project. So upgradability is critical but is is only part of the module story.

8. Imagine for a moment they you have made a fantastic modification directly to the code base and you just have to have it on another project. How easy is it going to be to copy your changes over to that new project or what about copying it to 10 projects. And say 10 project are actually using your modifications and then you find a bug.

9. Well, the ability to share your code between projects and effectively push out bug fixes and updates can make a huge difference in productivity and quality, so if instead of modifying the source code directly, you wrap up your modification in a module, everything is in one place. And there is a number of methods that exist for then distributing your code across different projects, either public ally or internally. Basically what modules give you is code portability.

10. There is one more big bonus that you get when building a module. Because there is typically a clear path forward when modifying the behaviour of Drupal or adding new functionality, it make module code fairly reliable. This reliability then lays a foundation of solid techniques and rules for working with other developers.

11. And it's solid enough that many developers find it is relatively easy to ramp up on a Drupal site that somebody has built. Plus in a few months when you review your own work, there is some clear structure there that help you navigate your code, even if you didn't have a chance to write good comments at the time. So by keeping your code in a module, you get the power of Drupal's API's.

12. You get upgradability, portability and reliability. When you really understand these benefits, the time and cost of learning how to build modules the right way, it is more than justified. It is actually a steal.

13. Given all of this you would think that it would be really hard to wrap your mind around something so powerful right? Well, yes and no, but mostly no. For example I'm about to show you how to build a module in just a couple minutes and that same module structure can then be used as a starting point for any other module that you need to build. And many of the concepts around module building are just like this.

14. They're easy to grasp and they are easy to implement. The tricky part is that there is a lot of concepts. So for example, there are over 250 functions that allow you to hook directly into Drupal to do anything from adding triggers and actions to altering the content of Drupal's search index.

15. There are also numerous API's that allow you to plug into forms, add new kinds of fields and work with files in the database and that's just to name a few. But if you find this daunting, there's a couple things that might help you out. First, what all this functionality means is that when you need to modify or extend Drupal there is probably a function or an API that will make your life a whole like easier and that's encouraging.

16. Secondly, many modules just touch on one or two of these features and that means you only need to know just what you need to know in order to get what you need. So it's ok to start small. Throughout the course of this video series, we are going to be spending some time working up the learning curve; step by step.

17. But We're also going to be spending time above the curve looking at what's behind us and at what lays ahead. We just spent a few minutes above the curve reviewing why putting your code in a module is a good idea and hopefully I have filled in a few gaps. Now we are going back to the ground level to take a few more steps up while we build a very simple module.