Error: Cannot use object of type Drupal\Core\Render\Markup as array in Drupal\Core\Render\Renderer->doRender() (line 218. When checkbox 'Use field template' is checked

Can you share the config of your view and some steps to reproduce?

Thanks

Thanks, that's very helpful

Confirmed this happening with the attached view config from #3 (like @larowlan already said: Super helpful, thanks!).

This looks like a regression introduced in #2794261: Deprecate render() function in common.inc:

\Drupal\views\Plugin\views\field\EntityField::render_item originally used the render function from core/includes/common.inc.

That function has a check if the provided element to be rendered is not an array, in which case it returns the element as-is. (See https://git.drupalcode.org/project/drupal/-/blob/9.3.x/core/includes/common.inc#L406-410)

That check seems to be missing from the currently used \Drupal\Core\Render\Renderer::render.
If I add that check and return the element as-is in \Drupal\Core\Render\Renderer::doRender as in the attached patch, the test View works without errors.

Upping version to 9.4.x-dev since changes need to be committed there first and then be backported
Tagging with Needs tests for a minimal testcase that proves the above is indeed true.

It would be nice if anybody that ran into this issue can confirm the patch does make the error go away.

I ran into this issue today after installing 9.3. This fixed it, thanks very much!

Like this approach better, seems to be tackling the root cause of the problem.

No interdiff since it's a new approach.

Bumping to critical.

This patch is a combination of patch #6 (patch #9 doesn't respect the field template) with the addition of a test class.

I can confirm this fixes the error.

However it doesn't actually use the field template anymore which it used to.

Thus spoketh @rviner in #10

I ran the test_only patch from #12 against a clean install of 9.2.x-dev and it passed.

What does your field template look like and are you sure the classes in there aren't applied to the View after patching it?
I would expect my test-class to fail if the field template wasn't applied, since it's actively looking for classes inherited from the field template in the theme (which is classy in the test-class).

Local TestBot was more forgiving than d.o. TestBot. Giving it another go.

Ok, it works with the latest patch.

It didn't work with patch from #9. #9 fixes the error but doesn't use the template.

Thus spoketh @rviner in #16

Great, thanks for the confirmation :)

Interdiff for the archaeologists out there.

TestBot is going to return green AFAICS, now it's time to appease the Big Brains around here by putting this up for scrutiny => Needs review.

Confirmed https://www.drupal.org/project/drupal/issues/3253568#comment-14335441 fixes the issue and uses the correct template in Drupal 9.3

Can also confirm that the fix in #6 solves the error and uses the correct template.

Attached is a simpler kernel test for this

Oops. I meant for the test to use the existing test_field_field_test view, not test_field_alias_test. Not a big difference but this might be better.

And just for reference - I got this approach from FieldWebTest::testFieldClasses().

I'm guessing that this error is happening because a call to render() has been replaced with \Drupal::service('renderer')->render(); as render() has been deprecated in 9.3.x.

The change made here is quite a big change and I'm not sure we're basically repeating the following code from render()...

    // Safe-guard for inappropriate use of render() on flat variables: return
    // the variable as-is.
    return $element;

Without the comment.

In someways this feels a step backwards. Why are we not fixing this in views?

Yep this was caused by #2794261: Deprecate render() function in common.inc.

One option would be to move some of the logic from render to \Drupal\views\Plugin\views\field\EntityField::render_item()... but that leaves the double rendering in place.

The correct fix is to change \Drupal\views\Plugin\views\field\EntityField::getItems() from

    if ($this->options['field_api_classes']) {
      return [['rendered' => $this->renderer->render($build_list)]];
    }

to

    if ($this->options['field_api_classes']) {
      return [['rendered' => $build_list]];
    }

And rely on the rendering occurring in \Drupal\views\Plugin\views\field\FieldPluginBase::advancedRender()

However that's tricky because we'd be changing what's returned from a public method... although it'd then be more similar to what is returned when field_api_classes is not checked...

Not sure what to do here but I'm pretty sure that the change to the renderer service is not the best option.

I think the suggested fix in #30 is the right way forward.

If the checkbox is not checked then each delta is extracted separately and rendered to avoid the field API wrapper:

      $items[$delta] = [
        'rendered' => $build_list[$delta],
      ];

So by returning the full render array when the field template is enabled we are making this more consistent.

The docblock also says:

   * @return array
   *   An array of items for the field.

And while that's not very specific about what the "items" are, at least we would be returning an array of items rather than a pre-rendered string.

The fix in #30 works, according to #31 we can get away with it due to the non-specific doc-block.

This is going to need a test - as far as I can see we don't have any test views that use field_api_classes: true.

This is going to need a test - as far as I can see we don't have any test views that use field_api_classes: true.

I believe the test is already in the patch?

+++ b/core/modules/views/tests/src/Kernel/Handler/FieldFieldTest.php
@@ -339,6 +339,27 @@ public function testFieldAliasRender() {
     }
   }
 
+  /**
+   * Tests the result of a view field with field_api_classes enabled.
+   */
+  public function testFieldApiClassesRender() {
+    /** @var \Drupal\Core\Render\RendererInterface $renderer */
+    $renderer = $this->container->get('renderer');
+    $executable = Views::getView('test_field_field_test');
+    $executable->initHandlers();
+
+    // Enable field_api_classes for the id field.
+    $id_field = $executable->field['id'];
+    $id_field->options['field_api_classes'] = TRUE;
+
+    // Test that the ID field renders with multiple divs from field template.
+    $output = $executable->preview();
+    $output = $renderer->renderRoot($output);
+    $this->setRawContent($output);
+    $field_values = $this->xpath('//div[contains(@class, "views-field-id")]/span[contains(@class, :class)]/div', [':class' => 'field-content']);
+    $this->assertNotEmpty($field_values);
+  }

Oops, I think only read the interdiff and then went looking for an exported view after applying the patch locally :)

I think #32 is probably OK, the only way it could break is if a custom module is doing something very specific to this views configuration - like a view-specific alter. Since that's not impossible, we should add a change record and a release note, but it seems unlikely so probably OK for this to go into 9.3.1.

The other option would doing the earlier approach in 9.3 and this approach in 9.4.

+ 1 for RTBC.

I put the error in the title for SEO results as I searched the error multiple times, but had to come to the release page to find the bug.

I've added a release note, I couldn't think of anything to put in the change record that's not in the release note, and the likelihood of this causing an issue is close to zero. Additionally for sites already on 9.3.0 they have a fatal error on these views so it can't possibly be worse than that.

Committed/pushed to 10.0.x and cherry-picked to 9.4.x and 9.3.x, thanks!

Restoring meta-data

Thank you! #32 patch solve the issue for the website I was updating.

Re-Restoring meta-data.

I wanted to mention: I have a view that is, I believe, suffering from either this bug or a similar one. However, none of the fields in this view use the field template option.

I have isolated the problem to a particular view on my site, which begins to fail when I upgraded from d9.2.10 to 9.3.0. As I mentioned, none of the fields in the view use the field template option. As such, applying the suggested patch doesn't resolve the exception I'm seeing when I try to load a page that contains the view.

The exception looks like so:
2021/12/17 16:03:36 [error] 1674#1674: *260 FastCGI sent in stderr: "PHP message: Uncaught PHP Exception Twig\Error\RuntimeError: "The "replace" filter expects an array or "Traversable" as replace values, got "string"

== added later ==
I have tracked down where the problem is in my application. In the view setup/admin page, under "format" I have specified an Unformatted List showing Fields. On the settings for the unformatted list, I've specified the "row class" as: {{ type|replace(' ', '-')|lower }} . This seems to be the thing that is causing the exception.

I'm not expert enough to know if this is the same problem described in this thread. But it definitely arose when I upgraded to D9.3.0.

#6 worked for me.

@mefron you can try applying the patch here to your site, or updating to 9.3.x dev. If that doesn't resolve your issue, please open a new issue in this queue with the information you provided so far (but ideally steps to reproduce the bug from a clean Drupal install - such as recreating the view configuration).

@mefron I've stumbled over this stack overflow link https://stackoverflow.com/a/54895016 which isn't Drupal related, but might help.

If not: You should follow the advice of @catch and open a new issue.

The patch from spokje works for me.

Many thx!!!!

whoa. Thanks for the patch. This caused some big unnotified error on a D9.4 project.