Contrib.social

Refactor form to use getEditableConfigNames() and $this->config() instead of injecting config

Open on Drupal.org →
Created on 5 September 2025, about 13 hours ago

Problem/Motivation

Follow-up from #3491004-18: Can't save image widget crop settings (ImmutableConfigException) →

I'm going to merge this to get people unblocked, even though the bug itself is due to a preexisting, incorrect pattern -- you are never supposed to inject a config object into a form (or any class) as a dependency.

The correct pattern would be for the form to override the getEditableConfigNames() method, and use $this->config() internally to load config. Core will guarantee that it gets editable versions of anything listed in getEditableConfigNames().

Merging this on the good-faith assumption that some kindly person will open a follow-up issue in which to do that cleanup. — phenaproxima

The current fix was merged to unblock users, but it relies on a pre-existing incorrect pattern: a configuration object is being injected into a form (or related class) as a constructor dependency. In Drupal’s configuration system, forms must declare editable configuration via getEditableConfigNames() and access it using $this->config(), letting core guarantee editable config is provided. Continuing to inject config:

  • Bypasses core’s guarantees around editable config objects.
  • Makes testing and overrides less predictable.
  • Encourages a pattern that contradicts established core practices.

Proposed resolution

  • Remove direct injection of configuration objects from the form’s constructor and properties.
  • Use $this->config()
📌 Task
Status

Active

Version

3.0

Component

User interface

Created by

🇨🇦Canada joelpittet Vancouver

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024