Need some help with your project? Contact me

Go custom or use a contributed module?

That is the main question. If you came here looking for a definitive answer, I'm afraid you won't find one. What you maybe will find is a discussion I propose on this topic and my two cents on the matter.

Why am I talking about this?

I've been working on a big Drupal website recently which has many contributed and custom modules. One of my recent tasks has been enabling validation of an existent text field used for inputting phone numbers. The client needed this number in a specific format. No problem, a quick regex inside hook_node_validate() should do the trick nicely. But then it got me thinking? Isn't there a module I can use for this instead? Well yes there is: Field validation.

I installed this module which comes with a plethora of validation rules and possibilities. The default phone validation for my country was not matching the client expectation so I had to use a custom expression for that. No problem, achieved basically the same result. But was this the better option under the circumstances? You might say yes because people have been working on this module a long time to perfect it, keep it secure and provide all sorts of goodies under the hood. Not to mention that it's used on over 10.000 websites.

However, the Field Validation module is big. It has a bunch of functionality that allows you to perform all sorts of validation on fields. This is not a bad thing, don't get me wrong. But does my little validation need warrant the installation and loading into memory of so much code? My custom solution was very targeted and took no more than 10 or so lines of code.

One argument would be that yes, because I may need other kinds of validation rules in the future so you can use this module also for those. But I think that being already very far in the lifetime of this website the odds are quite low of that. And even if this is the case, will an extra 2-3 validation needs warrant the use of this module?

On the other hand, you can argue that your custom code is not vetted, is difficult to maintain, can be insecure if you make mistakes and basically represents some non-configurable magic on your site. These can all be true but can also all be false depending on the developer, how they document code and the functionality itself.

I ended up with the custom solution in this case because on this site I really want to introduce new modules only if they bring something major to the table (performance being my concern here). So of course, the choice heavily depends on the actual module you are considering, the website it would go on and the custom code you'd write as an alternative.

Moreover, please do not focus on the actual Field Validation module in this discussion. I am not here to discuss its merits but the whether or not installing any such module that serves a tiny purpose is the right way to go. This is mostly a Drupal 7 problem as in D8 we use object oriented practices by which we can have as much code as we want because we only load the necessary parts when needed.

So what do you think? Do you have a general rule when it comes to this decision or you also take it case by case basis? If the latter, what are your criteria for informing your choice? If the former, why is this? I'd love to hear what you have to say.


From my experience, the choice come always to this, when I have to chose between custom and contrib :

  • Contrib is safier and scalable
  • Custom allows better perfs (I code only what I need and I can more easily implement performance considerations, like caching) + I can do exactly what I need + if I had to add something, i know where to go and what to do.
  • The other part is about myself : will I do it faster with code or a contributed module ? 90% of times I think I'll do it faster with custom code.

    The other part to think about is your colleagues : Who will take care of your functionality after you ? Will he / she be more at ease with custom code or complex configuration of a module ?

    Hey Greg,

    You can indeed argue that contrib is safer in some cases. I think it also depends on the amount of code we are talking about. A big contrib module is more likely to be unsafe than 10 lines of custom code if that is all you need.

    As for the devs who take over my code. I think here contrib has many points as Drupal devs know contrib modules but have to research your custom code (for the most part). Though if a dev writes good code, I like to go into his/her code :)

    I don't know about all the details of your project, but I'd probably go with custom module too. Specially if it is a site where a lot of traffic is expected I'll only use those contrib modules that are not to big and don't come with lots of unneeded functionality. Mainly for, but not limited to, performance reasons.

    I also argue that contrib modules are not necessarily more scalable and easier to maintain. I believe that one needs to understand code not only of own custom modules but also of contrib modules that are used on a project. When you look at it from this perspective the price of maintaining contrib modules suddenly becomes more than $0.

    I also argue that contrib modules are not necessarily more scalable and easier to maintain.

    I do not maintain contrib modules, so to me, they are always easier to maintain.

    I believe that one needs to understand code not only of own custom modules but also of contrib modules that are used on a project.

    You've dug into Views and Ctools code? If you are going to take on an unnecessary burden when using contrib modules then of course you will favor custom modules.

    I agree the example use of a custom module is fine. But this barrier to contrib code is way too high.

    Exactly that, it's also about myself, but in terms of spending time.

    When I take all in consideration, for smaller site maybe will before use contributed module (to save my time),
    but for complex decision is always harder, while it depends more on performance, then of case of reusing contributed module. And it's necessary to avoid too many modules if possible

    There was a related podcast (, Modules unraveled podcast) on this fairly recently. It points out for small "minor" things that require a "few lines of code" (Say a simple regex as per your example here, or the example in the podcast of an entity view-mode) you may be better writing a custom module. The larger it gets the better to use a contrib module. I've yet to find a good rule of thumb as to the best way to handle this, but have been using a "25 lines of code" (excluding comments) rule for the past 2 months and this seems to serve me well for the moment, but would be interested in seeing others limits/standard assumptions on contrib vs custom.

    I know we do not want to get too far in the weeds with the specific case but I think it is worth saying it is a good idea to avoid using PHP in the database. That is one of the rules I use for deciding if I want a custom module or use a contrib module.

    Hey there,

    I don't think at any point did the idea of PHP in the database came up. Let alone there being any arguments FOR that approach. As you say, a terrible idea :)

    I thought that was how you you were doing the custom rule with the validation module. I know it lets you do that.

    Yes but you most likely put regex in the db not raw PHP code meant to be evaluated. I have not checked all the possibilities though. So if I am wrong, indeed it's bad :)

    You remind me of a diagram I 've created once for the same topic "When should i create a new drupal module?". There is a useful diagram also.

    If you have to spend more than a day on a custom module then better go for contrib. On the other hand, some contrib modules are not of really good quality. I've also seen contrib modules with bugs and security holes in them.

    For me time is not a factor here. If I spend a day on custom code it very well may be because contrib doesn't offer this particular option for me. Though indeed, one day of custom code that just replicates perfectly a contrib module is probably not advised.

    I think you made an excellent analysis of your needs (performance, lightweight) and pointed out the essentials of custom vs contrib:

    • consider performance
    • consider safety
    • consider debugging and follow-up

    Keeping these in mind, you're likely to make a sensible decision in any given situation.

    Something that performance consultants always bang on about is the number of enabled modules on a site. (Though without specific details as to why more is worse, usually.) If you already have a custom module, and you can provide the functionality you need by adding code to it, that's another motivation to go that route.

    The more modules you enable on a site the more module information gets loaded (but also cached) in any given bootstrap. The problem with this is that all the code in .module files are always readily available so Drupal needs to always load them all. So if you put all your code in the .module file it can become heavier than it needs to be. It's always recommended to only put hook and preprocessor implementation there (things that really need to be loaded all the time) and try as much as possible to keep helpers and various business logic in include files that you only load yourself when you need them.

    That being said, I also don't like the approach of having a general custom module where all the code gets dumped. I like to create separate modules to group functionality logically.

    Add new comment

    You can post comments in Markdown and basic HTML tags.
    For code blocks, wrap your code within '~~~'. For example:
    $var = 'my variable';