Problem/Motivation

Modules should not update configuration once it has been installed because they could wipe out a site's customizations. However, when new configuration is added to a module (such as a View), then a quick helper method to read the new config and write it to the system would be quite helpful.

This is the current approach (from #2549675: Upgrade path for 2375589):

  // Only create if the view doesn't exist and views is enabled.
  if (!View::load('block_content') && \Drupal::moduleHandler()->moduleExists('views')) {
    $config_path = drupal_get_path('module', 'block_content') . '/config/optional/views.view.block_content.yml';
    $data = Yaml::parse($config_path);
    \Drupal::configFactory()->getEditable('views.view.block_content')->setData($data)->save(TRUE);
  }
  else {
    drupal_set_message('Not creating views.view.block_content since it already exists.');
  }

Proposed resolution

Add a method to ConfigFactory (or elsewhere?) that takes a path to configuration as the parameter. The method will throw an exception if the config already exists in the system.

Remaining tasks

User interface changes

API changes

New method on ConfigFactoryInterface.

Data model changes

Files: 
CommentFileSizeAuthor
#9 import-config-helper-2550325-09.patch6.29 KBjhedstrom
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 103,215 pass(es), 1 fail(s), and 0 exception(s). View

Comments

jhedstrom created an issue. See original summary.

jhedstrom’s picture

Issue summary: View changes
Status: Active » Needs review
Issue tags: +Needs tests
FileSize
2.02 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 101,569 pass(es). View
jhedstrom’s picture

FileSize
575 bytes
2.04 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 101,575 pass(es). View

Oops.

alexpott’s picture

Issue tags: +Configuration system
jhedstrom’s picture

Assigned: Unassigned » jhedstrom
Status: Needs review » Needs work

Got some feedback in IRC from alexpott and berdir.

jhedstrom’s picture

Status: Needs work » Needs review
FileSize
5.16 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 103,211 pass(es). View

This isn't quite working, but I ran out of time. Posting here for review of general direction. No interdiff since it's a different approach than the first patch.

jhedstrom’s picture

Assigned: jhedstrom » Unassigned
jhedstrom’s picture

I mispoke above--this is working for complex config (eg, views). I think it is failing to import simple config because of this check in ConfigInstaller::installOptionalConfig()

      // Only list configuration that:
      // - does not already exist
      // - is a configuration entity (this also excludes config that has an
      //   implicit dependency on modules that are not yet installed)
      return !in_array($config_name, $existing_config) && $this->configManager->getEntityTypeIdByName($config_name);

I've spent a little time thinking about how to write tests, but am a bit stumped since I don't think it will be easy to create new config during testing for modules that are already installed. Unit testing may be the only way to go, but the current test coverage of ConfigInstaller doesn't have any unit tests that I could find.

jhedstrom’s picture

Issue tags: -Needs tests
FileSize
1.77 KB
6.29 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 103,215 pass(es), 1 fail(s), and 0 exception(s). View

Actually, I realized faking new config is as simple as deleting installed config. This adds tests that illustrate the issue above where simple config_objects are not properly imported.

Status: Needs review » Needs work

The last submitted patch, 9: import-config-helper-2550325-09.patch, failed testing.

jhedstrom’s picture

One potential fix for importing basic config would be to add a parameter to ConfigInstaller::installOptionalConfig() to make the check in #8 that filters out basic config optional. This would be an API change though.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.