1

After upgrading from 10.0 to 10.1.7, changes to block configuration were no longer saved.

I cannot reproduce this in an out-of-the-box instance. I've turned off all custom modules and as many of the contrib modules in use that I can without utterly breaking the site due to interdependencies between modules and content structures, etc. Nothing changed with this behavior.

I've since moved on to attempting to locate where the behavior is explained in xdebug.

When I click the submit button in the block config form, stepping through in xdebug, I reach ::submitConfigurationForm() in BlockPluginTrait.

At this point $form_state contains the changed block title in $form_state->decoratedFormState->values[settings][label].

::blockSubmit() is then called.

It progresses to FormBuilder::buildForm() where ::processForm() is called and returns an EnforcedResponseException code of 303 (Other).

No error message is given on the screen, nothing logged, but the result is a return to the block layout screen with the config change not having been saved.

What does the 393 enforced response exception signify and what can cause it in the context of saving a block config?

1
  • I added the question at the bottom. It is not a big report, it is the detail of how I found where the normal behavior changes.
    – JAyenGreen
    Commented Jan 27 at 1:07

2 Answers 2

2

What does the 30x enforced response exception signify and what can cause it in the context of saving a block config?

You are debugging low-level code on how Form API handles redirects. Drupal forms use this exception to transport redirect responses to the Symfony stack because they didn't find a way to return it from the form controller. This is an internal issue for core developers. You need to debug Form API level code returning a redirect response from a form class or setting the redirect in $form_state in places where you don't want to do that.

In Form API the default for any form is set to redirect to itself after a successful submit to display a new empty form. Even a very simple form would show this exception in xdebug. Additonally, a destination query parameter can override any redirect URL. Where the user is sent after a form is submitted is not necessarily determined by the form.

1
  • Thanks for that. So, hmm, if the config save has gotten to that point already, with the config change still in the form state object, it gets more curious why it’s not saved.
    – JAyenGreen
    Commented Jan 27 at 18:14
0

Reasoning

The 303, indicating redirects not working of failing, might be due to ContentSecurityPolicy (CSP) header set to for example form-action 'self'.


In that case, your title is correct:

Block config not saved apparently

If the culprit is the CSP header for form-action, then the config actually is saved, but there is no feedback shown.


Your symptoms

No error message is given on the screen, nothing logged, but the result is a return to the block layout screen

are also consistent with this header issue.


This header can be set by the server or by Drupal, for example by the CSP Drupal module.

Troubleshooting

  1. In a browser, press F12, choose the Console tab and see if there is any error talking about CSP headers.

  2. Remove the form-action part (everything from form-action to and including the first ;) of the CSP header and see if feedback is shown after saving config.

  3. Still not working? Choose the Network tab, click on the original page request (not the 303) and see if the form-action part of the CSP header really has been removed.

Solution

Make the CSP header as secure as possible simultaneously allowing feedback from Drupal forms (how to is out of scope within this answer).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.