Writing change for some configuration into datastore file that holds multiple configurations wipes out unchanged configurations

Now I have better understanding about how this module works I will try to fix this important issue.

I tried to figure out what was happening here. But I couldn't find an easy way to fix this.

However, in my opinion, is a lot easier to have different files for different configurations. In fact, this makes a lot of sense, it's more visible to track using VCS, and users can see really quickly what configurations are being exported just taking a look to the files saved in /config.

This patch makes the content types and images use they own files to storage they configurations. Also includes tests for overridden node types.

I made some tests and the configuration for each component is complete rewritten into the file, so, if you change only one content type, all the exported content type will be saved again.

#2: 1538502.diferent_files.2.patch queued for re-testing.

#2: 1538502.diferent_files.2.patch queued for re-testing.

Re-rolled

RTBC Thanks @dagmar!

Thanks @BTMash I think that's what we need to move this issue forward. I wonder how all these changes would work with the rest of the api like configuration_download_diff() and configuration_write_exports(), etc. In theory it should be ok, right?

Could we split this into two issues? To properly test CTools integration we should write a custom test module.

I think that, since configuration.ctools.inc is part of the configuration module (that is, we provide integration with ctools in configuration) the integration tests for ctools belong in the configuration module (it's just like the support for image styles).

Yes, but I mean, CTools will not be tested by the bot unless you add Ctools as a dependency of configuration management module.

@dagmar you can add it as a dependency for a configuration test module... take a look how features implements that.

Original patch re-rolled and tested... @btsmash issue still pending... i'm on it that will take a while.

Committed the partial patch from #17.
We still need to deal with #10 so setting to needs work.

Thanks to this patch we don't need this exception anymore for the tests:
In ConfigurationTrackingTest::testTracking

 $types = array(
      'field',
      'filter',
      'image',
      'node',
      'user_permission',
      'user_role',
      'taxonomy',
    );
    foreach ($types as $type) {
      $this->assertRaw(t('Tracking configurations for %type have been saved', array('%type' => $type)));
      if (!in_array($type, array('node', 'image'))) {
        $this->assertRaw(t('Wrote %type to filesystem', array('%type' => 'configuration.' . $type . '.inc')));
      }
    }

changed to:

       $types = array(
      'field',
      'filter',
      'image',
      'node',
      'user_permission',
      'user_role',
      'taxonomy',
    );
    foreach ($types as $type) {
      $this->assertRaw(t('Tracking configurations for %type have been saved', array('%type' => $type)));
      $this->assertRaw(t('Wrote %type to filesystem', array('%type' => 'configuration.' . $type . '.inc')));
    }

it failed because I had already committed the patch so it's not applicable....
(here's the test result for the commit: http://qa.drupal.org/pifr/test/219688).

Leaving as needs work so we add support for ctools for this issue.

This patch provides support for ctools to avoid the issue on http://drupal.org/node/1538502#comment-6270296
It includes a test for views for checking the correct behavior. From this issue i'm noticed that a bigger re-factory is needed so this patch only fix the issue and I'm creating another post for tracking the re-factory.

+++ b/configuration.moduleundefined
@@ -1095,36 +1095,39 @@ function configuration_hook_info() {
-  $status = $config[$component][$identifier]['status'];
+  (int) $status = $config[$component][$identifier]['status'];

Why?

+++ b/configuration.moduleundefined
@@ -1095,36 +1095,39 @@ function configuration_hook_info() {
-  $status |= ($from_activestore) ? CONFIGURATION_ACTIVESTORE_OVERRIDDEN : CONFIGURATION_DATASTORE_OVERRIDDEN;
+  $status |= ( $from_activestore) ? CONFIGURATION_ACTIVESTORE_OVERRIDDEN : CONFIGURATION_DATASTORE_OVERRIDDEN;

The original line is the correct one.

The rest looks good.

+++ b/configuration.moduleundefined
@@ -1095,36 +1095,39 @@ function configuration_hook_info() {
-  $status = $config[$component][$identifier]['status'];
+  (int) $status = $config[$component][$identifier]['status'];

It was added it in the debugging process, I was getting strange values for $status... and since $config[$component][$identifier]['status'] comes as string and we are doing bit operations. Anyway this will be re-factored in a next patch now that is working.

+++ b/configuration.moduleundefined
@@ -1095,36 +1095,39 @@ function configuration_hook_info() {
-  $status |= ($from_activestore) ? CONFIGURATION_ACTIVESTORE_OVERRIDDEN : CONFIGURATION_DATASTORE_OVERRIDDEN;
+  $status |= ( $from_activestore) ? CONFIGURATION_ACTIVESTORE_OVERRIDDEN : CONFIGURATION_DATASTORE_OVERRIDDEN;

Sorry about this.. i can't remember how many times i changed this line to make this work :P

Tested with Views and Display Suite. It seems to be working fine.

committed, thanks guys. I think we can close this issue and start a fresh new one for any changes :)