Impossible to save Layout when block with VBO

I think I found a solution while comparing with Layout Builder module.

patch for Composer usage.

Creating a test regarding https://drupal.slack.com/archives/C7AB68LJV/p1755161643751989

Related: 🐛 Saving a layout after adding a block that contains a form doesn't allow you to save anymore Fixed (this was fixed when this was on a sandbox, the relevant commit is ad556a0

Interesting, the related problem was with the "search block".
Still I can reproduce this, while I cannot reproduce it with the search block.

So I assumed the problem is having a form inside the block. Why isn't triggering in one case but the other?

Adding the issue where this was fixed in core as related.

Looking at that fix, we actually copied the previous core fix to dashboard, then it was not enough in some cases, and was fixed in core in layout builder render element.

So the proper MR should actually just delete

      '#process' => [[static::class, 'layoutBuilderElementGetKeys']],

from \Drupal\dashboard\Form\DashboardLayoutBuilderForm::buildForm. So we don't override the core's one (which is the actual bug: we should have added a new process, not overriding the existing one: just happens that now we don't need ours at all).

I have tested, I confirm that removing the line fixes it.

I have updated the MR.

Trying to write the test.

In the Dashboard issue which fixes it, the test data with blocks with forms had been changed in https://git.drupalcode.org/project/dashboard/-/commit/d12e725428dde68578..., so I guess no more tests for the original fix.

Updating the tests showed that for D10 and Drupal < 11.2, the proposed fix of removing the line will not work.

So maybe for D10 and D<11.2 the first proposal should be used then on another branch use the latest proposal.

As you want @penyaskito

Should 2 MRs be created? One "targeting" D10 and D<11.2 and the other for D11.2

Creating separated test regarding latest review comments.

That's what I feared, that this was a recent fix. If you can do a new one targeting D<11.2, that would be ideal.

Edit: x-post with #14

MR updated and MR for D10 and D<11.2 created.

Tests are failing on D10 because I chose a block "clear cache" which exists from D11...

I also realized that the test only pipelines are green because the problem occurs when using Gin admin theme.

So should I set the test to use it and add it in require-dev?

I don't think this would be specific on the theme?
I could reproduce this with claro.

Checking with Claro.

I don't think this would be specific on the theme?

I was not thinking that too, but what bothers me is that the "test only" tasks in both MRs are green. And tests are using stark theme.

Manually reproducing with stark and claro. And confirming that the fix works on both themes and also Gin.

So I guess it is ready to be merged. I would have liked the "test only" tasks to fail.

I think the problem occurs only on the actual dashboard, not the LB preview. However the test-only still passes with every combination I tried locally (even using gin in the test).

When failing on manual testing, I can see the existing temporary config with
select * from key_value_expire where collection LIKE '%tempstore.shared.layout_builder.section_storage.dashboard%';

I've been debugging this til \Drupal\Core\Form\FormBuilder::processForm, where effectively the "block" form is submitted instead of the "dashboard" form.

Looking at the core issue, this only was tested with a functional javascript test, so I'm guessing this is not reproducible without js interaction.
I tried that and could reproduce a failing test, which passes with the fix 🎉

Credit.

Merged !67.

Thanks for the merge and updated tests!

Great to have been able to reproduce!

I was about to say the issue should be marked as fixed, but it is still waiting the other merge for D11.2 ^^

Thanks a lot @grimreaper!

Automatically closed - issue fixed for 2 weeks with no activity.