I set a couple of fields to be tracked, and got this in my config folder:

- config
-- tracked.inc
-- field.fieldname.etc.inc
-- field.fieldname.etc.inc

The tracked.inc file appears to list the two field components, along with some a hash which I assume is used to check override status, and a list of dependencies.

What happens when I want to track some more fields, or other components? Does the tracked.inc file get updated with more components?

I am concerned that having everything in the same tracked.inc file prevents finer control and granularity. For one thing, it makes it impossible for multiple developers to work on configuration management without getting version control clashes -- whereas with Features what I do is have one feature per section of the site, so developer A can be adding fields to node type A while developer B adds fields to node type B.

Also, is it possible to keep configuration files in other places? For example, I have a module that tweaks a node type, and relies on the presence of certain fields (or other components) to do its work. With Features, I can mark a feature as a dependency of that module. I was hoping that with config I could put a folder of configuration files inside a module folder. Is that possible?

Comments

joachim’s picture

joachim commented
Version: 7.x-2.0-alpha1 » 7.x-2.x-dev
Category: support » feature
Priority: Normal » Major

Having had a look through the code, it does seem that this module is limited to config files being in the one folder, and tracked through the one tracking file.

I'm changing this to a major feature request accordingly, as it does seem to be a major shortcoming -- for myself, one that precludes my adopting this for projects.

Would using drupal_system_listing() be feasible, and then allow tracking folders to be present inside folders, and multiple folders inside the sites/default/files/config?

dragonwize’s picture

dragonwize commented
Status: Active » Closed (won't fix)

joachim, I understand your request, however, what you are not realizing is that this module is not meant to replace the Features module. What you are asking for is the "features" part of Features, which is to group random bits of config together in different bundles.

The Configuration module is only configuration management at the site level just like CMI in D8. It is the intention that when Configuration is ready, that a version of Features could be written on top of Configurations API to give you what you seek, much like how it will be done in D8.

As for the tracked.inc file it is the exported config for the Configuration module. Also since we can not change as much of Drupal as the D8 CMI, the tracking system allows us to get around the issue of what is configuration and what is not, via developer choice.

joachim’s picture

joachim commented

Looking at the config system in D8, it looks like what I'm really after is the way that node module in D8 has a file node.settings.yml, which then auto-imports to config.

dragonwize’s picture

dragonwize commented

Configuration works a similar way as we have files for each type of config but unfortunately writing an entire system that works with core and contrib and have everyone adopt it before D8 is a viable solution is not feasible so we are building off of the same config formats that are already in use in D7 (ctools, features, etc.) so that is usable now.

joachim’s picture

joachim commented

I don't meant the YAML format, but the way that each module gets to have some built-in default configuration, which is then (I presume) overridden by the user-created config.

dragonwize’s picture

dragonwize commented

I refer to both, the file format (yml, php, etc.) as well as the export format (ctools, custom, etc.) when I say format. In fact I speak more of the later when saying creating and adopting a new export format and process would be unfeasible in the time frame.

joachim’s picture

joachim commented

I think we may still be talking at cross-purposes, as I don't think I mean either of those things.

I don't mean the file format, and I don't mean the export format that modules such as CTools define.

What I envisaged is that a module that requires, say, some custom fields for its operation would be able to do this:

- mymodule
-- mymodule.module
-- mymodule.info
-- config
--- tracked.inc
--- field.fieldname.etc.inc
--- field.fieldname.etc.inc

Where the contents of config are the same format as what is used in sites/files/config.

This use case is illustrated by Commerce, which has several modules that require particular fields to exist.

GDrupal’s picture

GDrupal commented

@joachim You can do something very similar to what you need right now. We are using in fact a folder of configurations for our internal profile that it import in the install process and you could do the same with a module using the helper function configuration_import_directory().
You can easily import configuration files when you module is installed, but right now it will be only tracked in the configuration datastore. But in fact i think that using configuration this way it's very similar to a feature, we can use the configuration API to write an OO features module but i think the original intend its to configuration for a more generic (staging configurations) use case. SO if we provide some sort of "features" equivalente functionality i think should be in a different module on top of the configuration API. We can include that module in configuration as well and later break it apart, but for sure our current sponsor does not need that "feature" functionality so we can't prioritize that.

joachim’s picture

joachim commented
Category: feature » support
Priority: Major » Normal
Status: Closed (won't fix) » Active

> but right now it will be only tracked in the configuration datastore

So, let me get my head round this... if a module has a config folder, and in its hook_install() calls configuration_import_directory() on that, the config components defined there get merged into the sites/default/files/tracked configuration? And the components get created if not already present?

That seems like a pretty good starting point to me. I can see that from a developer's perspective there's a missing part of the round trip -- if I export my field to mymodule/configuration and then tweak it in the UI, I can't easily export it again. But that's something I could look into coding as a module on top of this :D

I'm trying to test this out, but there are a few hurdles --

- the filename is expected to be configurations.inc rather than tracked.inc
- the variable name is expected to be $configurations rather than $tracked
- configuration_import_directory() calls ConfigurationManagement::discoverRequiredModules() with the $configurations array, but discoverRequiredModules() seems to be expecting a $modules parameter. But having copied the variable over from my tracked.inc file, I have an array like this:

$configurations = array (
  'field.node.field_config_me_up.article' => '764a105f70c633300bca89f0097bd1eabd7bbd90',
);

which obviously doesn't have module names in it!

This looks like a bug to me, as importToActiveStore() and startTracking() are called with the same variable further on and don't seem to expect the same thing.
EDIT: I see that's been fixed here #1860490: Improve and update configuration_import_directory() helper function matching last API changes..

joachim’s picture

joachim commented

Hmm it does look like the formats are different: when I try to install my test module, with the patch from the other issue, I get these errors:

    Notice: Undefined offset: 1 in Drupal\configuration\Config\ConfigurationManagement::createConfigurationInstance() (line 77 of sites/all/modules/contrib/configuration/lib/Drupal/configuration/Config/ConfigurationManagement.php).
    Exception: There is no configuration handler for: 764a105f70c633300bca89f0097bd1eabd7bbd90 in Drupal\configuration\Config\ConfigurationManagement::createConfigurationInstance() (line 83 of sites/all/modules/contrib/configuration/lib/Drupal/configuration/Config/ConfigurationManagement.php).
joachim’s picture

joachim commented
Status: Active » Fixed

Thanks for your help on IRC just now :)

Very much appreciated -- and I've got it working!

1. use migrate tab to create a tarball
2. put that inside module folder
3. use hook_install() to install the configuration
4. result is:

- fields created
- fields are tracked in the tracking folder
- fields are marked as default

Changing the field results in the tracked component being marked as overridden, and I presume that exporting it changes the tracking folder rather than the module config folder -- which is as expected too.

Perfect! :D

I'll take a look at the docs pages on this and see if I can help with filling in any blanks.

(PS. Any chance of a new alpha release with this fix in it?)

GDrupal’s picture

GDrupal commented

@joachim I glad to hear that configuration will be helpful for you!

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented

We are going to release another alpha really soon.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.