Unable to save 'access unpublished' setting form - TypeError: Drupal\Core\Render\Element::children(): Argument #1 ($elements) must be of type array, null given

This issue is only happening with Drupal core 10.2 and it is working fine with Drupal 10.0, do we have any patch for this issue?

I am able to replicate the issue.

Let me try to work on this.

DamienMcKenna → changed the visibility of the branch 3421309-unable-to-save to hidden.

The problem is the validation on the modify_http_headers field, if that's removed the form can save correctly.

This patch is a bandaid that lets the settings form save, but it needs a proper fix that uses the correct validation logic.

Thank you @DamienMcKenna for this patch and all that you do! The patch works for me!

The reason of this error is that module settings form uses ListItemBase::validateAllowedValues method as validation callback. But at the last versions of Drupal allowed values form of list fields was totally refactored. See this core commit https://git.drupalcode.org/project/drupal/-/commit/693ced9cd830f9b1d0942...
So to fix thie we need to either refactor module settings form to use the same approach as list fileds or copy the old validation callback to SettingsForm class. Unfortunately I can't do this because on my current froject we don't use headers settings, and in my case patch from #7 solved my problem

I can confirm the patch from #7 resolves the issue, but we will need a long term fix to add the validation correctly. Going to get this issue some attention as this module was a module of the week on Talking Drupal. Thanks All!

jakaeser44@gmail.com → changed the visibility of the branch 3421309-unable-to-save to active.

After applying the patch from #7, I received this error:

Warning: foreach() argument must be of type array|object, string given in Drupal\access_unpublished\Form\SettingsForm->prepareHeadersDisplay() (line 127...

Still not a long-term fix, but here's an updated patch to prevent that from happening.

It didn't take long to realize my previous patch isn't quite going to cut it. Changing the expected value of the field from an array to a string unsurprisingly has some negative side-effects. Here's a patch that copies over the previous form validation from ListItemBase. It should be a good bit more robust and allow you to actually use the modify_http_headers setting.

I don't think this is an ideal long-term fix, either. The best path forward, in my humble opinion, is to match what core did in https://www.drupal.org/project/drupal/issues/2521800 📌 List key|label entry field is textarea, which doesn't give guidance towards the expected input Fixed .

patch #14 does remove the error and allowed me to save the form, but I'm not sure it makes the headers setting work: I couldn't find the one I had set in the Response headers from the Chrome inspector's Network tab.