Pushing Public and Private Updates From Your Feature Server
A First Look at Downloading, Installing, and Updating Features from a Feature Server
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.
Wow
This is some seriously cool stuff! Looking forward to checking it out!
feature server = repository?
Is it just me our is the following scenario close to reality? Sudo apt-get drupal-pathauto drupal-atrium
Required : token Suggested : admin
While the sources.list contains Https://features.developmentseed.org Https://features.drupal.org
Looking forward to playing with it.
Another fantastic addition
And I thought Features and Spaces was innovative enough, now Feature Server will further change the way developers work. Really impressive.
Awesome
This looks like it’d be really awesome in combination with plugin_manager (does that integrate?) and Aegir.
Clean, cool, and sweet.
I’m not a coder anymore; but I try to keep my hands dirty enough to recognize goodness. This looks good.
And if Moshe says it is, it must be so. ;-)
great work, again
great work, again
suggestions
1. The version field in features export should have some info about the standard Drupal format. Although the update status accepts any filename, but for example the import function in the l10n_server would not work with different version format.
Then the 3 version fields: api_version, version_major and version_patch could be read from the tarball filename when creating the release node, no need to set those manually.
2. The release format seems to be incorrect (or just confusing) on the release node. Should be 6.x-1.0 instead of 6.x-1-0
3. There should not be more than one “recommended release” for the same Drupal version, and as I know update status only supports recommended flag on the major version, so I do not know how do you construct the XML if 1.0 release is recommended and 1.1 is not. (example: http://updates.drupal.org/release-history/views/6.x)
And there should be also a flag for “supported release” to have all the options from update status. UI suggestion
4. The Major version and Patch level could be larger than 9, but as I see the selection is restricted to [0-9].
Thanks for the review Balint!
Thanks for the review Balint! I’ll look into incorporating your suggestions.
transcendent
awesome.
now we enter the era of feature servers popping up around the web, & feature development enters into the grand ole’ maturity model that module & theme development has been (and is going) thru…
feature day zero. huzzah!
brings a whole new light to “feature creep”! ha
/matt
WOW. You guys should have
WOW.
You guys should have run for president.
How difficult was the UX stuff built into the feature server? The configure/edit hovers, etc….
Thanks, and aaah…..thanks!
Terry
Hi Terry, The admin UI
Hi Terry,
The admin UI components are actually provided by the admin module for D6 (http://drupal.org/project/admin) and some of its components are working their way through the D7 issue queue.
As for the other parts of the theme (the general wrapper, etc.) we are indeed planning on including them with the install profile.
humm…..is there an emoticon
humm…..is there an emoticon for crying tears of joy?
OVERLOAD!
This screencast has me overloaded. This looks incredibly useful. Also, did you guys code up the admin theme eye candy for your own projects, or will this be a core part of the feature server?
Like its 19999
“get the party started”. You said it!. The best innovations are so simple yet so genius.
I’m sure you guys are working on drush commands for features so they can install/update from a feature server. and also create a features project from within drush would be neato (not at all critical tho).
Nice work! I’m really
Nice work!
I’m really impressed each time with you guys.
Jérémy