Skip to content Skip to navigation

3 Tips for Making Your Drupal Features Highly Reusable

Dear Developers, if you follow these simple guidelines, your Drupal Features will be much more useful to institutions like Stanford over time. You will win friends and influence people. Drupal will live up to its potential, and there will be much rejoicing.

1. Small Features, Loosely Joined

For institutions like Stanford that have multiple Drupal projects all happening at the same time, spread across different teams, it is important to establish norms that make reuse more likely. For Features, smaller is better. The atomic unit for a Feature is the Content Type. If you do nothing else, make one Feature per Content Type and resist the temptation to put anything else in it.  Whatever else you got going on: Views, Rules, Feeds, Services, etc. keep all that stuff in separate Feature(s) that list the basic Content Type Feature as a dependency. To maximize its reuse potenial, your Content Type Feature should not itself have any dependencies on other Features*.  It’s common for developers to use a <prefix>_base Feature that bundles common site attributes (like image styles and variables) that all the other Features depend on.  In our case it’s better to either a) not do that, or b) make it easy to discover and undo that.

2. This is my prefix. There are many like it, but this one is mine.

One attribute that all highly reusable Features have in common is a prefix, consistenly applied. I have stood up a hasty prefix registry on techcommons (until we decide to make a better one). Each unit of the university should use just one prefix over time. This will take a little care and attention, but I have faith in us. Here are some of the existing claimed prefixes. If you have a small project inside one of these organizations, please use these instead of registering a new one:

  • gsb_ (Graduate School of Business)
  • soe_ (School of Engineering)
  • earth_ (School of Earth Sciences)
  • dor_ (Dean of Research)
  • stanford_ (Stanford Web Services)

To see the complete list, and to add to it, please visit techcommons.

3. Namespace them thar fields!

Many of you are already making Kit-compliant Features. That’s good! (We like Kit.) So please do read and follow the Kit spec for Features. We also need to extend Kit some.  Our primary concern is field name collision, or anything else that would prevent a Feature from being successfully introduced to a new Drupal site outside its original distro. Like most everything else in Drupal, we do this with prefixes (technically, for fields these are infixes).

Things we prefix:

  • Modules and functions (natch)
  • Content Type machine names
  • Views machine names
  • Fields
  • All the things

The Cantor Center is creating a Drupal Feature for their exhibitions. They know that prefixing is important, and they don’t want to collide with similar projects currently underway by the Department of Art and Art History or the Libraries, so they employ the prefix cantor_ consistently across all their properties, and edit the techcommons page to let others know that they have done this.

Content type: cantor_exhibition
Field: field_cantor_exhibition_image
View: view_cantor_exhibition_gallery

You’ll notice that we use a version of Hungarian notation, whereby the machine name indicates what that thing is. For field names this can be a little challenging due to the 32 char limit on field names (and Drupal uses up the first 6 with field_ ) but if we all stick to this convention our Features will get along with each other, and as a University and an open source community we stand to gain a great deal more over time as increasing number of these Features become Highly Reusable Features. (HRF? I’m trademarking it! I want a quarter any time someone says it!)

If we do nothing other than harvest the humble Content Types from our various projects, that alone is a huge win for us.  This point may get lost in some of the flashier Drupal applications being built these days, so it’s important to call out:  Drupal is a marvelous content modeling framework, and the Content Type contains a lot of important information about a particular domain or group that is highly shareable.  We don’t have a single, uniform higher-ed use case. We have hundreds of use cases. The Content Type emerges as an extremely relevant and legible artifact of prior work that we can learn from, adapt, and develop over time.  We are looking for development teams that are willing to join us in this endeavor (and show the perseverance to slog through overly verbose blog posts!).

Call me maybe

Any development team that wants to connect directly with me to discuss our Features best practices is more than welcome to do so! The absolute best time to do this is when the content model is just taking shape, before you make your first Content Type. There is one vendor team that already is doing all of the above consistently (you know who you are; thank you!) it would be amazing if we get to a point where everyone does.

*one obvious exception to the no dependencies rule is a Content Type feature that includes an entity reference to another Content Type. Dependencies aren't bad, we just want to remove unnecessary ones.


Hi Zach,

Great post!

Because your Features architecture is so granular, any given site leveraging this will likely have a large number of Features modules. Coupling that with the typical amount of contrib modules used, I could see a site having well over 200 modules.

There are obviously performance issues when using lots of modules so do you have any special tricks for helping soften this beyond the standard Varnish, Redis, Memcache, Views caching, and core Drupal caching configurations? Do you use a CDN?


p.s. Thanks to the Stanford team for the latest camp!

p.p.s. Posting from phone so please excuse any typos or wording issues ;)

Hey Kristen! Thanks so much for presenting at camp, you and Aimee are great contributors.

About the number of Features, that this creates, is actually far less than what you're imagining. Our Stanford Sites environment has less than 100 contrib modules (including our Feature modules).  Like you I start to worry when a site takes on too many modules. What's that sound? That's your SQL server crying... We've actually stayed pretty lean.

I'm not a devops guy, and I've never actually worked with a CDN, is that something that I should know more about?

We're normally under 150 modules enabled even on the largest prod sites. We have run into some overhead issues at times (e.g., on the admin/modules page, or when clearing caches and parsing all the .info files), but it's a balancing act between that and being able to build many disparate sites on the same underlying architecture. We've rebuilt many of our Features to break down the monoliths into discrete building blocks.

Where we try to trim the fat is in overall functionality ("Does this site really need an Intranet? A publishing workflow with multiple layers of review and approval? 17 roles and 53 content types? No.")

Most of our overhead issues have been more to do with trying to run 1400+ Drupal installs on one service :)

Makes sense... good to not introduce unneeded functionality in the first place. I'll have to figure out how to convince our clients on the virtues of that as we do struggle with too many modules due to large/complex sites (example: we have 45 *custom* modules alone for our biggest project but that includes all Features).


One of the things that I tell our clients at Stanford is that Drupal has tens of thousands of contrib modules, but you really only want less than one percent of those on your website. Isn't it really more about containing expectations about functionality and scope? I like Alan Cooper's book for making this case, even though some of the examples are a little dated: The Inmates are Running the Asylum. The gist is that, with limited resources, we need to say no to the temptation of adding more (lower case) features, and focus on usability instead because that's what users actually want.

That is good news... you are doing well if you can stay below 100 :)

As for CDNs, we are using Cloud Flare for a couple sites but mainly for the spambot protection. The other benefit is that it helps with performance by keeping some of the spambots from getting to your site and sucking up resources. Also, CDNs can be used for distributing your assets around the world if you need to have faster load times globally. But, if you are getting good load times without it, then no reason to add more complexity.