Why to build a module instead of modifying source code, and how this video series works (a Drupal h


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. 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. 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. 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. 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. 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. 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. Imagine for a moment they you have mad 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 filed
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.

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Post navigation

3 thoughts on “Why to build a module instead of modifying source code, and how this video series works (a Drupal h

  1. This is sad. The video starts with: "In this video we learn …. and create a 2-minute module".
    After an introduction of 6:23 minutes it ends with: "setting up a module".
    Of course: no module is created…

    Save yourself 6 minutes and browse to their website directly where you will learn that FREE video's COST $23/month.

  2. @zandbJ Sorry about the miscommunication there. The title screen at the end segways into the next video which is also free . Even though there's a fee for access to the whole collection, there's still over 7 hours of free material, much of which covers the creation of the 2 minute module.

    Sorry again, hopefully this helps move you on the right track.

    Cheers!
    Chris

Leave a Reply

Your email address will not be published. Required fields are marked *