Scared Of Features? Don't Be!

I'm an experienced Drupal developer. I've been embedding stuff in code for ages now. Views, Panel pages, ImageCache presets, even putting CCK content type exports in to hook_install() implementations just to try to keep stuff in code. Many of you are probably in the same boat. Keeping stuff in the database brings all sorts of ugly deployment and performance issues, so we avoid like the proverbial plague.

Now, just in case you've spent the last year on the planet Zog and have only just returned, there's a neat module these days called Features which supposedly does all this for you.

After months of procrastinating over when/if to take plunge in to Drupal development with this whizzy new module, I finally did it this week. And wow. Just... wow.

So what took me so long? Well, mainly it was the fear of another steep learning curve and me already working 10 hour days as it is! Knowing how much of a PITA it is to do all this manually, I naturally assumed Features would be horribly complicated and I sincerely could not face learning anything under the present workload, so I put it off and put it off and put it off...

Until I had a fresh project that I figured would really benefit from the Features model. I installed it and off I went.

I had already created a Yahoo! Answers style element in Drupal for my client. It felt like the perfect starting point for a nice new Features-based module. It was basically made up of some content types and views. The content types had some fancy CCK stuff going on (mainly using the excellent Nodereference URL) and the Views had some fancy display settings (courtesy of Views Attach and Views Slideshow), but essentially there wasn't much to it after the configuration.

Time to turn it in to a module. Hmmmm. Deep breath:

So, where is Features hiding?
Site building -> Features... that feels like a good starting point.
Hmmm, no Features installed yet, that figures.
Create Feature? Probably.
Name, description, version, all seems obvious enough. Mkaaay...
URL of update XML? I'll ignore that, it's not compulsory and I have no idea what it should be...
Add components? A drop-down list... now this looks interesting...
Content types, I got some of those... Question and Answer (ticky tick tick).

That's when I nearly wet myself.

OMFG, it just auto-added all the module dependencies! How cool is that?!
Views, I got some of those too... questions and answers (again! tickety tickety tick those checkboxes).
HA! It did it again! views_slideshow and views_attach added as dependencies automatically. Awesome!!
Hmmm, it didn't pick up the core Statistics module. I need that for reads.
No matter, there's a "Dependencies" option.
And yes, it's a list of enabled modules. Hurrah! Ticky tick Statistics.

Yup, I do believe that's it. Click the "Download feature" button, I guess?
A packaged module! Content types, Views and all dependencies.
Install it back on the site and bingo, there it is on the currently installed Features list.
That's it, I'm finished! That took, oh, 2 minutes?
Wow.

Intuitive? Hell yeah!

I certainly need not have been so concerned about learning curve. Actually Features is easy peasy - far easier than I ever imagined it could be. In fact, I can honestly say you no longer need to have a clue about Drupal development to make Drupal modules*. My two-year-old could build a module with this! This is the coolest thing since the bread slicing machine, seriously.

* But you will need the Features module, naturally.

Then there's the other things you can do. There's drush integration (for command line Features module creation and updating), there's the Strongarm module (for exporting variables, amongst other things), there's CTools integration for creating exportable objects, etc. etc. Just read the project page.

But even if you don't want to get in to all that. Even if you've simply made some sort of simple application, you think it's worth sharing and you don't want to have to build it all over if you need it again. Make it a Feature! You don't need to know a line of code. If you know your way around the Drupal UI well enough to create content types and Views, and you have the necessary bodily appendages to allow you to wield a pointing device and tick boxes, you can make a Drupal module.

The only thing I really miss is the ability to bundle user roles and their related permissions settings with my Features module. (Or at least, I think I miss it? Maybe you can already do this and I've missed the option.)

Before I sign off, quick note on sharing Features-based modules. I think I'm right in saying you can't just stick them on Drupal.org. Or people aren't doing anyway, even though thinking about it, I don't see why not if you have CVS access. Perhaps someone can expand on that in the comments?

Anyway, I put my module on mig5's Features community server, here:
http://community.featureservers.org/project/answers

You can too. There are several community servers about and, if you're feeling really adventurous, you can host your own community server. By the way, that's where "URL of update XML" comes in. Remember I didn't know what to do with it? It's simply the URL of the community server your module is hosted by, so the core Update Status module knows where to look for update information.

24 comments

by steve on Fri, 26/03/2010 - 13:21

Nice write-up. I've played a bit with Features but I'm still a little scared of it. Like what if your Feature needs a module that does not provide exportables? Is that where strongarm comes in? I admit I haven't done enough research on this topic. But, for example, a wiki Feature may contain CCK and Views, but would also contain Markdown and Freelinking and Diff and their various settings. I guess I could just set those in mymodule_install()?

Oh and thanks for that Answers feature!

by greg.harvey on Fri, 26/03/2010 - 13:43

Thanks - re: other modules, if Features doesn't pick them up automatically, you can manually add them with the Dependencies option when creating a Features-based module. I guess you'd want to encapsulate the Input Filter settings as well though? That may require you rolling up your sleeves and doing some hook_install() magic right now, but I don't know. Perhaps Strongarm would help? I haven't checked it out yet.

by Jonathan Pugh on Fri, 02/04/2010 - 20:36

Strongarm is used with features to export any variable in the system. Strongarm is required if you want to save Node Type settings, like comments and attachments, so it's pretty much essential to use it for any feature you are building.

Luckily, it adds a list of all variables with simple checkboxes just like everything else, so its easy to scroll through and select the variables you want to save with your feature.

On another note...
the created feature.module file is free to edit at will, add any other hooks you want in there. Features will preserve whatever is there when you re-create the feature. You are also free to add a feature.install file to the package.

by Dan on Fri, 18/02/2011 - 15:12

thanks for the explanation of what strong arm does, Makes more sense now. Does strongarm work the other way as well. i.e can you import your strongarm settings on lets say your staging environment or does this work automatically if features is enabled?

by agentrickard on Fri, 26/03/2010 - 16:17

The only thing I really miss is the ability to bundle user roles and their related permissions settings with my Features module. (Or at least, I think I miss it? Maybe you can already do this and I've missed the option.)

The Secure Permissions module does this part, but not with Features integration.

by Damien McKenna on Fri, 26/03/2010 - 17:25

StrongArm only handles the variables table so it won't help with permissions, other dependencies, etc. And the content type integration in Features is still not complete.. hopefully after I finish this patch for CCK there'll be a better solution for handling them, then some cleanup work on Features to make it a more straight-forward module builder and it could be golden ;-)

by mikeytown2 on Fri, 26/03/2010 - 18:32

I've tried to use it but I've given up for now due to this bug:

unable to extract tarball with tar
http://drupal.org/node/522794

by greg.harvey on Fri, 26/03/2010 - 19:06

No such issue with Fedora. It works fine.

by Kyle Mathews on Mon, 29/03/2010 - 20:22

Ubuntu doesn't have a problem as well.

by SeanJA on Thu, 07/10/2010 - 06:48

That issue has been fixed

by Kyle Mathews on Fri, 26/03/2010 - 18:35

Nice writeup Greg -- nice to see you go from asking questions on Twitter to building/sharing features :)

On permissions -- you can export permissions w/ their associated roles. It's one of the drop-down options in features. I'd suggest not doing that however on something you share publically as the roles on your site + permissions might not match up with whoever else will be using it.

by greg.harvey on Mon, 29/03/2010 - 18:11

That's good to know - at least you can pre-configure "authenticated" and "anonymous". It would be nice to be able to bundle roles too.

agenttrickard's Secure Permissions suggestion looks good for that though:
http://drupal.org/project/secure_permissions

by dkinzer on Thu, 11/11/2010 - 19:04

It does look like roles are exported. When you check off the list of permissions you need exported, Features looks for the roles that have said permissions and exports them as,well.

Below is an example of a permissions setting array where you see that the 'administrator' role is included in the export.

<?php
 
// Exported permission: delete any paleghist content
 
$permissions[] = array(
   
'name' => 'delete any paleghist content',
   
'roles' => array(
     
'0' => 'administrator',
    ),
  );
?>

by Adrian on Fri, 26/03/2010 - 22:50

To install a feature on a site, should those modules where feature is depending on, download and install modules manually ?

by greg.harvey on Mon, 29/03/2010 - 16:50

You need to go and install all dependencies for *any* Drupal module (it's not a Features thing, it's a Drupal core thing) before you will be able to enable the module requiring them. The enable check-box will be greyed out until all the dependencies are satisfied (downloaded to a valid modules directory).

I find it good practice to always enable the modules which are dependencies PRIOR TO enabling the module with dependencies, as the install order is arbitrary and installation may fail in an ugly way if any of the dependencies were required by the installation scripts and weren't yet available.

by Jonathan Pugh on Fri, 02/04/2010 - 20:31

You only need to download the required modules. As long as they are available on the server, Drupal will detect that they are not enabled and do so for you, whether using admin/build/modules or "drush enable".

And since features, for the most part, only uses CCK, Views, panels, and their addons, you don't have to worry much about letting it install them in any order.

by greg.harvey on Sat, 03/04/2010 - 19:41

While that may be true of Features-based modules, as a general rule it's not strictly true. You should enable dependencies first (even though that's not necessary according to the docs). Potential issue described in more detail here:
http://drupal.org/node/365098

by Sina Salek on Sat, 27/03/2010 - 06:41

I had the same problem with features, and it seems that i was totally wrong!! Thanks for sharing you experience :). Gonna share some features ;)

by Chris on Thu, 10/06/2010 - 08:27

what is the difference between drush make and features ?

by Tom on Wed, 06/10/2010 - 07:04

Always liked Features but I've been waiting for it to support Taxonomy. Now that's in development, I'm excited about it!

by Kla harr on Thu, 07/10/2010 - 08:01

Thanks for the post, I had no idea about this, can't wait to try it out.

by Anonymous on Mon, 20/12/2010 - 21:13

Now try re-importing it.

You'll see that

1) The content type you exported with Features is not available
2) It says "overridden"
3) Noone knows why it's "overridden"
4) The names "content type" and "feature" is so prevalent in English that a search on Google to try and see why it doesn't work is pointless, signal-to-noise ratio-wise.
5) All you get is fanboy gushing saying "and you can export a Content Type as a Feature! I'd document it, but I haven't even tried it yet and don't realise it doesn't work."

by greg.harvey on Tue, 04/01/2011 - 22:04

You're a pretty angry guy... ;-)

I'm not a "fanboy" at all. In fact, I have had a whole set of issues with Features, all recorded, some here and some just on Drupal.org. I'm now pretty careful about where and how I use it, but it *is* still useful.

And I've never had any problems with reverting/over-ridden content types.

But it is buggy, sure.

by Amitav roy on Tue, 26/04/2011 - 11:29

Yes, I am using the features module for basic use of enabling the features of certain content types with their views ready with all the settings. I feel when you are working on drupal and making websites day in and day out on drupal, then there are a few things you would like to get done easily on sites. Features helps you with this. We have things like blog, forum, community wall etc which are all features based

If one site require it, put the module, enable it and you are ready and client is happy :P

Post new comment

© 2010 Greg Harvey. Drupal theme by Kiwi Themes.