Do not require the config in #config_target to be listed in getEditableConfigNames()

So we need to decide if we should implement getEditableConfigNames ins ConfigFormBase...

I think we could and then somewhere we could check if there's no map and getEditableConfigNames() returns an empty array we could throw an exception.

WOW! 🤩 That looks splendid!

I think we could and then somewhere we could check if there's no map and getEditableConfigNames() returns an empty array we could throw an exception.

+1

And that also opens the door to eventually deprecating and removign getEditableConfigNames() I think? 🤔

re #5 - Yep eventually could do that. There will be some fun because \Drupal\Core\Form\ConfigFormBaseTrait() is used elsewhere but maybe that can continue and we'll just remove it from ConfigFormBase.

Change makes sense to me, with the empty array return at least.

Tests are all green so nothing noticeably broke.

Opened 📌 PP-1: Deprecate \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames() - use #config_target instead Postponed to work out how to deprecate getConfigNames() in the ConfigFormBase context.

I thought about implementing ConfigFormBase::getEditableNames() and returning an empty array here and then adding another after build method to check whether there is a map and if there is no map and the return value of ConfigFormBase::getEditableNames() is empty trigger a warning or something. The problem with this is that if you do that you will no longer be told to implement ::getEditableNames() - so I think we should only do this when we're ready to do 📌 PP-1: Deprecate \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames() - use #config_target instead Postponed and completely deprecate it.

I realised that the exception being thrown by ::copyFormValuesToConfig() is pointless now that we're calling the method based on what is in the map. So we can remove some dead code.

More deleted code is more better, I'm super interested to see how we pick up 📌 PP-1: Deprecate \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames() - use #config_target instead Postponed in the future, but this is already a big win for altering exisiting config forms.

VERY nice! 🤩

This makes ConfigFormBase more capable, with a better DX, with less code! 👏

This is very nice and I never thought we'd be able to remove those custom submits in form alters of config forms or might even make them harder.

Suggested a trait for the empty array implementation of getEditableConfigNames() not because there's any code re-use, but because it'll save copying the same comment around dozens of times and be easier to remove when the time comes.

Committed/pushed to 11.x and cherry-picked to 10.2.x, thanks!

Updated the CR https://www.drupal.org/node/3373502 → with this.

Alright, we're almost done here!

For the final piece to make #config_target a delight to use and usable in also the more refined ConfigFormBase forms … see 📌 ConfigFormBase + validation constraints: support composite form elements Needs review 😁

That is ready for final review too now! 🥳

Automatically closed - issue fixed for 2 weeks with no activity.