Raw Notes: DrupalCampNYC8: Building Features and Exportables

Posted 07.25.2010 by Jack

Presented by Frank Carey (frankcarey)

In the beginning, Drupal was very code centric
if you wanted to make something you coded a module, relied in hooks API, etc
Content ruled the land (the database), but modules still stored many settings in the database
Content in Drupal - nodes, friends, comments, votes, users, messages
Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you'd normally do with code, but now could do through the UI
Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
Why should this stuff be in code and not the DB?
- How do you track changes within the database?
- How do you revert back when you make a mistake?
- How do you reuse configurations?
- How can you work as a team?
- How can you update settings across sites?
If your settings/config are in code, you can use version control to handle those thing
- take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
How do we get stuff into code?
- Some modules provide their own custom export and import functionality - views migrate rules
- some are leveraging ctools export api (paenls, context, etc)
- some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

Tool attempts to solve the common problem of handling exportables.
- Defining exportables structure
- Getting the data from the DB and creating the xportable object
- importing the data from either db or code
Ctools exportables
- Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
- Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
So what the heck is Features?
- Features is basically an exportables manager
- It creates "features" modules, which are really just normal modules (features is not a hard dependency
- allows for a gui interface to choose what things you want to export per feature
- it provides drush integration to easily update and revert changes from the CLI
What should a feature consist of?
- Look for logical sections and atomic functionality
- Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
- Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal's hooks are available to Features.

In the beginning, Drupal was very code centric
if you wanted to make something you coded a module, relied in hooks API, etc
Content ruled the land (the database), but modules still stored many settings in the database
Content in Drupal - nodes, friends, comments, votes, users, messages
Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you'd normally do with code, but now could do through the UI
Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
Why should this stuff be in code and not the DB?
- How do you track changes within the database?
- How do you revert back when you make a mistake?
- How do you reuse configurations?
- How can you work as a team?
- How can you update settings across sites?
If your settings/config are in code, you can use version control to handle those thing
- take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
How do we get stuff into code?
- Some modules provide their own custom export and import functionality - views migrate rules
- some are leveraging ctools export api (paenls, context, etc)
- some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

Tool attempts to solve the common problem of handling exportables.
- Defining exportables structure
- Getting the data from the DB and creating the xportable object
- importing the data from either db or code
Ctools exportables
- Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
- Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
So what the heck is Features?
- Features is basically an exportables manager
- It creates "features" modules, which are really just normal modules (features is not a hard dependency
- allows for a gui interface to choose what things you want to export per feature
- it provides drush integration to easily update and revert changes from the CLI
What should a feature consist of?
- Look for logical sections and atomic functionality
- Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
- Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal's hooks are available to Features.

Notes from Features Demo

When you look at your list of features with diff module enabled, you can see how a feature has been overridden within the current configuration
Turning on Strongarm allows you to export variables (from the variables table) into a feature

Command-line features

Features exposes many commands to Drush that can then be used from the command line
features revert - revert a feature from the command line; this reverts changes made within the UI to settings that you've configured within a feature

Features/Exportable Gotchas

Some exportables can't be exported more than once (e.g. can't re-export a default view)
Features-revert-all can be dangerous, blow away work
Not everything is exportable yet
Revert-all doesn't work if there's no diff (fixed recently in dev)
Dependencies can be tricky.

Developments to watch out for

Additional Things to See