2

There should be several sites, starting with something like a similar distribution, but over time, each site might get some individual modules. Yet, I'd like to keep the site updated with new versions and new configurations over time as well.

So I can't use the full import/export of configuration management, since this would delete my individual additions on some sites, if I understood it correctly. And I need to be very careful with single exports, since those don't care about dependencies.
Configuration Packager has been merged into Features, so it seems as I need to use features anyway.

So what do I put into a configuration? And what into a feature? And how would I distribute the preconfigured stuff to all sites? Use a feature server like in Drupal 7? (If the Github process is setup and I've got a dev and several production sites, how do I push configuration and feature updates to production?)

Improve this question
6
  • Use configuration files for common config and use state for site-specific configuration.
    – user21641
    Commented Apr 19, 2015 at 7:59
  • A common config would be what? Something like Content Types/Required Modules/Permissions. And state for the site itself for language, theme_settings etc. How would I create and develop something like a news section with all it's views, blocks and the content type? How about a gallery?
    – Chris
    Commented Apr 20, 2015 at 23:38
  • common config would be a configuration entity, ie. a block, a view, a field(storage or instance), a system setting, content type, content type display,...the stuff that is in module's config directory. State on the other hand is site-specific, ie. D7 variables.
    – user21641
    Commented Apr 21, 2015 at 18:47
  • I see, thanks. So for packages and own functionality, I'd still need to use Features? The news-section, the gallery-section? Since configuration can't handle dependencies, right? I reckon it'd be possible to write it by hand - but Features seem to be way more efficient.
    – Chris
    Commented Apr 22, 2015 at 2:42
  • Cofiguration supports dependencies. Features is more like a comparison tool. You cna import a feature(a set of configuration objects) and then you can see if the configuration on the site is the same as the one that was imported with the feature and if not you can recreate the feature to reflect the actual state or you can revert the site's configuration into feature's state. Currently I'm not sure what are the good cases to use Features in D8 but it's too soon so I'm sure some scenarios will pop up with time.
    – user21641
    Commented Apr 23, 2015 at 6:10

1 Answer 1

Reset to default
0

So .. found more details on it.

With drush config-list | grep news I can get all configurations that are named with news. Those can be exported into a Module / YAML file and moved to another installation, or rather copied and enabled.

More information on that: http://nuvole.org/blog/2014/jul/15/packaging-and-reusing-configuration-drupal-8

So that would make Features in D8 quite unnecessary - depending on the use case, very good.

It might be reasonable to use config-merge but I'm not sure about:
If I'd do a Full Export, I'd only be able to use this on Cloned sites (like Staging/Live). But in my case I'd do an initial clone or a profile and would only like to pass on functionality (like features) and that might not work with config-merge?

Improve this answer

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.