`LocaleConfigManager::updateConfigTranslations()` saves language config overrides
even when the computed translation data is identical to the existing override. This
causes unnecessary cache tag invalidations on every `drush locale:update` run.
On a site with German translations, running `drush locale:update` with no actual
translation changes re-saves all 177 config overrides, invalidating their cache tags.
When a CDN purge module is active, this floods the purge queue
and triggers rate limiting.
The bug is in `updateConfigTranslations()` at line 600 — the `elseif (!empty($data))`
branch calls `saveTranslationOverride()` without first checking if `$data` matches the
existing override.
The issue has been identified on Drupal version 11.3.3
1. Install Drupal with the `locale` module and at least one non-English language with
imported translations
2. Run `drush locale:update` — observe config overrides being saved
3. Run `drush locale:update` again — the same overrides are re-saved even though
nothing changed
Add a comparison in `updateConfigTranslations()` to skip the save when the computed
data is identical to the existing override:
elseif (!empty($data) && $override->get() !== $data) {
The $override object is already loaded on line 586, so this adds no extra queries.
none
None
None
None
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 3577001-1-locale-unchanged-config-override-resave.patch | 4.06 KB | petar_basic |
| #3 | 3577001-locale-unchanged-config-override-resave.patch | 1.98 KB | petar_basic |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
petar_basic commentedAdded a comparison to skip saving config overrides when the data hasn't changed, plus a kernel test. The fix is a one-line change in updateConfigTranslations() — we check
$override->get() !== $databefore callingsaveTranslationOverride().Also, attaching a patch for use with composer patches.
Comment #4
petar_basic commentedfailing gitlab jobs are really unrelated
Comment #5
quietone commentedHi, Issues for Drupal core should be targeted to the 'main' branch, our primary development branch. Changes are made on the main branch first, and are then back ported as needed according to the Core change policies. The version the problem was discovered on should be stated in the issue summary Problem/Motivation section. Thanks.
Comment #6
petar_basic commentedI've rebased the MR and it's target is now main.
I've also added the version the problem was discovered on in the Problem/Motivation section of the issue summary.
Comment #7
alexpottThis fix looks really sensible - nice work @petar_basic. I think we should also mirror this logic for the active langcode translations too.
Comment #8
petar_basic commentedThanks @alexpott!
I agree, and I've applied the proposed change.
Also added a test to cover that path as well.
Re-rolled patch with all changes.
Comment #9
smustgrave commentedRan the test-only and both tests fail which is good to see https://git.drupalcode.org/issue/drupal-3577001/-/jobs/8790039
Tested with breakpoints and with the MR I didn't hit the reimport. Already appeared to get a support from @alexpott and feedback which has been addressed.
Comment #10
alexpottCommitted and pushed 2ed9cb80fae to main and be71083b676 to 11.x and 18c354876df to 11.3.x. Thanks!