A Paradigm for Reusable Drupal Features

session details: A Paradigm for Reusable Drupal Features

• the theory
  • enable the Blog module, each user gets a URL and RSS feed
  • a blog is a "feature," and so is a pressroom, an image gallery, a publication library, etc.
  • more complex example: a pressroom with fields, blocks, theming, etc.
  • 3 problems: slow process, not reusable, disconnected pieces
  • Context module (currently alpha for D6) lets you assign related elements to a single feature which can be scripted or exported (manually)
    
• the practice
  • set up content type, view,
  • views have "spaces" filters to define possible contexts (thanks to Spaces module)
    
  • go to /admin/build/context and select elements that relate to your feature
  • go to /spaces and enable & customize the feature
  • go to /admin/build/menu and select Spaces for primary links
  • To avoid doing this on every site, make feature into its own module (manually)
    
  • combine Spaces with Organic Groups to allow features to look & act different in different parts of the site
    
• the future
  • why put site building in code? because it's reusable, distributable, and versionable
  • but scripts are a pain to debug, maintain, and extend
  • new model: "exportables" -- similar to how we currently export views to code: normal/default/overridden
  • exportables provide definitions, not scripts; are easy to maintain; and are overridable and extensible.
  • views, panels, context_ui, and imagecache all have exportables
  • cck, taxonomy, filter, menu, triggers don't yet have exportables
  • recipe for exportables:
    • string identifiers good, ID numbers bad
    • create API functions for collecting all items at once
    • create a structured array or object to represent your item
    • use hook_item_export in your module
  • wouldn't it be cool if a module let you export all your site's features into a module?
  • to prepare for this day, add exportables to your modules!