Confirmation form for disabling per-entity layout overrides shows a success message and should not

Verified from manual testing that this is still an issue. Updating the IS and added steps to replicate.

Opened a MR to strop the message from showing on the Disable Layout Builder Form.

There was no specific test coverage for the disable form itself, rather than add a whole new test for this I added coverage to an existing test that was already asserting LB messages.

@mstrelan raised a clever alternate approach on the MR. Setting back to NW for that

Updated the approach based on the feedback from @mstrelan

Can confirm I'm seeing the issue described following the steps of the issue summary.

Attaching before/after screenshots to the summary.

MR does fix the issue.

Not sure this will work if the string has been translated or altered via custom strings; is there no way of preventing the message from being added in the first place?

Based on @longwave's comment in #27 I've built a POC of an alternate approach that prevents the message from being added to the messenger().

This is a more generic approach that other forms could use in the future if this comes up again in other places in core.

Can confirm still working @longwave what do you think?

To keep this one from stalling going to mark but new solution is also still working as mentioned. If I jumped the gun apologize

Simplified this even further, if we redirect at all then we shouldn't show the message?

New approach appears to work as well.

I was concerned the new approach could stop the message from showing when we do want it to display, but I've checked all child classes of EntityDisplayFormBase and the only one that sets redirects in the form state is LayoutBuilderEntityViewDisplayForm.

I prefer the approach taken here to my original MR & it's flexible enough to be used in the future if something like this pops up again. So +1 from me

Committed/pushed to 11.x and cherry-picked back through to 10.3.x, thanks!

catch → closed merge request !7489

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