SystemMainBlock only functions when used by block.module

I'm sorry to interrupt, but why is this a better solution than returning an empty array by default? Is there some other problem you are solving?

This seems overly complex to me. The fatal error is avoided by returning an empty array, right?

I think the idea of restricting the main block to block module is better than just throwing a fatal error for other modules. But this is still looking overly complex to me. I have argumented for the benefits of the simpler solution here: https://www.drupal.org/node/2819219#comment-12135122

I have not yet seen any practical reason for "it should never". Can you help me out to understand those? Also could there be some case where other modules could need an access to the main block? Thanks!

Hi!

I'm wondering why my questions go unanswered. Are they inappropriate? These are honest questions so if there's something wrong how I present them I would be happy to be guided!

So, full disclosure: I support the spirit, if not the specific implementation, of what Tim's suggesting here.

@jiv_e

I think your points, on this issue and the other you've referenced, are fine and appropriate. That being said, I'd start my counter argument by pointing out that contextual plugins (of which blocks are a member) work a little differently that perhaps what you're expecting.

Contextual plugins operate on the idea that there are certain method which cannot be invoked until context is set on the plugin. Other methods (like forms for configuration) CAN be invoked w/o context because it's not necessary for them. The block build() method is one of these methods that requires contexts to already be set. The conversion of the MainContent Block is one of those things I started and with help from others, we ultimately got working with the new plugin system. That being said, "context" came along a little later, and the main content block was never revisited subsequent to the introduction of that api addition. Which is to say that the setter that plugin uses is weird, non-standard, and there's already a standard for plugin which need that sort of handling... it's called context(s).

To address Tim's solution more directly, I'd actually invent a new type of context object that only the Main content block requires. That would give us an object on which we could place the expected render array. If the context isn't provided via a typical context provider, then no one will ever accidentally get it, and the block system itself could just hardcode the service id of that context. This might actually make the render pipe-line smoother and clearer as there'd be a service to which objects could read/write main content output. That's just my 2 cents on the approach. I'd love to iterate on this more and see where it goes.

Eclipse

I have a conflicting experience with the system_main_block.

I'm using the following modules:

• Drupal core 8.6.5
• ctools 8.x-3.0
• page_manager 8.x-4.0-beta3
• panels 8.x-4.3
• panels_everywhere 8.x-4.0-beta1

While I initially could not use Main page content in my panels layouts, when I added a condition of content type = page - it started working.

I only add this comment in case someone else is as frustrated as I was in trying to include the node content in a variant of node/{node}

Edit: While I was not able to avoid the error on the landing page I was working on, I was able to create a new landing page, and edit the layout on other nodes, without triggering the error. Since I reconstructed the new landing page with precisely the same elements as the original, I don't know what difference might have triggered the error unless it is some sort of data corruption in how that particular page/node was stored. In any case, while you can get around it, the error is very frustrating and nearly impossible to diagnose because you lose the ability to add, delete, or change blocks included in the areas managed by layout builder. (Unless there is another way to access that? I assume they are in the database, but I didn't want to go mucking about in there.) I'm sure future users would appreciate a fix, or at least some tools to address it.

A clue? While trying to figure out the error, I used other systems which allow you to manage the display, which kept reporting that I had unsaved changes. I would click the 'save' button, and would receive a message that the display had been saved, but upon re-visiting that module it would again say there were unsaved changes. Odd.
-----------

Is there any chance of a functional patch for this? I see other issues with suggested patches were closed as duplicates, but there doesn't seem to be a resolution.

I ask because I *just* started having this error in an existing installation of Drupal 8.9.1, possibly because of running a 'composer update' command. Since the layout I'm trying to manage is the front page, this has brought my site development to a halt (trying, painfully to move from D7 to D8). I can see the front page, but I can't get at any of the pieces controlled by the layout builder to add or change blocks. I'm using a contrib theme that depends heavily on layout builder for basic page visual structure.

Wish I could help, but I don't have the skills. Any advice welcome!

My error:
Argument 1 passed to Drupal\Core\Cache\CacheableMetadata::createFromRenderArray() must be of the type array, null given, called in [site root]/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php on line 110 in Drupal\Core\Cache\CacheableMetadata::createFromRenderArray() (line 149 of [site root]/core/lib/Drupal/Core/Cache/CacheableMetadata.php)

@sjnorton

I'm also doing a migration from D7 to D8 too and I'm also having the same issue. Have you find a solution for this problem?

Thanks!

@sseto

No - my only solution was to rebuild the page from scratch (for the most part, just inserting the same blocks). I don't know why my original home page caused those errors.

this patch does not apply to 9.1.x
last test also failed

however #2885370: SystemMainBlock::build does not always return array still does apply cleanly to 9.1.x

marking this as a duplicate, and re-openning the other