Profile picture for user admin
Daniel Sipos
29 Jun 2015

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.

Profile picture for user admin

Daniel Sipos

CEO @ Web Omelette

Danny founded WEBOMELETTE in 2012 as a passion project, mostly writing about Drupal problems he faced day to day, as well as about new technologies and things that he thought other developers would find useful. Now he now manages a team of developers and designers, delivering quality products that make businesses successful.

Contact us


Greg 29 Jun 2015 13:00

Security + Scalability VS Performance + Agility

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 ?

    Daniel Sipos 29 Jun 2015 13:42

    In reply to by Greg (not verified)

    Hey Greg,

    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 :)

    Janez Urevc 29 Jun 2015 15:47

    In reply to by Greg (not verified)

    I don't know about all the

    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.

    Brendan 01 Jul 2015 21:36

    In reply to by Janez Urevc (not verified)


    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.

    Vallic 04 Jul 2015 16:02

    In reply to by Greg (not verified)

    Exactly that, it's also about

    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

    David Thorne 29 Jun 2015 15:09

    There was a very interesting podcast along these lines recently

    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.

    Steve Kessler 29 Jun 2015 19:12

    PHP in the Database

    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.

    Daniel Sipos 29 Jun 2015 19:21

    In reply to by Steve Kessler (not verified)

    Hey there,

    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 :)

    Steve Kessler 29 Jun 2015 20:32

    I thought that was how you

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

    Daniel Sipos 30 Jun 2015 07:11

    In reply to by Steve Kessler (not verified)

    Yes but you most likely put

    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 :)

    Theodoros Ploumis 30 Jun 2015 00:07

    I was thinking about it some years ago...

    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.

    Alma 02 Jul 2015 17:11

    If you have to spend more

    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.

    Daniel Sipos 02 Jul 2015 17:23

    In reply to by Alma (not verified)

    For me time is not a factor

    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.

    nordicmaterial 02 Jul 2015 18:32

    The right choice

    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.

    Anonymous 02 Jul 2015 21:30

    number of modules

    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.

    Daniel Sipos 02 Jul 2015 21:06

    The more modules you enable

    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