Core Update 10.5.1 --> 10.5.2

There have been no other reports of this critical bug in the days since 10.5.2 released so I am tagging this "needs steps to reproduce" because there must be some setup we need to identify that's causing the problem. My organization has been using 10.5.2 with large forms without issues.

When you say that the browser stays on the edit form, does that mean the form doesn't post? Are there any error messages logged, or on the screen? Are there browser console errors?

@the form doesn`t post
yes, that is what it looks like.
There a no error messages.... no JavaScript error and no php-error.

I tested it on different server. all server have the same problem.
An entity with 23 fields works fine. An entity with 69 fields cannot be saved anymore.
It is a plattform, which is not new.... it runs a couple of years.

I downgrade do 10.5.1 again and everything works fine.

🐛 FormState::getTriggeringElement() behaves inconsistently when request is malformed Active is the only change to the forms system in 10.5.2. Does reverting the change to core/lib/Drupal/Core/Form/FormBuilder.php fix 10.5.2 on that site?

Yes, it does.... with the old FormBuilder.php (Version: 10.5.1) I can save the entities and nodes with plenty of fields.... :-)

Thanks for checking. I commented about the regression on that issue.

Based on this the site may have contributed or custom modules that alter form processing.

Yes I do.... a lot of form_alter :-)

I think, we are on a good way.
I deaktivated the form_alter Hook for a special Entity Type and now the 10.5.2 Version can save the entity.
Obviously it has nothing to do with the number of the fields in the entity.

But what is the reason for that.

I used the form_hook_alter for years like this:

function MODULNAME_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {    }

We would have to see the code within the hook function to answer your question.

for example....
there is a entity-Type with the name: gebaeude and the bundle with the same name: gebaeude

  if (
    ($form_id == 'gebaeude_gebaeude_form') or  // hier für Gebäude
    ($form_id == 'gebaeude_gebaeude_edit_form')
  ) {
    // zweiter Speichern button rechts unten
    $form['actions']['submit_secondary'] = [
      '#type' => 'submit',
      '#value' => t('Speichern'),
      '#attributes' => [
      ],
    ];
}

this code snipped generates a second Save-Button on the form.....

Everything is very simple.... no strange things.

Yet that code seems exactly like what 🐛 FormState::getTriggeringElement() behaves inconsistently when request is malformed Active is trying to prevent, in principle.

from a UX point of view another submit button with large forms is help full for the user (one near the top, one near the bottom). Why should that be forbidden?

We are also seeing this after upgrade to 10.5.2. Custom form does not post back.

As a temporary fix we have downgraded to 10.5.1.

This doesn't meet the criteria for a critical bug → .

@eastdrive
it is not necessary to downgrade the whole drupal installation to 10.5.1.... Look at my post #7

I don't understand, while they do this.....

a second submitbuttom is very helpfull......

greetings
Berthold