Unable to save 'Access Unpublished' settings form due to TypeError in Drupal\Core\Render\Element::children()

I am able to replicate the issue.

Let me try to work on this.

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!

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

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.

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.

hi chr.fritsch, I have opened MR for the fix. Please review.

Patch #14 doesn't seem to work for Drupal 11.2.1

Patch #14 seems to work for my needs (Drupal 11.2.4).

Can confirm, patch in comment #14 fixes the problem for Drupal 10.5.x

Added a patch corresponding to the new MR 32. Tested successfully on Drupal 11.2.8.

When following the steps to reproduce on a clean install, I receive the following errors.

Warning message
Schema errors for access_unpublished.settings with the following errors: access_unpublished.settings:modify_http_headers variable type is string but applied schema class is Drupal\Core\Config\Schema\Sequence. These errors mean there is configuration that does not comply with its schema. This is not a fatal error, but it is recommended to fix these issues. For more information on configuration schemas, check out the documentation.

Error message
Warning: foreach() argument must be of type array|object, string given in Drupal\access_unpublished\Form\SettingsForm->prepareHeadersDisplay() (line 204 of modules/contrib/access_unpublished/src/Form/SettingsForm.php).
Drupal\access_unpublished\Form\SettingsForm->prepareHeadersDisplay() (Line: 76)
Drupal\access_unpublished\Form\SettingsForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Nice catch @generalredneck!

The warnings should have disappeared now.

Added an empty-headers test case to ensure no warnings are triggered.

Lets call this toddler aged issue fixed. Thank you Mably for lighting the fire... and thank you to the rest of you for testing and patching and putting forth the hard work. This is availible in the dev version for the immediate future.