Problem/Motivation

Follow-up to #2625258: LocaleConfigManager::updateConfigTranslations() deletes translations if a config object's name happens to match that of a shipped configuration object which adds a hash to configuration files. We need to provide a upgrade path for existing sites.

Proposed resolution

Discussed with @catch and @Gábor Hojtsy. We agreed that the upgrade path should:

  • check all active config and if name does not match - do not add hash
  • If name matches but has custom config translations - do NOT add hash
  • Otherwise add hash.

This way we don't get data loss and most sites will get localisations for default config.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

Existing configuration entities created through the installer have a default_config_hash key set.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott created an issue. See original summary.

MustangGB’s picture

Status: Postponed » Active
tstoeckler’s picture

check all active config and if name does not match - do not add hash

Can't we actually hash the config in ExtensionInstallStorage and the config in "ActiveStorage" and only add the hash if the hashes match?

alexpott’s picture

Well means any change to non-translated things will stop you getting the new translations

tstoeckler’s picture

Ahh right. Hmm... but that means that people who have deleted e.g. the frontpage view and have recreated one with the same name, still get the data loss problem, right? Hard tradeoff to make, not necessarily disagreeing with the issue summary, just wanted to pinpoint this.

alexpott’s picture

@tstoeckler yep it is tricky - I'm not sure what the best approach is tbh

alexpott’s picture

The biggest problem is knowing what to hash. We can't hash the active config because it might have changed. And hashing the default config provided by modules / profiles is tricky because whilst I don't think we've changed any default configuration files since 8.0.0 sites might be older than that. And they might change in the future. Also what about contrib? Default config has certainly changed there.

I'm not sure there is any reliable way of working this out. So the question is what would be the impact of doing something like this...

  1. If an active config name matches something provided by a module, profile or theme that is installed THEN
  2. If the config has no custom translations THEN
  3. Write a hash value to the config file BUT don't actually create a hash - use a value like 'pre-8.0.2 default config'

This way we'll know we can't use this information to work out which version of the extension's default config was installed BUT if the config has a translatable value that still matches the default value as determined by locale/config_translation then automatic translation will work because the system will consider it shipped config.

xjm’s picture

Priority: Critical » Major

@alexpott and I discussed this issue more. We have left this issue critical up to now for two reasons:

  1. We deliberately chose to skip our requirement for an update hook for the original critical issue #2625258: LocaleConfigManager::updateConfigTranslations() deletes translations if a config object's name happens to match that of a shipped configuration object, in order to stop the data loss problem as soon as possible.
  2. For those strings affected on sites installed before #2625258: LocaleConfigManager::updateConfigTranslations() deletes translations if a config object's name happens to match that of a shipped configuration object was fixed, the site owner currently has no recourse other than to manually translate those strings in perpetuity.

However, the workaround of manually translating this comparatively small subset of strings is available, and the issue does not meet any of the criteria for a critical issue on its own. Therefore, dowgrading to major.

Per @alexpott, we might also be able to make progress by separating this issue into two parts and handling the simple config case first.

alexpott’s picture

Status: Active » Needs review
FileSize
7.12 KB

Here's a starter - it's not yet working out if the translations are custom config translations. I think we need to look up locale tables to find out if the translation is a default translation or a custom one. Some guidance here would be helpful.

Kristen Pol’s picture

Thanks for the patch. I know you are still working on this and need to sort out the default vs custom logic but I scanned the code for other things which could be addressed when the patch is updated next.

  1. +++ b/core/modules/system/src/Tests/Update/ConfigHashUpdatePathTest.php
    @@ -0,0 +1,41 @@
    +      __DIR__ . '/../../../tests/fixtures/update/drupal-8.bare.standard.php.gz',
    

    Is this the best way to reference this file?

  2. +++ b/core/modules/system/src/Tests/Update/ConfigHashUpdatePathTest.php
    @@ -0,0 +1,41 @@
    +   * Tests that default configuration was updateed with default config hash.
    

    Typo: updateed => updated

  3. +++ b/core/modules/system/src/Tests/Update/ConfigHashUpdatePathTest.php
    @@ -0,0 +1,41 @@
    +    $this->assertIdentical(ConfigManagerInterface::UNKNOWN_DEFAULT_CONFIG_HASH, $this->config('system.site')->get('_core.default_config_hash'));
    +    $this->assertEqual('TestValue', $this->config('system.mail')->get('_core.default_config_hash'));
    +    $this->assertIdentical(NULL, $this->config('core.date_format.fallback')->get('_core.default_config_hash'), 'Default configuration entities have no hash.');
    

    It would be nice to have some comments for this logic similar to what's in the other test.

  4. +++ b/core/modules/system/src/Tests/Update/ConfigHashWithLanguageUpdatePathTest.php
    @@ -0,0 +1,43 @@
    +      __DIR__ . '/../../../tests/fixtures/update/drupal-8.filled.standard.php.gz',
    

    Is this the best way to reference this file?

  5. +++ b/core/modules/system/system.install
    @@ -1842,3 +1845,74 @@ function system_update_8014() {
    + * Update configuration is it is provided by a module or theme.
    

    Unclear wording.

  6. +++ b/core/modules/system/system.install
    @@ -1842,3 +1845,74 @@ function system_update_8014() {
    +
    

    Nitpick: Extra line.

  7. +++ b/core/modules/system/system.install
    @@ -1842,3 +1845,74 @@ function system_update_8014() {
    +    // Config with the hash already can safely be ignored. Configuration which
    

    Nitpick: Configuration => config (or vice versa) for consistency.

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

Kristen Pol’s picture

Version: 8.9.x-dev » 9.1.x-dev
Issue tags: +Needs reroll

Patch no longer applies and needs a reroll.

Kristen Pol’s picture

Status: Needs review » Needs work
Issue tags: -sprint
Kristen Pol’s picture

Issue tags: +Bug Smash Initiative
Hardik_Patel_12’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
7.18 KB

Re-rolled against 9.1.x. Kindly review a patch.

Status: Needs review » Needs work

The last submitted patch, 22: 2628004-22.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Hardik_Patel_12’s picture

FileSize
7.36 KB
1.26 KB

Solving failed test cases , kindly review.

Hardik_Patel_12’s picture

Status: Needs work » Needs review

Forgot to change status , moving to needs review.

Kristen Pol’s picture

Status: Needs review » Needs work
Issue tags: +DCCO2020

Thanks for the update. I have reviewed for formatting and general issues but not for overall logic and found a few things.

  1. +++ b/core/lib/Drupal/Core/Config/ConfigManagerInterface.php
    @@ -7,6 +7,11 @@
    +   * @todo
    

    Needs comment.

  2. +++ b/core/modules/system/src/Tests/Update/ConfigHashUpdatePathTest.php
    @@ -0,0 +1,41 @@
    +/**
    + * @file
    + * Contains \Drupal\system\Tests\Update\ConfigHashUpdatePathTest.
    

    Needs description.

  3. +++ b/core/modules/system/src/Tests/Update/ConfigHashUpdatePathTest.php
    @@ -0,0 +1,41 @@
    +namespace Drupal\system\Tests\Update;
    +use Drupal\Core\Config\ConfigManagerInterface;
    

    Nitpick: Add empty line between namespace and use lines.

  4. +++ b/core/modules/system/src/Tests/Update/ConfigHashUpdatePathTest.php
    @@ -0,0 +1,41 @@
    +      __DIR__ . '/../../../tests/fixtures/update/drupal-8.bare.standard.php.gz',
    

    Needs to be updated to drupal-8.8.0.bare.standard.php.gz.

  5. +++ b/core/modules/system/src/Tests/Update/ConfigHashWithLanguageUpdatePathTest.php
    @@ -0,0 +1,43 @@
    +/**
    + * @file
    + * Contains \Drupal\system\Tests\Update\ConfigHashWithLanguageUpdatePathTest.
    + */
    

    Needs description.

  6. +++ b/core/modules/system/src/Tests/Update/ConfigHashWithLanguageUpdatePathTest.php
    @@ -0,0 +1,43 @@
    +namespace Drupal\system\Tests\Update;
    +use Drupal\Core\Config\ConfigManagerInterface;
    

    Nitpick: Add empty line between namespace and use lines.

  7. +++ b/core/modules/system/src/Tests/Update/ConfigHashWithLanguageUpdatePathTest.php
    @@ -0,0 +1,43 @@
    +      __DIR__ . '/../../../tests/fixtures/update/drupal-8.filled.standard.php.gz',
    

    Needs to be updated to drupal-8.8.0.filled.standard.php.gz.

  8. +++ b/core/modules/system/src/Tests/Update/ConfigHashWithLanguageUpdatePathTest.php
    @@ -0,0 +1,43 @@
    +    // The system.mail has no translations therefore it should have the fake
    +    // hash.
    

    Nitpick: Change to get to one line, e.g.

    The system.mail has no translations so it should use the fake hash.

  9. +++ b/core/modules/system/system.install
    @@ -9,6 +9,9 @@
     use Drupal\Component\Utility\Crypt;
     use Drupal\Component\Utility\Environment;
    +use Drupal\Core\Config\ExtensionInstallStorage;
    +use Drupal\Core\Config\ConfigManagerInterface;
    +use Drupal\language\ConfigurableLanguageManagerInterface;
     use Drupal\Component\Utility\OpCodeCache;
    

    Nitpick: Not alphabetical.

  10. +++ b/core/modules/system/system.install
    @@ -1458,3 +1461,77 @@ function system_update_8901() {
    +
    +
    +
    +/**
    + * @addtogroup updates-9.1.0
    

    Nitpick: Extra empty lines.

  11. +++ b/core/modules/system/system.install
    @@ -1458,3 +1461,77 @@ function system_update_8901() {
    +/**
    + * @addtogroup updates-9.1.0
    + * @{
    + */
    

    Needs description.

  12. +++ b/core/modules/system/system.install
    @@ -1458,3 +1461,77 @@ function system_update_8901() {
    +  $optional_storage = new ExtensionInstallStorage($config_storage, ExtensionInstallStorage::CONFIG_OPTIONAL_DIRECTORY, ExtensionInstallStorage::DEFAULT_COLLECTION, TRUE, $install_profile);
    +
    +
    +  if (empty($sandbox['configs'])) {
    

    Nitpick: Extra empty line.

  13. +++ b/core/modules/system/system.install
    @@ -1458,3 +1461,77 @@ function system_update_8901() {
    +      // @todo configuration entities.
    

    Update to be a sentence.

  14. See #10 for more items.
snehalgaikwad’s picture

Assigned: Unassigned » snehalgaikwad
snehalgaikwad’s picture

Assigned: snehalgaikwad » Unassigned
Status: Needs work » Needs review
FileSize
7.44 KB
5.14 KB

Status: Needs review » Needs work

The last submitted patch, 28: 2628004-28.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Kristen Pol’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests

Tests are passing now and tests were added to the patch.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
144 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.