Exporting content type override base field

We were stung by this issue as well. My colleague, wwhurley, uncovered the most likely cause:

Drupal\configuration\Config\ContentTypeConfiguration::saveToActiveStore() is implemented as follows:

  /**
   * Implements Drupal\configuration\Config\Configuration::saveToActiveStore().
   */
  public function saveToActiveStore(ConfigIteratorSettings &$settings) {
    $info = (object)$this->getData();
    $info->base = 'node_content';
    $info->module = 'node';
    $info->custom = 1;
    $info->modified = 1;
    $info->locked = 0;
    node_type_save($info);

    $settings->addInfo('imported', $this->getUniqueId());
  }

Which assumes that the 'base' value is node_content and that the 'module' is node. These values can vary, like in bnobleman's example of course_booking, or in the example that had us tripped up, the Poll content type provided by Core's Poll module. Specifically, when Poll attempts to attach extra fields (the poll question itself), which depends on these values in node_type table. My experience with the Configuration module is limited, but here are my thoughts.

What seems to be happening is that during an "Import DataStore to ActiveStore" process, the normal default values are overridden. Any previously exported value (from Active to Data, which likely would have been correct) is overwritten, but once you import from the DataStore to the Active, the values are no longer used and any subsequent exports overwrite the correct ones in the DataStore.

The ContentTypeConfiguration class' constructor sets the key values (The main properties stored in configuration) for the component. These keys are missing the 'module' value mentioned above. So 'module' might need be added as one of the keys although I'm not certain that adding 'module' to the key definitions in the constructor actually matters. Since 'module' is one of the properties returned by node_type_get_type() in the handler's prepareBuild() method, it should be checked before overwriting it in saveToActiveStore().

Attached is a patch doing what I describe, but again, I am unfamiliar with this module, so there may very well be something more complex here that I am not considering.

Applying the patch by bburg resolved the issue.

Works for me... commit?