Deprecate \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames() - use #config_target instead

What if we made it non-abstract and returned an array by default in ConfigFormBaseTrait?

Blocker is in.

Ohai, @Feuerwagen, welcome to the merry land of all things config validation — looking forward to seeing you around more hopefully! 😊

@catch: that sounds reasonable to me!

Hi @Wim Leers, just doing some drive-by housekeeping while following the latest and greatest updates in core.

In awe of what you wizards are doing – I hope I can contribute something useful in the future. 😅

No real wizardry going on, just chipping away at things one step at a time 😄 Let me know what kinds of things you'd be interested in exploring, and I'll find you something that matches that 😊

Quoting myself from #3384782-7: [PP-1] Follow-up for #3364506: add deprecation once all simple config forms in core implement → :

#5 didn't explain how we could implement this deprecation in the >=10.2.x world.

Thanks to 📌 Do not require the config in #config_target to be listed in getEditableConfigNames() Active , I see how we can now do that:

I propose that we make ConfigFormBase detect:

1. when getEditableConfigNames() returns anything other than the empty array
2. a deprecation is triggered in Drupal 11

Tricky thing here: for example \Drupal\search\SearchPageListBuilder uses not the base class, but the trait … and the trait does NOT have the #config_target functionality 🤔

AFAICT we'll need to deprecate in Drupal 11 only \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames, not \Drupal\Core\Form\ConfigFormBaseTrait::getEditableConfigNames?

Tricky edge case: already (thanks to #3398891), a number of subclasses do not implement that method at all, and instead use RedundantEditableConfigNamesTrait;. That trait will become obsolete too!

Finally: is this issue now effectively a duplicate of 📌 PP-1: Deprecate \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames() - use #config_target instead Postponed ? Or vice versa?

Which issue do we keep? AFAICT the scopes are so tightly intertwined that it's easier to do together?

The other issue is older; let's keep that.

@Wim you linked to this issue, so not sure what the duplicate could be?

@smustgrave the other issue is: 📌 [PP-2] Follow-up for #3364506: add deprecation once all simple config forms in core implement Postponed .

Closed in favor of 📌 [PP-2] Follow-up for #3364506: add deprecation once all simple config forms in core implement Postponed