These are my notes from Andrew Root's talk at DrupalCamp LA. Thanks to Andrew for the great talk.
Both Context and Features were developed by Devseed for Open Atrium. They are often used with Spaces or PURL.
What Is Context?
It's a simpler module to understand. Context helps you plan your site. If you try to plan a site and section off the pages and find which are views and which are content, it can be painful. Context allows you to organize your site on a section level. One section can contain content and views, and can be referenced as one context.
This is beneficial because it makes your sites easy to think about. Instead of forty pages and views, you have eight to ten contexts. This can help you segment your work as well, and organize your work on a context-by-context basis.
Context also controls blocks for you. Many people say that Contexts is worth it just for this capability. You can set a whole range of triggers: If you're on a particular view or content type, then trigger a particular context. Managing your blocks on the context level makes it a lot easier than going through the block configuration screen.
Finally, Context provides themeing variables. You can configure theme variables that change based on the context. It makes it really helpful for visually seperating the sections.
Let's bring up an example Context through the UI. You can ignore namespaces for now; just name your context. Next, set your conditions. For example, you can say that when viewing node pages, your context will be triggered. Below, you can control block visibility by context.
When to Use Contexts
One question a lot of people have is, "What warrants a context?" I usually say, if it's a section of two or three related pages, it probably warrants a context. I specifically like to have a context for the front page.
Also, you can stack contexts, so you can apply two or more contexts to a particular page. This allows you to add blocks to some particular pages within a context.
When it was designed, Features was intended to create reusable components. What it really does is to export features from the database into code. It makes it really easy to pass things around and get them from one site to another.
Features exports database objects such as views to "pseudo-modules." These are real modules, but they are sometimes referred to as pseudo-modules because they are generated automatically. These modules can be checked into a repository and versioned, and they're easy to move from site to site. If necessary, these objects can be overridden in the database on any site where they reside.
Using Features with Context
Features works really well with Context. In fact, you can export your context as a feature, which makes it really easy to manage your context and all the views associated with it.
Features as Modules
Features leaves your .module files intact, so you can put stuff in your modules to enhance your features. If you've created any modules that define nodes, you know there are a lot of hooks you need to define. Using features, you can define a content type and put it in your feature, and then you still have the module to implement any of your custom hooks. I commonly put in hook_menu(), hook_block(), and views hooks.
When you're first checking out Features, you won't have any features to manage, you'll want to create a new feature. Enter the name and description of your feature, and definitely put a version number; you'll be going through dozens of revisions, and you want to make sure that when you push it from one server to another, the version number is appropriate.
The URL of update XML allows your features to check in with your server to see when they need to be updated. If you're developing something for another site, they can use the update module to check and see if there is a new version of your feature out there for download.
Now, go ahead and add something like a content type, for example. As you add more, the right column will fill up with things in your Drupal site that are associated with your feature.
Look into extensions to modules that can move components into the Features list. That will take us from a pretty good staging strategy, to something where everything you need is moved through Features. However right now, you can implement a hook_update() that runs a drupal_execute() on forms that are not supported. So for example your module can change the homepage URL by running drupal_execute() on the site information form. Just be aware that you'll have to run update.php after importing your feature, since that's what will call the hook_update() function in your module.
When you download your new feature, the .module file will have only one line, including the other files that are generated by Features.
Read up on the kit spec to learn about how to keep features from colliding using namespacing best practices.
Q & A
Q: If you have blocks in the database and export the context, it doesn't export the blocks?
A: Correct. I implement all my blocks in hook_block() so they can be versioned. I don't let my clients use the block administration interface. Even contexts is a little much.
Q: When you build a context, do you find your users think about your sites easier? At the beginning, it can be confusing even thinking about the difference of blocks and nodes.
A: Absolutely. It makes it easier for my clients to tell me where something is. If they're trying to talk about a section with three or four pages, they can get confused. I find that they're much more comfortable with a few objects, than a whole bunch of views and pages.