Worth noting, I'm not sure how feasible this is. Currently, this module acts on any table that matches the configured selector, regardless of how that table was added (via CKEditor-equipped WYSIWYG, hardcoded in a template, etc.). I figured it's worth having an issue so we have some place to discuss, though.
jakaeser → created an issue.
Latest patch fails on 8.x-1.0-rc5. Here's a re-roll.
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 .
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.
jakaeser44@gmail.com → changed the visibility of the branch 3421309-unable-to-save to active.