Notice: Undefined variable: view_mode

Hey Christopher!

Thanks for reporting this. We've encountered similar issues a few times, now, in the past (see #3103483: PHP notice "Undefined variable: view_display" and #3081517: Errors when using module with Layout Library). The cause is typically triggered by specific modules that use Layout Builder's section storage, but don't implement all of the expectations of that component.

My guess would be that the site you reference may use an as-yet unidentified entity type (provided by a Layout-Builder-related contrib module?) that we'll need to make an accommodation for.

Can you identify anything idiosyncratic about the site configuration, and in particular, the block configuration that triggered this error, that we might attribute this to? In other words, can you think of anything on this site that would make it differ from a vanilla Drupal site (which doesn't trigger that error)? Does the emphasis on view_mode trigger any insights for the site?

Thanks in advance for the additional context! I'm sure we could write some code that would avoid triggering this particular error, but we really need to know under what circumstances the view_mode might not be knowable.

Hi Mark, I'm running into this issue by trying to add a block on a page manager page.
Reproduce: Install page manager and use "Layout builder" as variant. Add section to layout and try to add a block.
The entity type and bundle context is given, but view mode is empty. Any reason why there is no fallback to 'default' view mode?

I think adding "default" as the fallback for the view_mode parameter is probably innocuous enough to resolve this particular notice.

The patch looks fine; I may just add an inline comment about why we're adding this fallback.

After reviewing the logic in the getValuefromSectionStorage, method, I think we can and should provide the view mode default at the beginning of the method and let it be overridden in the particular identified contexts. The merge request, above, implements this.

Adding a patch equivalent of the merge request in #6 to demonstrate that tests are still passing (the failures in the merge request were apparently false positives, since they failed on trying to retrieve other testing modules, rather than in the test execution itself).