Look bigger with Features

Andrea Pescetti
18 Jan 2012
7 Comments
Andrea Pescetti
18 Jan 2012
7 Comments
Andrea Pescetti, 18 Jan 2012 - 7 Comments

Look bigger with Features

Everybody uses Features, but using them properly makes a big difference

Nuvole built some respectably sized projects in 2011: a few large international projects (including a heavily customized Open Atrium installation for Higher Education experts and a portal for collaboration between Europe and Latin America on educational matters) and a bunch of ordinary websites, besides our other activities such as trainings and general consultancy. And people occasionally ask us how big Nuvole is.

Well, the truth is that Nuvole is a two-people company, helped by minor contributions by external consultants. Yet, it manages to run and maintain sizeable Drupal projects by using Features -the easy part- and by doing it properly - the hard part, and the main focus of our DrupalCon Denver Training.

So the key is not how many people work on a project, but how efficient their workflow is. Adopting a Features-based workflow provides a solid basis, but you still need to take a lot of design decisions: some will be easier, some will require a bit of thinking, some will prove correct or wrong only months later, when the project needs infrastructural updates.

Nuvole pioneered a Features-based development, and what in general we call the "Code-Driven Development workflow", a couple of years ago. Our Features-based projects look much different now: we found out that our old structure was not optimal, or that technology allowed for cleaner workflows (Drupal 7 brought some substantial improvements, for example). We structured our new projects to take the new knowledge into account, found new challenges and gradually solved them.

Here are a couple of examples of the design decisions you will be happy to have taken properly (we will cover them in detail in future blog posts).

Hard and soft configuration. A site, especially when built as a distribution, should ship with complete pre-configuration. And this pre-configuration should be in code, we don't want to carry a database around. But should all of it go into Features? No, because some pre-configuration (the soft one) is meant to be overridden in the normal site customization, while Features should only contain the hard one, i.e., configuration that defines the site structure. The soft configuration (like the default site title, or default colors) is best handled by putting the corresponding code in the installation profile rather than in Features.

Feature separation. When all your site configuration is in Features, you quickly realize that it is not feasible to put everything into one Feature: you will need multiple Features to build a website, and this means you will have to take decisions on how to split your site functionality across Features. A common mistake is to build transversal Features, like a "permissions" Feature with all site permissions: this works, but it introduces annoying interdependencies and maintenance difficulties in the long run. The problem is best solved by basing Features on content types, thus making them truly modular: in general, a Feature should contain a content type and everything that is related to it, such as views, contexts, image styles and permissions.

The Nuvole DrupalCon training, Code-driven Development: Use Features Effectively, will be held on March 19th, the day before DrupalCon Denver. The training is open to both DrupalCon attendees and externals, and must be booked from the DrupalCon registration page.

Comments

Comments

Anonymous
29 Feb 2012

Nice, thank's a lot

Nice, thank's a lot

Anonymous, 29 Feb 2012

Nice, thank's a lot

Anonymous, 29 Feb 2012
Jason Trancoso
7 Mar 2012

I would like to learn more about the Hard and soft configuration, i will be reading your post about it! Jason

I would like to learn more about the Hard and soft configuration, i will be reading your post about it! Jason

Jason Trancoso, 7 Mar 2012

I would like to learn more about the Hard and soft configuration, i will be reading your post about it! Jason

Jason Trancoso, 7 Mar 2012
Capi Etheriel
22 Mar 2012

Indeed, this is an issue. How does CDD deals with cross-content-type features? Examples: group node is set (through context) to display a views listing of group-related events; blog-type views listing by author has a context block with a views listing of documentation content by the same author.

Indeed, this is an issue. How does CDD deals with cross-content-type features? Examples: group node is set (through context) to display a views listing of group-related events; blog-type views listing by author has a context block with a views listing of documentation content by the same author.

Capi Etheriel, 22 Mar 2012

Indeed, this is an issue. How does CDD deals with cross-content-type features? Examples: group node is set (through context) to display a views listing of group-related events; blog-type views listing by author has a context block with a views listing of documentation content by the same author.

Capi Etheriel, 22 Mar 2012
Andrea Pescetti
3 Apr 2012

In these cases focus on functionality. If two content types are so strongly related that they are part of the same functionality, put them both in the same feature; otherwise, see which one of the two features (say A) is more likely to be reused, and put the overlapping part in the other one (say B), so that B depends on A but A can be reused independently.

In these cases focus on functionality. If two content types are so strongly related that they are part of the same functionality, put them both in the same feature; otherwise, see which one of the two features (say A) is more likely to be reused, and put the overlapping part in the other one (say B), so that B depends on A but A can be reused independently.

Andrea Pescetti, 3 Apr 2012

In these cases focus on functionality. If two content types are so strongly related that they are part of the same functionality, put them both in the same feature; otherwise, see which one of the two features (say A) is more likely to be reused, and put the overlapping part in the other one (say B), so that B depends on A but A can be reused independently.

Andrea Pescetti, 3 Apr 2012
Joel Wallis
24 May 2012

That's a really nice workflow!! I was using a "feature (in te own meaning of the ord) based develpment", putting each feature, app or section of the site in one feature, and making deppendencies between related features. By reading this post I could open more and more my mind to see CDD in a more organized way.

Thanks for shaing!!

That's a really nice workflow!! I was using a "feature (in te own meaning of the ord) based develpment", putting each feature, app or section of the site in one feature, and making deppendencies between related features. By reading this post I could open more and more my mind to see CDD in a more organized way.

Thanks for shaing!!

Joel Wallis, 24 May 2012

That's a really nice workflow!! I was using a "feature (in te own meaning of the ord) based develpment", putting each feature, app or section of the site in one feature, and making deppendencies between related features. By reading this post I could open more and more my mind to see CDD in a more organized way.

Thanks for shaing!!

Joel Wallis, 24 May 2012
Anonymous
23 Oct 2012

Any tips for how to organise features when you have a term reference or node reference field?

We would like to use features in our project, but are using Taxonomy Access Control to restrict access to certain sections of the site. We have 6 content types , but all have to have the same term reference field?

Could we split the content types into 6 features and the have an additional module with the shared field as a dependency?

If the content types can reference other content types , related articles / posts etc, how would you tackle that?

Thanks for your consideration and for writing all these great articles. There is so little information out there about these concepts, we are grateful for your contributions.

Any tips for how to organise features when you have a term reference or node reference field?

We would like to use features in our project, but are using Taxonomy Access Control to restrict access to certain sections of the site. We have 6 content types , but all have to have the same term reference field?

Could we split the content types into 6 features and the have an additional module with the shared field as a dependency?

If the content types can reference other content types , related articles / posts etc, how would you tackle that?

Thanks for your consideration and for writing all these great articles. There is so little information out there about these concepts, we are grateful for your contributions.

Anonymous, 23 Oct 2012

Any tips for how to organise features when you have a term reference or node reference field?

We would like to use features in our project, but are using Taxonomy Access Control to restrict access to certain sections of the site. We have 6 content types , but all have to have the same term reference field?

Could we split the content types into 6 features and the have an additional module with the shared field as a dependency?

If the content types can reference other content types , related articles / posts etc, how would you tackle that?

Thanks for your consideration and for writing all these great articles. There is so little information out there about these concepts, we are grateful for your contributions.

Anonymous, 23 Oct 2012
Andrea Pescetti
24 Oct 2012

Divide Features by functionality. This does not necessarily mean that you need a Feature per content type. If your 6 content types are in a way interdependent (meaning that the functionality is incomplete without that field), then it may well make sense to have all of them in one Feature.

Divide Features by functionality. This does not necessarily mean that you need a Feature per content type. If your 6 content types are in a way interdependent (meaning that the functionality is incomplete without that field), then it may well make sense to have all of them in one Feature.

Andrea Pescetti, 24 Oct 2012

Divide Features by functionality. This does not necessarily mean that you need a Feature per content type. If your 6 content types are in a way interdependent (meaning that the functionality is incomplete without that field), then it may well make sense to have all of them in one Feature.

Andrea Pescetti, 24 Oct 2012

Get your project started today!

Contact us