Problem/Motivation
In the context of
🐛
Resolve config_enforce "looping" behaviour
Closed: outdated
we noticed some odd behaviour importing some complex and interdependent config. It's unclear what mix of configs is causing the problem, but we're seeing failures where the config system reports that a bundle is missing, like so:
[error] The field_part_a entity reference field (entity_type: publication_widgets, bundle: template_publication_part_3) no longer has any valid bundle it can reference. The field is not working correctly anymore and has to be adjusted.
[error] Error: Call to undefined method Drupal\config_enforce\EnforcedConfigRegistry::deleteEnforcedConfigs()
Steps to reproduce
Uncertain, but at a guess, something like: a node type N with an entityreference field that points to an ECK custom entity type Ea. Ea has another entity reference field pointing to a second ECK custom entity type Eb. Eb in turn has another entityreference field pointing to Ec. Each of these has form and view display configs, as well as field storage and field instance configs, that all live in the same custom module's config/install directory.
Proposed resolution
This appears to result from a change in the core implementation of a core method that we re-implement in Config Enforce, in order to introduce some more detailed logging (and because in core it's in a submitForm() method we can't call directly. In testing, we've been able to avoid the crash by updating our implementation to match the one in core as of
#2875279: Update core modules to use the new batch builder →
.
The plan is to update our 1.x branch to only support a maximum version of Drupal 9.2.x, and implement this fix on our 2.x branch, where we set the minimum supported version at 9.3.x
Remaining tasks
- Roll a patch out of our current testing fix, to demonstrate and share the workaround solution
- Update 1.x branch core dependencies to max 9.2.x
- Prepare 2.x branch, and set minimum core dependencies at 9.3.x
- Cut a 2.x alpha release
- Review 2.x roadmap, and move any older issues up
- Start a 3.x roadmap, moving any API-breaking changes into it as needed
User interface changes
None.
API changes
Core update to the ConfigSync core routine that imports updated configs. See https://api.drupal.org/api/drupal/core%21modules%21config%21src%21Form%2...
and https://git.drupalcode.org/project/config_enforce/-/blob/1.0.x/src/Confi...