Lazy builder broken (#type defaults not loaded)

An alternative approach here would just be to call this on the $new_element

if (isset($elements['#type'])) {
  $element += $this->elementInfo->getInfo($elements['#type'])
}

#39 That sounds useful but I'm concerned it's a bit hacky to call getInfo() from a new place.

It's roughly 10 lines below where the renderer already calls it (off the top of my head when I hit this issue yesterday)

+1 to #39

Needs tests and we need to update https://www.drupal.org/docs/drupal-apis/render-api/auto-placeholdering#s... →

Also we should check if we want to load defaults for pre_render and post_render. But there we need to also check if defaults were already loaded and someone changed the type.

Why is phpstan choking on this on an unrelated variable that it should know how to inspect.

Meh added it to the baseline. The alternative was asinine:

    if ($this->rendererConfig['debug'] === TRUE) {
      $render_start = microtime(TRUE);
    }

    // Had to become (also further down):
    $debug_mode = $this->rendererConfig['debug'];
    if ($debug_mode) {
      $render_start = microtime(TRUE);
    }

To hell with that :)

Wonder if the IS could get some love. Using the standard template please

Good to see the tests still pass but believe will still need test coverage

Thanks.

Will try to find time next week to test this. If someone wants to have a crack at this in the meantime, go ahead.

Added tests

All green and the "test-only changes" job shows the failure we want to see.

That looks great, thanks for the red/green tests. I scoured over the code and didn’t spot anything concerning.

The issue summary still has:

Decide what to do with pre_render (and post_render) as theoretically those could also set or change the type.This probably deserves a follow-up as it has far more edge cases than lazy builders because the array specifying a lazy builder cannot have a #type set.

Does a folow-up exist?

Also not sure why this is adding a new entry to the phpstan baseline, is it somehow picking up a pre-existing issue it didn't pick up before?

Does a folow-up exist?

Not yet, I can probably create on later this week. if others want to beat me to it, go ahead.

Also not sure why this is adding a new entry to the phpstan baseline, is it somehow picking up a pre-existing issue it didn't pick up before?

Yes.

Added follow-up here: 📌 Decide if we need to load #type defaults for #pre_render callbacks Active

So setting back to RTBC.

Ran into this the other day on a client project, and realised I needed to nest the render array after a few minutes headscratching, but didn't put two and two together that it was this specific bug until I came back here. This is annoying and we should fix it.

Committed/pushed to 11.x and cherry-picked to 10.5.x, thanks!

catch → closed merge request !11250

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