Nuvole

Help shape the future of Open Atrium

Our review of Tracy Smith's Open Atrium book just made it to Slashdot, confirming there is a widespread interest in this popular Drupal distribution. (By the way, the book is not, and is not meant to be, useful to developers, but if you build Open Atrium projects you should definitely recommend it to your clients: it will save a lot of time to you and them).

The most interesting consideration is that the book, published in January 2011, is still perfectly current now, as of Open Atrium 1.3 released just a few weeks ago. And this is not quite good: most distributions have been significantly updated in recent months, while Open Atrium has been quite conservative in features and updates so far.

In case you haven't heard, this is going to change. The future of Open Atrium looks bright, and, while there isn't a roadmap yet, the guys at Phase2 have recently taken steps to make sure that Open Atrium can again be a shiny example of innovation and bleeding-edge, useful, technology:

• The Open Atrium Development Group is now open for everybody to join. Open Atrium is now a true community product with a transparent development process.
• A Feature and Theme Directory is now available to find in a single repository all features and themes created by the Community, such as Nuvole's Atrium Folders.
• An interesting BoF session was held at DrupalCon Denver, where we shared our experience with advanced Open Atrium customizations and we discovered that people are pushing this distribution to many different use cases: there are hundreds of organizations and companies working with Open Atrium now, and each of them can provide valuable feedback in shaping the future version.

The discussion about Open Atrium on Drupal 7 is now open, don't miss it!

New international projects, new office, and hiring!

Nuvole is going to add a couple of international projects and some advanced Open Atrium customization services for non-profit organizations to its portfolio in the coming months. And if you are a skilled Drupal Developer you can be involved too!

Our upcoming projects will require a stronger presence in Brussels, the place to be for every international organization in Europe. So, while still keeping our Italian headquarters and office unchanged, we've just expanded our Belgian office. The new office is located in ICAB, a modern business centre in Brussels close to the Flemish university: a place with a vibrant international student community, equipped with a gym, a swimming pool and pubs.

The new Brussels office was officially inaugurated with a reception last week (pictures below) and it will be the place where we meet with international clients and we develop the EU-funded projects Nuvole participates in, like:

• Alfa Puentes (2011-2013): a three-year project for international cooperation between Latin America and Europe on educational matters.
• Open Sounds: a Leonardo da Vinci project (2012-2013) for transnational cooperation in music production.
• Higher Education Experts (2012-2013): a renewed version of our customized Open Atrium portal for European experts in Higher education.

Want to be involved? We welcome applications: if you are a skilled Drupal 6 and 7 developer, just see our job post and apply!

Features, taxonomy and other beasts

An extract from the new teaching materials we are preparing for our DrupalCon Denver 2012 pre-conference training, Code-Driven Development: Use Features Effectively.

By now the advantages of a clean Code-Driven Development workflow are clear to the majority of Drupal developers; things like separation between configuration and content, packaging and deployment of new site functionalities or sharing changes in a distributed team don't look that scary anymore.

Still not everything in Drupal can be clearly classified into configuration or content, such as Taxonomy terms. Taxonomy terms are mostly used to categorize our content so, naturally, they are often used in site configuration: a context that reacts to a given taxonomy term is a fairly common scenario. Taxonomy terms can be generated by users (think about free-tagging), which makes them fall into the "Content realm". Drupal, in fact, considers them as such, assigning to each term a unique numeric identifier, and that's the problem.

Each component has its own name

One of the turning points in making configuration exportable in code was the introduction of a unique string identifier for each component: this way it's easy to share configuration and to avoid conflicts. So what happens with taxonomy terms? If they appear in our context conditions then we'd better bundle them together: no matter where we are going to deploy our feature, they will always have to have the same values. That's simply not possible: they have numeric IDs, forget about easy life here.

Various attempts have been made to export numerically identified components, such as UUID Features Integration or the handy Default Content module, but they only solve part of the problem: we want other components to know the unique name of our terms.

Hard and Soft configuration

At Nuvole we adopted the following terminology to classify the two kind of settings that we need to deal with everyday:

• Hard configuration includes the settings under the distribution developer's control (e.g., Views or Contexts); it has a machine name, it is easy to export, it gives no headache. We store it in Features.
• Soft configuration includes the settings that are meant to be overridden by the site administrator (e.g., the default theme, or the initial terms of a vocabulary); it often gets a unique numeric ID from Drupal, it is impossible to export safely, it is painful to handle. We store it in the Installation profile.

This distinction becomes fundamental when the configuration is altered or (if you are dealing with a distribution) when the underlying distribution is upgraded. In the case of Hard configuration, altering it results in an overridden feature, which is upgrade-unsafe. In the case of Soft configuration, altering it does not change the Features state, since the corresponding settings are stored in the Installation profile, and changes are upgrade-safe.

Not only taxonomy terms

The distinction between Hard and Soft configuration goes beyond how to conveniently export taxonomy terms: it is more a design decision, especially important when dealing with distributions. We consider everything that the site builder might be entitled to change as Soft configuration. The place where to usually store Soft configuration is your hook_install(); this guarantees a safe upgrade path to the next version of the distribution. An example could be the default theme: you may ship your distribution with a specific theme but the site owner might want to change it and subsequent updates shouldn't alter it.

Here is how our profile hook_install() might look like in a Drupal 7 distribution:

<?php

/**

* Implements hook_install()
*/
function example_install() {
 
   $terms = array();  
 
   $vocabulary = taxonomy_vocabulary_machine_name_load('category');

 
   $terms[] = 'Solution';
 
   $terms[] = 'Client';
 
   $terms[] = 'Use case';

 
   foreach ($terms as $name) {
     $term = new stdClass();
     $term->vid = $vocabulary->vid;
     $term->name = $name;
     taxonomy_term_save($term);
   }
  
  // Enable custom theme
 
  theme_enable(array('example_theme'));
  variable_set('theme_default', 'example_theme');  
}

?> Reference for site builders

If you are customizing a distribution and you need to override some of its default Hard configuration you might want to have a look at the Features Override module and at these two related articles from Phase2 Technology:

• A new paradigm for overriding Drupal Features
• Features and Overrides - Part Deux