[null, {"document_url": "https://developmentseed.org/blog/2009/jun/25/pushing-public-private-updates-your-feature-server/", "unformatted_src": "http://farm4.static.flickr.com/3662/3659392243_616abbe256.jpg", "src": "http://farm4.static.flickr.com/3662/3659392243_616abbe256.jpg", "formatted_filename": "abbe"}, null]
It's common for organizations to run 20+ different program websites. The bulk of these program sites need several of the same features like a public blog, a pressroom, and media resources. A few key programs might need a sensitive CCK-based reporting feature that was designed in house. This screencast by Young, who blogged about the power of decentralized features yesterday, is a first look at how a feature server will let you pull features from multiple sources and get updates for them in both public and potentially secure and private ways. If you're not familiar with the features module, you may want to watch the screencast introducing it before watching this one. The feature server architecture is incredibly simple because it leverages core Drupal components to their fullest. Believe it or not, the feature server is itself a feature (exportables for node types, CCK fields, Views, etc.) with a few small custom components (e.g. a Views style plugin for generating the update module-compliant XML). And because the update module in Drupal core allows for sources to be defined on a per project basis and the update information is transferred through dead simple HTTP requests and XML, the feature server for projects with sensitive information can be protected behind your private firewall. The ability to strengthen your toolset from a decentralized network while making sure some tools are behind your firewall is key for a lot of the international development organizations we are working with on data collection tools and intranets. We will blog again tomorrow about our plans to package up feature servers as install profiles so your shop, organization, or company can set these up and get the party started.
