1

I have worked on or seen different D7 projects in the past, with different strategies for features:

  1. One feature per view, content type, etc, with a consistent naming pattern. The result is many features with small or medium size. This has been my personal preference in the past.

    Examples:

    • mysite_ft_vw_articles, for an "articles" view.
    • mysite_ft_ct_event, for an "event" content type.
    • mysite_ft_tx_categories, for a "categories" taxonomy vocabulary.
  2. Multiple elements grouped into the same feature, e.g. if they are related to a specific section of the site, a specific topic etc.

I am now in a new project where we have to pick the strategy we want to follow, and some team members prefer to have bigger features with more elements in them.

To me the only problem I can imagine with having too many features would be performance. Some operations in Drupal may get slower if more modules are enabled.

The main problem with less but bigger features would be git merge conflicts, and side effects of "drush fu" on unrelated functionality.

Question

Am I missing something?

How big could the performance or memory impact be for e.g. 300 enabled feature modules?

What other downsides would it have?

Is there a recommended way / best practice?

Related

When using features to manage deployment, should I break my functionality into many little features or one big feature?

This question is asking whether to have multiple features or one big feature. But the accepted answer still suggests to group a lot of things into one (e.g. all content types, all views, etc).

I am asking whether to have multiple features, or even more features.

Note: the sites where I did this so far had fewer content types and views, so if there was a performance impact it would have been smaller. Also I have not compared few or many features on the same project to see which is faster. This is a new employer, new team, new project, I want to do things the way I used to on other projects, but want to evaluate the pros and cons and have a good argument, before I force this on a team that used to work differently in the past.

  • Could the downvoters please explain what is wrong with the question? – donquixote Nov 20 '18 at 13:41
  • 3
    Didn't -1 but that's quite a broad and/or opion-based question. I mean, did you experience any reproducible downsides with that approach? As you are doing it that way right now. Then that would be your answer. I tend to do it like you. Multiple smaller and encapsuled features. Downside maybe could be dependency hell. But haven't had much problems with this so far. I also always capture the feature modules to add other (custom) related code in the *.module and *.install files. But that's just how I do it. Maybe others do it different. – leymannx Nov 20 '18 at 14:12
  • 1
    Dozens of features or more definitely impact certain areas of performance. For example you’ll want to disable “rebuild features on cache clear” as that can be a heavy operation. The larger a feature is, the harder it could be to manage too. It’s all a balance. – Kevin Nov 20 '18 at 14:42
  • "did you experience any reproducible downsides with that approach? As you are doing it that way right now. " - the sites where I did this so far had fewer content types and views, so if there was a performance impact it would have been smaller. Also I have not compared few or many features on the same project to see which is faster. This is a new employer, new team, new project, I want to do things the way I used to on other projects, but want to evaluate the pros and cons and have a good argument, before I force this on a team that used to work differently in the past. – donquixote Nov 20 '18 at 15:10
  • 2
    I wouldn't worry too much about too many (or not) feature, but rather on how to best prevent conflicts. For way more details on that, refr to my answer at drupal.stackexchange.com/a/199860/39516 – Pierre.Vriens Nov 20 '18 at 15:44
2

I'll jump in with an answer, though I agree with others that there is probably no single correct way.

My experience with features is that large features become very difficult to manage. Even one-feature-to-rule-all isn't a great answer, though it obviously reduces the conflicts possible, though that helps, because of the management of all those individual elements becomes hard.

In the past I have attempted to keep one "feature-module" for each aspect-feature of the site - so for example one feature describing a content type, and the views using it, and the rules, etc. Sometimes this is essentially one page, sometimes more. I have also tried larger groupings - bad idea - but not so far smaller ones (one for the actual CT, another for the view, etc.

The aspect of 'too many modules' is real, though I have dealt with perfectly functional sites with >200 (non-features) modules active. A mitigation you could use is for the live system to run with the features modules disabled, because their effect should be in the database and so the code is not needed. I haven't tried this, though.

From this experience I think that the choice should be to keep the scope of each feature small and very, very well defined. Most of the time I have got into trouble it has resulted from some aspect of a feature that is on the border between several elements -- it should probably have been its own thing not lumped into other things.

So: smaller features with very well defined scope for each.

  • Thanks! So it seems people generally believe that more smaller = better, but are somehow afraid to go all the way :) – donquixote Nov 20 '18 at 16:17
  • yes, probably because the more things are split the more complex it appears to be. – rivimey Nov 20 '18 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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