Definition

Feature: a Drupal module that provides a collection of Drupal entities which taken together satisfy a certain use case. 
example:a gallery feature provides a gallery view, a photo content type, and several blocks allowing a user to add new photos and browse those submitted by others.

Component: an individual object or configured setting provided by a feature. 
example: a “gallery” view, the “comment_gallery” variable.

Design Strategy

In general, Kalamuna features should be built around discrete sets of functionality. Content Types, Fields, Views, Fields, Panels Pages, and other components related to a set of functionality will all in the same feature.

Think it through. Make a plan. In writing.

Be specific, but avoid too many features! Planning things out broadly will help keep the dev team on the same page,  minimize the amount of spec per issue, and promote a bigger picture strategy to the build overall.

example strategy docs:  SYN features planning, USFI distro upgrade

Directory Structure

Put the actual Features modules in sites/all/modules/contrib/features and the features you create in sites/all/modules/features.

Your sites directory should look something like this:

sites/all/themes
sites/all/libraries
sites/all/modules/contrib/features
sites/all/modules/features/foo_util
sites/all/modules/custom/foo_personality
sites/all/modules/patched/

Namespacing

All Kalamuna client projects should have a short (3-5 character max) namespace identifier.

This namespace will prepend features, fields, views, views displays, panes, content types, and other machine names. This namespace identifier should also be the name of the project subtheme (if applicable).

Examples:

This allows us to recognize immediately what configuration we've built for a project.

Features that apply more generally across project spaces should be prepended with either kala_ or hot_

Semantic Naming

Whenever possible, after the namespace a semantic, functionality-related name should be included.

Go from General to specific. Example:

YES	NO
field_kala_name_last	field_kala_first_name
field_kala_name_last	field_kala_last_name

Fields have a 32 character limit, so try and be brief with all parts of the name – thumb is better than thumbnail, ref is better than reference.

greenbiz_topic_reference_collection_img_link is too long,

but gbz_topic_ref_coll_img_link fits.

UTIL

Most sites require a utility feature in which to capture site settings and configurations, misc variables from contrib modules and such.

Smaller sites will see more miscellaneous configurations live here, whereas bigger sites with more complexity would see more dedicated features for workflows, search, seo, and more.

Features Workflows

• New Development is exported into code with Features
• Any changed stuff in LIVE, should be conditionally exported to Features
• When deploying, review and revert features

• Increment version numbers

• always diff your re-rolled feature in git

• reference issue # in the commit message

• default config only if users will update settings

• DON’T roll features off LIVE, except…

 NEVER start or finish a sprint with overridden features on LIVE

Updating Features

every feature update should increment the version number:

i.e. 7.x-1.0-alpha1 → 7.x-1.0-alpha2

Drush

Drush is powerful, and an important part of a good features workflow.

drush fu feature_name
Update the feature settings, and update the code locally
You can update multiple features, separate their names by a space

drush fra
Revert all overridden features

drush fr feature_name
Revert specific feature
You can revert multiple specific features, separate their names by a space

references

• https://www.drupal.org/node/960926
• http://drushcommands.com/drush-7x/features/

Features Override

• override and extend panopoly features cleanly

• features_override is now much better, so we prefer that.

• Open Atrium already overrides Panopoly… so this is how do you override an override!
  
  

resources

• https://kalamuna.atlassian.net/wiki/display/KALA/Panopoly+Override
• https://github.com/kalamuna/panopoly_override
  
  

Features are Modules!

Once a feature is generated, it will contain .module file. You can put any code in here you would otherwise put in a custom module.

Things you might want to add to your feature:

hook_update_n

running update.php to trigger some operations and ease deployments, like:

• update field settings see this wiki article for more

• disable modules

display related things

• ctools layouts
• display suite templates
• fieldable panel pane templates
• css or scss

…decouple functionality from the theme layer as much as possible. Ideally, you should be able to turn the theme off, and the site still function.

Other stuff

• facetapi plugins

• README files

Useful Features contrib modules

• Features - the matriarch

• Strongarm - puts variables into the feature

• Default config - settings that can be changed in the DB later

• Features Tools - push features back into code

• Features Override - extend existing features with

• Panopoly Override – kalamuna’s in-code distro overrides

• Features Extra – export blocks, nodequeues

• Features UUID - export nodes, taxonomy, fieldsfeatures_orphans - lists all Features-Exportable components that have not been exported to a feature

• Role Export - allows roles to have machine_names and generates a unique role id (rid) based off of the machine_name