#Needs steps to reproduce

@newswatch you will need to provide more details about your configuration, possibly a a URL, to receive help. Without that we cannot know what does not work on your site.

First, can you reproduce the problem on a new site with just D11 core and statistics ?

The module worked fine till I started using it as a contrib module (after it was moved out of core).

Now, the counter does not move. No matter what.

If the counter doesn't move, then this module is of no use really.

I think @bnjmnm would be the best person to review the solution.

The error occurred after upgrading from Drupal 9 to Drupal 10. To investigate, I exported the configuration files and searched for occurrences of 'content:' strings.

For example, could the following configuration in views.view.comments_recent.yml be causing the error?

label: 'Recent comments'
description: 'Recent comments.'
display:
  default:
    display_title: Default
    display_options:
      title: 'Recent comments'
      fields:
        changed:
          settings:
            future_format: '@interval hence'
            past_format: '@interval ago'
      empty:
        area_text_custom:
         content: 'No comments available.' # Could this be the source of the problem?
  block_1:
    display_title: Block
    display_options:
      block_description: 'Recent comments'
      block_category: 'Lists (Views)'

I’m not entirely sure, but could the content: 'No comments available.' string format be causing the issue? Should it now be structured as:

content:
  value: 'No comments available.'
  format: 'plain_text'

Is this new format required in Drupal 10, and if so, was this change documented? I’d appreciate any clarification or guidance regarding this.

This is admittedly kinda hacky

$this->options['content'] is expected to be an array but can sometimes be a string

@lance lancelot Have you been able to pin down when or why this would be the case? We still need steps to reproduce this on a fresh Drupal install since as it stands currently, the error might just be the correct way to handle this because there is something wrong upstream.

I encountered the same error and implemented a temporary fix, which needs review. The issue arises because $this->options['content'] is expected to be an array but can sometimes be a string.

Here’s the patch I applied to web/core/modules/views/src/Plugin/views/area/Text.php:

  /**
   * {@inheritdoc}
   */
  public function preQuery() {
    // Normalize $this->options['content'] to ensure it's an array.
    if (is_string($this->options['content'])) {
      // If it's a string, treat it as the content value with a default format.
      $this->options['content'] = [
        'value' => $this->options['content'],
        'format' => filter_default_format(),
      ];
    }

    // Proceed as normal with the now-normalized content array.
    $content = $this->options['content']['value'];

    // Check for tokens that require a total row count.
    if (str_contains($content, '[view:page-count]') || str_contains($content, '[view:total-rows]')) {
      $this->view->get_total_rows = TRUE;
    }
  }

Re #6 Yep that's what it looks like. cache_discovery - cid library_info:olivero is the culprit. If this cache item is first generated when the XB UI loads, the $route_name === 'experience_builder.experience_builder' condition is true and the library info cache will omit the extra assets. I suspect when that scenario happens then Olivero risks having some assets missing, but I haven't confirmed this.

Ok found from comment under experience_builder_library_info_alter and previous MRs it's because of Drupal.ajax bringing in Drupal.message that brings in Olivero assets but because the hooks run after a cache clear the current workaround that unsets the drupal.message library isn't getting triggered if a page that adds the library is visited first?

I updated the steps to reproduce and added a failing e2e test that admittedly does not follow the exact steps as summarized, but still runs into the problem. In the test, it fails due to an error vs a non-passing assertion because the pile of Olivero assets include navigation JS that assumes certain elements are present and it errors when those elements aren't found.

quietone → closed merge request !167

According to @larowlan, this is a problem in the formatting of a yml file. And there has been no discussion in 4 years to suggest that there is another problem. So, I am closing this.

If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue → starting from "Install Drupal core".

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