Contrib Development Best Practices

Contrib developers often need some help figuring out the best way to maintain their modules, both strategically and tactically.

This can include (but is not limited to)

  • git best practices in contrib (branch naming? How to commit patches? How to commit my own work?)
  • How to manage the issue queue
  • How to deal with difficult people in the issue queue.

When we reach consensus and develop some quality material, it can move over to the Best Practices section of the Handbook (under Start a new project).

Mario Steinitz's picture

Modules *should* implement hook_help()

Having reviewed a module recently within the Security Advisory Coverage application queue, a discussion came up of whether hook_help() must be used or should be used to comply with the module documentation guidelines.

The guidelines state

All but the most trivial modules should implement hook_help().

in bold letters.

Read more
Charles Belov's picture

Best practices for deprecating old module/adding new release

I'm wondering what is the best practice for creating new releases of modules and deprecating the old version, in terms of maintaining security while the new version proceeds to release status. I'm asking this as a Drupal newbie.

Read more
pwolanin's picture

Wastelands group defunct/not needed?

This group looks defunct and will be merged or deleted in 1 week.

Especially with the availability of sandbox projects, and the frequent pushing of code to places like github this seems a solved problem.

Read more
mlncn's picture

Recommended Markup Guide for Modules

I'm referencing the Drupal Markup Style Guide g.d.o wiki in the Definitive Guide to Drupal 7 and it hasn't been updated in a couple years so i wanted to give all interested parties, especially HTML5 folk, foreknowledge to update it (or link it to a d.o equivalent?).

Advice is sound and it's the most comprehensive take i've seen from a module developer's perspective, so that's why i'm providing the link:

Read more
arianek's picture

Sprint based development for Drupal 8

Hi Drupalfolk -

I documented a bunch of the ideas/discussion points from Dries' D8 core convo on a blog post:

I am considering making a page/section in the Initiatives section on d.o but would really like a bit more input first - I got a lot of positive tweets and a couple more detailed comments, but I still am not sure exactly how much support there would be for this, nor how much more detail would need to be hashed out for it to become a method that people would be comfortable experimenting with.

Read more

Package names for contributed modules (Drupal 7)

Modules are grouped on the module administration page (admin/modules in Drupal 7) by package, which is defined, optionally, in our module's .info file. Package, then, is the most visible way in which modules are categorized. This wiki page documents package names chosen by module maintainers, please edit it!

Read more
mlncn's picture

Package names for contributed modules

Modules are grouped on the module administration page (admin/modules in Drupal 7) by Package. Sensible grouping can greatly enhance site builders' Drupal experience. (Package is defined, optionally, in our module's .info file.) As developers of contrib modules, we can come to this wiki page before choosing our package name to see what other thoughtful module developers have chosen for their package.

Read more
arianek's picture

Should the docs style guide apply to interface text?

A ping in #drupal-docs earlier has brought to my attention that the Docs style guide only applies to handbook and not explicitly to interface text in Drupal core/contrib.

I'd think it should apply so we get consistent text and grammar formatting Drupal-wide, but didn't want to make such a sweeping declaration without some consensus from the community at large.

Read more
xurizaemon's picture policies on module behaviour

I posted this question yesterday after seeing some contrib code (not yet submitted) which included HTML tags to track module installations.

I'd appreciate any pointers or feedback on the practice, and how we can educate contrib developers about what practices are and aren't acceptable in code hosted on

I don't know of any specific security or privacy policy this practice would be forbidden by, even though to me it seems clear that the practice wouldn't be acceptable.

Thanks in advance!

Read more
DrupalCuckoo's picture

Call hook_node_access_records() from custom function


usually the hook "hook_node_access_records($node)" gets called when you hit the save-button on the edit page of a node. I need to call this function outside the edit-form.

I'm building a custom content-privacy module and I need to call this function for all existing nodes filtered by content-type (for example all blog nodes).

The problem I have is that this hook needs a node-object as a parameter. When being on a node-edit page (node/[NID]/edit) this object will be available. But when I don't edit a node I have no node-object available.

Read more

Proposal for "Best Practices in Contrib Development" Drupalcon session

I'd like to get some of you great people to give a panel discussion on best practices. Here's a proposal - edit it! Who would be willing to lead it? Who has something to offer?

Session Proposal: Best practices in Contrib development and support

Contributed modules and themes are fundamental to the Drupal experience, but the quality varies oh, so widely.

How can we improve our development process, keep modules maintained, help maintainers, and somehow harness the explosion of modules.

This forum will cover:

  • What's expected of a module maintainer
  • How to keep the modules you maintain from overwhelming you
  • How to get help from others
  • Finding maintainers, abandoning projects, dealing with abandoned projects
  • Best practices in CVS, including when to branch, and how to maintain branches
  • Best practices in patch issue workflow
  • Best practices in the issue queue: How to enlist the community, deal with support, and deal with newbies.
  • Avoiding duplication in contributed projects
Read more
ilo's picture

Branch versioning across Drupal versions

So, I've got a question pointed by a services module discussion.. What should be the best practice for contributed module versioning when Drupal version is updated, keep current contrib versioning?

Read more

Methods of managing commits, patches, and issues

Here are some notes from a discussion with greggles that influenced me on managing commits and patches:

  • Every commit should be matched with an issue that has a patchfile, just as would be done in core.
  • Every commit should give credit to the contributor of the patch, and a link to the patch. This page gives a great summary

This can seem hard to do in a rapidly developing project, but it gives great discipline to the code.

Read more

CVS Practices for contrib

There is a standard Drupal (and maybe everywhere) methodology for managing a project in CVS, but not all of us know about it.

  • Always do new development on HEAD.
  • When the time comes to leave a branch behind (as when beginning Drupal 7 development) branch off the old (like D6) stuff. Continue working on HEAD.
  • You can apply patches from HEAD onto other branches, if you have other branches going.

This is the approach described in the fine Pro Drupal Development.

Please add to this.

Read more

Best Practice notes

Drupal Coding standards

Follow the [Drupal coding standards] ( The coding standards provide information on code syntax, white space in code, and currently more development detail than this wiki page.

Required Files

When a module gets too long it is wisest to break up a custom module into the following files:

  • - Module declaration file.
  • MYMODULE.module - for Drupal hooks like hook_menu, hook_forms, etc.

Additional Files

Read more
EclipseGc's picture

WOW! I'm not alone here anymore!

HAHA, welcome everyone, been a while since I checked this group. So, here's the basic need to get us going. I'd really like to put our heads together and start to put a list of features that would be needed for this sort of thing, together. Let's get it started, and we'll see where it goes from there.

Obviously we need some serious taxonomy controls to help make code easier to find and categorize. I'd like to start off by asking what sort of scheme you all think might work best here.


Read more
joachim's picture

Wastelands: Let's start thinking about use cases and spec

So I'm at DrupalCamp UK and the topic of this site has come up again.
Lots of developers mention cool modules they've written in-house but aren't releasing because they're too specific to their projects or too raw for a release.

A space where these could be released without too much expectation would mean the next person who needs this feature doesn't reinvent the wheel, but instead can give some time to pushing the code a little more towards being generic and ready for release.

So let's think about use cases for the Wastelands and the spec we'd need.

Read more
julma's picture

Turn it more positive : what about a "Recycling drupal code factory" ?

I think there is a huge potential in this idea.

There are lot of modules on d.o that are not maintened, and lot more code never published.

A true "recycling drupal code factory" could have several benefits :

To allow the drupal community to better understand the general needs behind lots of "custom modules", reuse some code but also some conception work.

For the beginners users of d.o, a smaller list of contributed modules really maintened instead of a large list of 2000 modules with lot of weird modules would be a huge time saving.

Read more
sirkitree's picture


So I came here expecting a list of a bunch of modules that has been tossed out as incomplete/un-generalized. Found nothing but a poll. Hrm.

So the thought then is, how do I get a list of modules that are categorized in a way that I know that they either a) need work or b) are specific to a private company's needs but released for other to at least peruse/hack/learn from/or throw away?

I don't think we can actually just list them here...
I don't think that we should really just throw them up on d.o (read:

Read more
Chris Charlton's picture

Do you collect code scripts?

Yes, and I would cry if I lost them.
36% (5 votes)
A little; I try to.
14% (2 votes)
No, I don't collect code scripts. (I rely on google)
50% (7 votes)
I bookmark code/scripts I find on the web
0% (0 votes)
What the heck is a code script/snippet?
0% (0 votes)
Total votes: 14
Subscribe with RSS Syndicate content