2

We are developing a single Drupal 8 site with a set of different features (content types, etc). The CMI approach is great for sharing config through git and importing/exporting on local, dev, stage, and prod environments.

But... I also really like the organizational aspects of the Features module. It is appealing to have config grouped in meaningful buckets rather than a single global sync folder. Individual modules also provide a nice place to hang default content and hook_update_N functions.

I've read that these two can play nicely together, but I'm having trouble determining the practical logistics of it all. When I develop a feature, I usually do a drush cex and commit the changes -- so with Features, do I also export a feature and commit that? Now the config lives in two places -- should I be concerned? Will it cause conflicts?

Am I just complicating things by trying to use both? If forced to choose, I will use only CMI because I want to be sure to control all config (not just the bits I've grouped into Features) -- and we want consistent and predictable deployments between local, dev, stage, and prod.

2
  • 2
    IMO Features isn't really useful for one site. It is useful for extracting and packaging functionality to use on multiple sites. Using both at the same time is probably counter productive.
    – Kevin
    Commented Mar 3, 2017 at 14:20
  • Thanks, Kevin. I've come around to your way of thinking -- especially after discovering that if you try to enable a Features-based module through the UI, and the configuration already exists, it will create an error. I was under the impression that Features got around this problem, but it seems that's only the case if you use drush to enable the Features-based modules (which I don't understand, but is confirmed in another answer on this site).
    – Chris M
    Commented Mar 7, 2017 at 15:21

1 Answer 1

2

In my opinion Features isn't really useful for just one site. It is useful for extracting and packaging functionality to use on multiple sites. Using both at the same time is probably counter productive and prone to errors, as they both try to enforce features via configuration and manage them as well.

If you had a site and wanted to copy/clone the article functionality or product catalog functionality from it to another (different) site, then, yes. You would need Features to do this, because core CMI does not work when you want to take pieces and import to a totally different site.

On the other end of the spectrum, you could ignore the core config management and use Features to do this for your entire site, but it is more for you to manage, and as stated, if you are not extracting it out for use in other sites, it is just busy work.

1
  • Thanks, Kevin. My experience since posting the question aligns well with your answer.
    – Chris M
    Commented Mar 8, 2017 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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