Fixed
Project:
Drupal core
Version:
11.4.x-dev
Component:
field system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
11 Sep 2026 at 08:46 UTC
Updated:
17 Oct 2026 at 17:21 UTC
Jump to comment: Most recent
In the #2907780: Add a field purger service commits contain errors.
The config name and its key were misnamed in the commit.
This code in SystemHooks::cron()
// Do a pass of purging on deleted entity field data, if any exists.
if (!$config_purge_batch_size = \Drupal::config('field.field_settings')->get('purge_batch_size')) {
$config_purge_batch_size = Settings::get('field_purge_batch_size', 50);
}
\Drupal::service(FieldPurger::class)->purgeBatch($config_purge_batch_size);
doesn't read a customized config value anymore, because of the incorrect config name - field.field_settings instead of field.settings. The same situation in ConfigImporterFieldPurger::initializeSandbox().
The config key purge_batch_size is incorrectly referenced as field_purge_batch_size in the return string of field_post_update_clear_purge_batch_size().
Fix names of the config and its key.
Start 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:
Comments
Comment #3
hoxton commentedtried looking for other places were this issue could have been present, found non.
have raised PR for current issue.
Comment #4
hoxton commentedComment #6
leandro713 commentedI may be missing something, but I noticed two points while reviewing MR !17090.
The change from field.field_settings to field.settings looks correct. However, the MR also changes the fallback in ConfigImporterFieldPurger::initializeSandbox() from:
Settings::get('field_purge_batch_size', 50)
to:
Settings::get('purge_batch_size', 50)
As I understand it, purge_batch_size is the key inside the field.settings configuration object, while field_purge_batch_size is the corresponding key in settings.php. The existing post-update function and SystemHooks::cron() also use Settings::get('field_purge_batch_size', 50).
The issue summary also mentions correcting the returned message in field_post_update_clear_purge_batch_size(), from field.settings:field_purge_batch_size to field.settings:purge_batch_size, but field.post_update.php does not appear to be changed in the current MR.
Am I reading this correctly?
Comment #7
pingwin4egRight. The setting is a new one (if I understand correctly from the original issue), so don't change it.
The issue summary lists all places with errors. Don't look further.
ATM I can't say whether anything else should be done regarding the fact that the wrong config landed in a stable release.
Comment #8
hoxton commentedthanks @leandro713 for pointing out the needed corrections. Have corrected them likewise.
Comment #9
leandro713 commentedThanks @hoxton. I reviewed the updated diff and the three affected locations now look consistent. The changes address the points I raised, and the pipeline is green.
Comment #11
ironnuts commentedThis being a bug test coverage is required. Perhaps it can be added to core/modules/field/tests/src/Kernel/BulkDeleteTest::testPurgeField.
Comment #12
ironnuts commentedComment #13
ironnuts commentedIf this is simply a case of wrong naming then possibly no test required. But there is the question why existing test coverage is not detecting the bug. Ok, will set to RTBTC. If anyone thinks test is needed they can flip back to Needs work.
Comment #14
ironnuts commentedComment #15
ironnuts commentedComment #17
longwaveDebated whether to backport to 11.4.x as it applies there, but it touches a translatable string. However the wording (and code) is incorrect so I think we should fix it there as well. We also have
entity_update_batch_sizealready so I wonder why we need a different setting for this, it feels like this should only need one value really. But that's for another issue to argue!Committed and pushed to main, 12.0.x, 11.x, 11.5.x and 11.4.x. Thanks!