Making and Using Features in Drupal
An Introduction to the Features Module
At our presentation A Paradigm for Reusable Drupal Features at DrupalCon DC, we showed the following slide toward the end of the presentation as a blue sky picture of what we thought the future of Features might be.
Well, that was March and this is May. We may be a little exhausted, but we’re happy to introduce you to the Features module:
The scope of Features
For those who weren’t at our DrupalCon presentation, here is a recap of the basic concepts that have driven our work on Features:
- A feature is a collection of Drupal entities that, taken together, satisfy a certain use-case.
- A feature is a module. This lets each feature get a great deal of Drupal core’s infrastructure out of the box meant for managing, sharing, and updating modules.
- The scope of features is limited by design. The stuff that features is made of is exportables, and it is meant to deal strictly with site building structures.
The last point is particularly important – individual feature modules don’t script site building or use update scripts to maintain themselves. Instead, we take advantage of the powerful exportables concept pioneered by Views to allow all of your feature’s site building to live in code (exported views, contexts, imagecache presets, node types, etc.) but also be overridden and in the database. This allows you to take advantage of version control to collaborate and share your site building work, and to also use standard Drupal site building UIs to take the next steps in improving your features.
Here is an overview of current support in Features for other modules that have exportables:
Module Support Block Yes CCK Yes Context Yes Imagecache Yes Menu Yes Node Yes Views Yes Taxonomy TODO (no exportables) Variables TODO (no exportables) Flag No Rules No Panels 3 No Your module? ???We’re excited by what we have support for now, but even more excited by what the contours of feature building will look like as integration for more modules is added.
Um… so what about “The future of Drupal features?”
If the future of Drupal features (as perceived in March) is moving along nicely, what’s the next big thing for Features?
Features is part of the answer to one of Drupal’s biggest headaches – what to do with all that loose site building and customization that happens on every project. Features is part of the answer to making stronger, better install profiles and targeted distributions of Drupal. And features is part of the answer to making Drupal more task oriented and less daunting to our users.
We’ll be following this post with some of the ideas we and other people in the Drupal community have had. We’re excited. We hope you are too.
A thanks
Features is the product of work from Jeff Miccolis, Ben Root, Dmitri Gaskin, and myself. Ideas from Ian Ward, Alex Barth, and many conversations at DrupalCon DC fueled the development of this project.
You can get Features at http://drupal.org/project/features.
Wow
Developmentseed devs certainly have their thinking caps on 24/7 judging by the amount of clever stuff coming out! I look forward to bundling up some features in the near future!
perfect developer solution
I’ve been building sites in drupal professionally for 4 years, and solving the issues of team development in a db oriented environment has been a holy grail for a long time… both life changing and ELUSIVE.
I was finally building some cool tools for managing content types in a team for a new gig where I’m teaching them all to develop with drupal. I went as far as to submit a patch to content_copy so that it actually updates and deletes fields as well as adding them if they don’t exist…
The effort to push for everything being exportable and having defaults coming from code is key toward the future of drupal and its goal of getting better all the time, especially for developers.
This is more than a tool to easily deploy a set of ‘features’.
Any website built for a business by a business has to customize a lot of stuff. This will allow drupal devs to make changes anywhere they want in the fantastic drupal UIs, and then export and commit those changes into their version control repo for the site.
Other developers then simply need to revert just like they would svn up.
Thank you. I had already started to build export tools for the variables table and enabled modules, and was about to set out to do something like this in a module. I’m thrilled someone has finally pulled all of this together in a manner that works.
I can’t wait to try this out as soon as I get back to work on monday :)
keep up the good work guys, you’ll see me in the issue queues
Jon
THANKYOU!!!
amazing work you guys! I don’t know how you guys ever sleep as it seems like all the things that keep amazing us, making us salivate, and helping us SO much come out of devseed (ex. context, features, aegir, 8trees/atrium etc.).
If I created a feature from
If I created a feature from a site put the exported feature module to another fresh install drupal site, should dependency modules of this feature should be existed ? (either enabled of disabled)
Features and Advanced Help Injection
Like the other people commenting in this thread, I have to agree — amazing work.
We’ll be digging into features shortly as part of our Knight Drupal work, but we’re currently hammering out some details re creating more effective documentation on featuresets — toward that end, I was wondering about how features handles changes of modules? I’m assuming that features can be moved best on sites that have an identical codebase, and that any changes in the module versions between sites have the potential to adversely affect the feature import.
Module exportables API stability
It’s ideal to use exported features with module versions that match the original source site to best reflect how the creator intended their feature to work but it’s by no means necessary.
Features assumes that you’ll be using your exported feature between module versions that are API compatible — for example, the format of Views 2 exportables has remained very consistent between its 2.x point versions. While different modules offer varying degrees of stability in their exportable formats, the ones we’ve included integration for so far have been relatively stable.
Patterns vs. Features
@Tom Geller: Patterns exports stuff to a markup file, and has the scaffolding to export it and import it. Actually, no export today, so you have to manually write XML / YAML files.
Features turns stuff into a module, leveraging core Drupal. And you build it in a Drupal site, so no YAML writing required.
Hopefully some of the Forms API stuff that Patterns does can be merged in here … but from my POV, Features leverages more native Drupal stuff and is more compatible with the direction of core.
Young — FAN-frickin-TASTIC! Where is the right place to be sharing Feature recipes today?
Decentralized Feature Servers
Boris, We’re working on plans of how people can run their own feature servers using the update module infrastructure. We are going to have a working prototype pulling from what we think will be three separate feature servers in the next 6 weeks. We see decentralization as a key strength of the feature server future. A couple of the shops at BootUp might have their own, Lullabot and Phase2 might have their own, Devleopment Seed will have one, probably our intranet package 8trees (soon to be called Atrium) will have one. Then of course organizations that are hosting a lot of sites, like the World Bank, New America, or Warner Brothers would all have their own internal. And sites could pull from all of these.
I am excited by this diversity, seeing this as something that is exactly what Drupal needs during this period of growth.
As for a listing of features, I would think if people like features, then there should be a listing page of recipes on d.o. You should write the recipe feature for your cooking blog and we could reuse it on d.o.
Lovely
That drush features update is hot hot hot. Do all exportables support updateing like this? Can you package up roles and permissions in a feature? Curious why thats not on your list.
Yes — if it has exportables
Yes — if it has exportables we can evaluate the default/overridden status and update as well. The way we do this is a little on the dirty/evil side but sometimes you need to sell your soul for generalizable superpowers : )
As for roles/permissions, we haven’t seen a module that supports exportables for permissions yet (that’s not to say we might not have written one internally…) but it’s definitely something we run into every day. On the code front I’m keeping my eye on http://drupal.org/project/permissions_api as a potential project to roll role/permission exportables into.
There is a related problem to permissions/roles which is that there is a very wide variety of role setups on Drupal sites. If there were a default set of Drupal roles (e.g. admin/manager/user/anonymous) then it might start to make sense to have different features provide default permission settings for those roles.
Brilliant!
Good work, going to give this one a try!
Amazing! Comparison with the Patterns module?
Wow, that’s really wonderful. I can immediately see how this will help consultants as well as developers.
I’m slightly familiar with Patterns (http://www.drupal.org/project/patterns), which is similar in that it automatically configures numerous site features. It seems to lack the tie-in with Contexts (or anything like it), but on the other hand seems to perform more actions.
But I haven’t actually used either. Is my take on it right, or am I missing something? Could you compare the two projects?
Packaging/deployment
We get this question a lot : )There was actually a very good BoF meeting at DrupalCon DC between the developers of the different packaging / deployment projects and you can get a sense of the activity in the space here:
http://groups.drupal.org/packaging-deployment
The main difference between the different packaging/deployment-related modules is their approach to the problem and the scope defined for the respective projects. Here is a rough summary in my eyes:
Project Scope Deployment Directional push of content/configuration between sites Patterns Capture and “replay” configuration/building tasks Features Export/maintain site building in modulesYou’ll notice some overlap between patterns and features currently. I would say that this is because Drupal is slowly moving towards an exportables paradigm for site building, and features limits itself to only modules which have made that shift. Patterns is doing a great job at supporting site building modules that haven’t made that jump yet.
Hopefully in the future the split between site building and site “settings” or “configuration” will be cleaner so that each of the projects can do what they do best.
Great embodiment of the term "leverage"
It seems my team was just having this conversation yesterday: “Is there a way to organize commonly implemented solutions so that we don’t have to reworking from project to project and so that developer brain power can better be shared?” Features = Yes!
It is a great start and will benefit as time goes on from usability improvements, but I’m loving the thought behind it and how it recursively uses the same principles that makes Drupal one of the best CMS platforms. As Drupal is to building websites, Features is to building with Drupal.
This has so much potential
This is not only great for packaging up thinks like CCK fields, Views, and moving this between devel, stage and live servers, but I can also see a new section on Drupal.org with Features “recipes”. Just think things image galleries with slick jQuery effects pre-built as a Feature that you can install like a module.
I wonder if there is a way to merge this with install profiles?
Fantastic work guys.
Looking forward to trying it.