We’re going to showcase all the modules, tools and techniques we’ve used to create Dropfort in a regular series of posts titled “Forging Dropfort”. This week we’re looking at a module which really sparked the idea of what eventually became Dropfort; Feature server.

Originally released by Development Seed, Feature Server for Drupal 6 allowed any Drupal site to distribute and share their “Feature” modules with other Drupal sites using the same mechanism as Drupal.org did with contributed modules (i.e. the update XML feed). We started using Feature Server for Drupal 6 back in 2010 for just about every client we had. We had written some custom script for our Subversion server which took our commits, packaged them into tgz files and then with a little help from the Services module we sent that release to Feature Server to add to the update XML feed.

On your Drupal site, when you go to the available updates page, the list of updates available for your modules comes from https://updates.drupal.org. That site sends back information about each project in a specific XML format which includes the information about available releases, supported versions, security updates, everything you see on the available updates page. Feature Server lets you have a feed exactly like the one from https://updates.drupal.org but for your own custom modules (i.e. those which don’t belong on Drupal.org). This means you can have your sites download and update your custom modules exactly as you would with those from Drupal.org. And thanks to our port of Feature Server to Drupal 7 Dropfort can let you do just that (n.b. we’re working on getting our copy of Feature Server onto Drupal.org as the official Drupal 7 version, for now it lives on GitHub).

Our implementation of Feature Server had a specific build pattern in mind; use Features. We wanted to build Feature Server using as much from Drupal contrib as we could. With that in mind, we broke Feature Server into three parts:

1. Project and Release Entities using Entity API
2. Basic Feature Server UI using Panels
3. Update XML feed using Services

We switched from using Nodes in the Drupal 6 version of fserver to writing actual Entities specific to projects and releases. The Project entities have three bundles (Module, Theme and Distribution) each of which have specific fields and settings for their given needs. Release entities currently have only the one bundle (also named Release) but this allows us to create new release types as necessary. By using tailored entities for the core objects, we were able to avoid the extra overhead of the node system, avoid having to manipulate the node object into the right project release format, and we could store all the required information for projects as entity properties (which are much faster to load than fields).

To create the project pages and release pages (like those you see on Drupal.org) we created two node types; Project Page and Release Page. These nodes reference the project and release entities and thus are only responsible for the presentation of additional information to the user (i.e. project description, documentation URL, demo URL, etc.). The basic UI which comes with fserver uses Panels to layout pages and some Views to show information. The built-in UI for fserver isn’t very verbose and we’ve actually left that module off within Dropfort. Which is partly why we broke the UI portion into it’s own module within fserver. It allows you to create your own UI on top of the project and release data. But the project page UI you see on Dropfort uses the same nodes and entities defined in Feature Server.

Lastly is the XML feed provided by fserver_services. We added a custom XML output formatter for “.x” paths in Services (since requests for updates come in as https://app.dropfort.com/fserver/release-history/mymodule/7.x) and added a custom object class which builds out a release object which can be converted to the proper release format automatically. Using Services to handle the rendering of the release object also means we can have a json feed of updates, a yaml feed, serialized PHP . XML is just the default since that’s what Drupal uses but you could have other tools consume the update XML for other reasons in other format. That’s the main reason we used Services to handle the update feed. Services takes care of the output format, allows us to add access control, and the configuration is all exportable meaning we can override and/or extend as necessary. We really like the Services module.

One part which is unique to Dropfort is the authentication layer added to the Feature Server update XML. By default, for both Drupal.org and Feature Server, the release XML is available to any user (i.e. anonymous access). However, with Dropfort, you can only access the XML feed as an authorized site and/or user. For more details on how the authentication works, have a look at the Dropfort Update module on Drupal.org. It’s responsible for ensuring in all cases you can access your modules from Dropfort using the update XML and authenticate as necessary.

Suffice to say Feature Server is a key component to Dropfort. We really encourage you to go and look at the code within Feature Server and try it out for yourselves. We’re always looking for ways to improve the module so both Dropfort and the Drupal community can benefit from distributing modules to your Drupal sites the best way possible.