2

I have worked on a few Drupal projects that used features. I am usually perplexed by the way the way functionality is grouped. I'm guessing that most of them were created as needed and by different developers that did not want to meddle with other people's features. The outcome is usually a mess of different naming and grouping schemes. Currently, I have the opportunity to create a site from scratch, and I want to start using a good methodology for creating my feature groups. I am tending towards making a gigantic feature that contains everything, and only rebuilding one feature every time an update is needed. What is good/bad about doing this. Also, I feel more responsible while considering building several different features for each bit of functionality. However, I am not sure how granular to go, or if this is begging for conflicts later. How should I be approaching this issue?

marked as duplicate by Anil Sagar, Mołot, kiamlaluno Apr 14 '14 at 12:23

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2

It's all up to you. There are pros and cons to both and it depends on your use case.

Generally one would tend toward decoupled functionality with granular features instead of a giant feature. Especially if you wanted to potentially use these features on other sites.

Some information to help you out.

One big feature Pros:

  1. It's quick and easy. If you're just using features to track database changes in code and don't care about re usability, you can just stick everything in one big feature.

One big feature Cons:

  1. If you make one big feature, you can't re use it at all on another site unless that site is almost exactly the same.

Decoupled features Pros:

  1. You can re use features on other sites.
  2. Your features are much more manageable, even it if it takes a bit longer.
  3. You can keep custom code which is directly related to the feature in the features module, so you're keeping the feature + custom code in one nice package.
  4. This model fits in well with programming in general, taking big problems, breaking them down, abstracting them, using dependencies, etc. It will definitely improve your programming practising separating your code logically like this.
  5. Helps the way you think about Drupal components and how they mess together.

Decoupled features Cons:

  1. Overhead of organizing features structure. This will get easier as
    time goes on and you get better.
  2. Can be very hard to decide where to decouple, especially for newbies.
-1

How should I be approaching this issue?

  1. Take a holiday
  2. Come back when Drupal 8 is released
  3. Use that.

;)

On a more serious note, I'd spend some more time learning core Drupal APIs and do as much as you can from an install profile using drush make and the smallest amount of contrib modules as you possibly can.

Not the answer you're looking for? Browse other questions tagged or ask your own question.