When editing a custom elements page view php errors are produced by renderer

Which version of core / lupus-decoupeld are affected?

I'm getting the same issue on Core 10.3.1 and Lupus decoupled 1.0.0-beta6 and custom elements 2.5.0

The problem seems to be occurring because a paragraphs views reference field is causing a view to be rendered on the node edit form (this is the desired behaviour) and the lupus_decoupled_views modules is adding things to the render array that Drupal's renderer cannot process. It's adding things in \Drupal\lupus_decoupled_views\Plugin\views\style\CustomElements::render() and \Drupal\lupus_decoupled_views\Plugin\views\style\CustomElements::render() that will cause errors in \Drupal\Core\Render\Element::children()... I would have expected some sort of pre_render callback to process them but I don't know enough about how the custom elements module works at the moment.

This has only been causing issues on Drupal 10.3 due to #3427177: Replace calls to ::expectError*() from Drupal\Tests\Core\Render\ElementTest which changed an E_USER_ERROR to an exception in the renderer. I think \Drupal\lupus_decoupled_views\Plugin\views\style\CustomElements::render() needs changing to use render arrays rather than just dumping stuff into the render array. However this module has always been cause notices like User error: "total_items" is an invalid render array key in Drupal\Core\Render\Element::children() in the logs.

Not sure why/how the CustomElement style plugin gets called for a view that - as I understand - is not related to custom elements?

Anyway, as pointed out there are errors produced else as well, so we definitely have an issue here. As it seems, the render() method is supposed to return a render array, and we aren't, what leads to the problem.

At the same time, it's also not completing the rendering atm, we have the code that puts the final touches on it in \Drupal\lupus_decoupled_views\Controller\ViewsController::viewsView. So what about moving that final touches

    // Build a view as a custom element.
    $custom_element = new CustomElement();
    $custom_element->setTag('drupal-view');
    $custom_element->setAttribute('title', $view->getTitle());
    $custom_element->setAttribute('view_id', $view_id);
    $custom_element->setAttribute('display_id', $display_id);
    $custom_element->setAttribute('args', $args);
    $custom_element->setAttribute('pager', $result['#rows']['pager'] ?? []);
    $custom_element->setSlotFromNestedElements('rows', $result['#rows']['rows'] ?? []);
    $custom_element->addCacheableDependency(BubbleableMetadata::createFromRenderArray($result));

    // Allow other modules to change the custom element without replacing the
    // entire method.
    $this->moduleHandler()->alter('lupus_decoupled_views_page_alter', $custom_element);

to the render() method and returning the expected renderable via $element->toRenderArray()? That would solve the code-reusing issue I commented on the MR above as well.

@fago yes \Drupal\lupus_decoupled_views\Plugin\views\style\CustomElements::render() is supposed to to return a renderable array - but it doesn't in 2 two ways:

• $result['rows'][] = $custom_element; - $custom_element is not a renderable. I think this should be $result['rows'][] = $custom_element->toRenderArray();
• And then there's $result['pager'] = $this->pagination($result['rows']); this also cause issues that are harder to see how to fix because of what \Drupal\lupus_decoupled_views\Controller\ViewsController::viewsView() is expecting.

Not sure why/how the CustomElement style plugin gets called for a view that - as I understand - is not related to custom elements?

In our case the view definitely is supposed to use CustomElements - it's just not using \Drupal\lupus_decoupled_views\Plugin\views\display\CustomElementsPage or \Drupal\lupus_decoupled_views\Controller\ViewsController::viewsView. It's a views reference field in a paragraph.

> I'm not sure why we even need the override with ViewsController.

We might need it for the Lupus-CE-Renderer to pickup the responses cleanly. I'm not sure it does so with a custom element render array, we might need to return the CE-object. If it supports the CE-render array also we might be fine without the controller.

Anyway, if the controller does not cause issues in general, let's better keep it and solely focus on fixing the bug.

@alexpott / @useernamee

The 'v2 way of rendering' (Processors) is still the same in v3, so there should be no need to test on v3. We should even be able to test these issues (that don't trigger any use of v3-style Custom Elements Displays) by temporarily copying v2 code back over v3.... for the moment at least.

I'm just noting this befause updating to v3 is explicitly non-trivial.

If possible / for the moment, any fix that comes out of this will be applied to the v2 branch also.

PR89 is not going to solve my problem because \Drupal\lupus_decoupled_views\Plugin\views\style\CustomElements::render() adds things to a render array array that are not renderable. As long as the module continues to do that anything that embeds the view is going to have problems. The fix in PR89 is a workaround for this only for preview but there are other cases where this occurs.

I far as I can see, if \Drupal\lupus_decoupled_views\Plugin\views\style\CustomElements::render() continues to return a non-renderable array, you'll continue to have unexpected issues due to the approach.

I don't see why this issue is related to the custom elements version, the APIs used did not change at all. So the fix should apply to both just fine.

Anyway, I very much agree with alex pott that we need to fix render() to return a proper render array.
Also added some comments to the MR.

replied in drupal issue, but I think the problem is that view's renderer doesn't know how to render custom elements.

This rendering is good, it's correctly rendering the custom element using markup serialization:

<div class="preview-section"><drupal-view title="" view-id="te" display-id="custom_elements_page" :pager="{&quot;total_pages&quot;:2,&quot;current&quot;:0}"><template #rows="">
<teaser-wide href="http://devblog.ldp-project.localdev.space/drupal/custom-elements-our-solution-soft-decoupled-drupal-57" title="Custom Elements: A solution for soft-decoupled Drupal!" category="Thunder core" excerpt="When it comes to decoupling, it turns out there are many options on how to decouple. Not only are there many technology choices in choosing the right frontend framework and APIs involved, the questions become also more foundational: Which system should be in charge for handing different aspects of the applicaiton, e.g. routing, placing blocks or authentication?" :image="{&quot;aspect-ratio&quot;:133.33000000000001,&quot;src&quot;:&quot;http:\/\/admin--example.ldp-project.localdev.space\/sites\/example\/files\/styles\/300_225\/public\/2024-09\/chocolate-brownie-umami.jpg?itok=jcNG8O0W&quot;,&quot;srcset&quot;:null,&quot;alt&quot;:&quot;Alt Placeholder&quot;,&quot;title&quot;:&quot;\u00a9 GPL v2+\nSource: Drupal core umami installprofile&quot;}" published-at="27. March 2021"></teaser-wide>
...
</template>
</drupal-view>
</div>

So all seems fine to me. Yes, it's not a frontend rendering, but that's another story.

That's why I converted array to string, pretty print it and show it as markup.

Why are you dumping the literal object when the above rendering is already good? Imo, we should simply add <pre> tags around the above custom element rendering (e.g. with #prefix #suffix) to make he markup readable / visible in the browser.

Yes, that's not a visual preview rendered in the frontend, but that would be a bit more complex and require iframes to correctly go via the decoupled frontend. There is code doing so in the issue #3338911: Frontend-rendered layout-builder previews, so that would be a great addition, but that is clearly out of scope here. Let's have correctly rendered markup shown in the preview for now. We could open a follow-up for a nicely rendered preview via iframes though!

Also I'm a bit unsure what to do with the pager. So far, I translated it into the custom element, and slot on the view, but I guess we could also leave it as attribute.

So far the code did:

$custom_element->setAttribute('pager', $result['#rows']['pager'] ?? []);

Changing that would be an API break. Why would we do that? Are there issues with the pager?

Generally speaking, a slot should be used for nested content that may be composed for any kind of content, not for passing data - use attributes for that. So the pager being an attribute is good, so the drupal-view component stays in control of how to render the pager.

From a quick check the MR looks mostly good, except for my remark related to PluginException being the wrong exception is not yet addressed.

> It works if I don't transform rows in render arrays but leave them as custom elements objects here. The issue is that render transforms render array into markup, but then the value is not string or MakupInterface which it expects.

hm, not sure I get that. You mean custom elements produces an invalid render array, that cannot be correctly rendered? If so, we should open an issue for fixing that and get that fixed. Returning Markup instead of a plain string would make sense to me. Please work with roderik as necessary to get it addressed.

I did not know this code yet, and/so could not make out from the discussion, what to do... so I needed to just tinker with it myself.

End conclusion: yes, this solution is already good. (Updated issue summary, with my understanding of what we are doing.) It just needed bugs fixed:

Another issue I get now is that markup format is producing an error:

That's because the controller was still doing $custom_element->setSlotFromNestedElements('rows', VALUE);, while VALUE was changed from $custom_element to $custom_element->toRenderArray(). The setSlotFromNestedElements() is now fixed.

the pager is now (again) producing errors on pre-view:

The preexisting code in the row style plugin just put an array of values into $result['pager']. That is not OK / not a valid render array.

I moved the code into the CustomElementsPage display plugin, because it's only needed there. Now we're not setting $result['pager'] anymore -- error is gone.

'custom_elements' format responses (i.e. anything using the "custom_elements_page" display plugin) still produces the same output.

* The change looks good now and generally ready. However, the MR needs a re-roll and a resulting glitch to be resolved/updated. (see my comment)
* I suppose this pager issues are not new? Let's open dedicated bug reports for each of them please.
* It seems there is no test coverage for that feature at all, we really should add some. Let's add a follow-up for it.

Thanks!

I couldn't merge either. (Happened to me more often.) And I seem to lack some git knowledge (about --no-ff and --squash not working together) so I can't really explain.

But I could reproduce a squashed commit locally and compare that it was equal to the branch, so all good.