Presented by Jeff Miccolis of Development Seed
(missed most of the beginning, talking about features and exportables)
- Ctools is special
- Strongarm gives you access to the variables table -- start to capture values from variables table
- these components are the configuration that descirbes how your site behaves - Strongarm lets you bring out and safeguard those important decisions
- Features should be used throughout the development process - not intended to come up later, meant to be there the entire time.
Creating a Feature
- Create a feature through the Features UI - add in various components
- Once you've built the feature, Features module gives you a way to see the status of the feature; lets you track whether any elements have been changed or overridden from what you set in your feature. Click Overriden, gives you a diff
- Using the Features web UI you can create a new feature, make updates to existing features, or revert the changes made from the prior iteration of the feature
- Drush has many Features commands - features (list all available features), features-export (export a feature from your site into a module), features-update (update a feature module on your site), features-revert (revert a feature module on your site)
Example of Features in development:
- Alex makes a feature
- Jeff pulls it down from version control, adds a couple of views to the features, updates the feature and commits in version control
- Young adds theme overrides
- Alex fixes Jeff's and Young's bugs
- Alex rolls the feature out
- Jeff makes views adjustments - when he clears his cache all of everyone else's changes to the feature reappear on his site
- Rolled out.
- Alex makes views adjustments to fix Jeff's...
- Young makes adjustments
- Roll out again
- Views changes are only made once. No need to manually copy stuff down, make changes on production AND staging, etc. Each change has a commit log within version control because everything is done in code.
- Process helps you avoid dumb errors; provides more accountability (making sure what you do is properly there; less likely for someone else to screw it up later; easy to enforce what's been done and figure out who did it.
- Overhead of staging goes away; go straight from dev to production.
- Not having a distinction between configuration and code is bigger than just this: you're able to maintain something like Open Atrium
Features for exporting Features as modules
- First: sequential IDs on configuration is the enemy. Use a machine name as the primary idea
- Second: when in doubt, use Ctools (http://civicactions.com/blog/2009/jul/24/using_chaos_tools_module_create...)
- Your job: database schema, UI
- Ctools' job: loading and exporting your configuration
- What's left: dependency detection, which is optional but useful
- hook_features_export() - lets you add modules, add components, allows for delegation
Best Practices around building Feature modules
- Kit - the goal is to offer a straightforward base package for building state-of-the-art Drupal sites while specifying how Features built on top of Kit can be compatible
- Kit includes Feature and Theme specifications
- kitf (feature specs): unique namespaces, user roles & permissions, variables, paths & menu items, block visibility & theme regions, dependencies, problematic components
- kitt (theme specs): regions, page template variabls, element attributes
- these are currently working documents based on developer feedback