Rendered item is not indexed in groups content using layout builder

Created on 25 October 2022, about 2 years ago
Updated 27 May 2023, over 1 year ago

Problem/Motivation

Authenticated role is not correctly taken into account while indexing rendered_item which is the rendered HTML output of the node. None of the layout builder content is recorded into the index by checking with queries in solr administration panel.

Steps to reproduce

Search server solr, group module, layout builder
In a group, create a node and add some content using the layout builder.

Add "Rendered HTML output" to the index:

  • Role: authenticated user
  • View mode: full

Create the index

The content added with the layout builder is not in the index.

The issue is found in "src/Plugin/search_api/processor/RenderedItem.php" in addFieldValues()

Before rendering the HTML of the node, the "index user session" gets an access forbidden. Applying patch "3181863" actually solve this access issue.
But when processing the rendered HTML output field "(l292) $this->getRenderer()->renderPlain($build)" returns a "the 'entity:user' context is required [...]" error falling into throwing an exception and skipping the field.

Proposed resolution

By giving an existing user id (uid) to the temporary user session used, it can the access to the content of the rendered HTML output field.
Proposed solution is to not modify current behavior of the code and provide a new hook to alter the user id (uid) provided to the temporary user sessions. The new uid is to be provided by a custom code using the new hook.

Remaining tasks

  • Validating the solution principle
  • Testing the patch
🐛 Bug report
Status

Needs work

Version

1.25

Component

General code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reporting this problem, and sorry it took a while to get back to you.

    As you are probably aware, this is a really tricky problem, where it seems there are no solutions that work for everyone. An alter hook therefore could make sense. However, we don’t use hooks in this module anymore (all existing ones have been deprecated, see #3023704: Convert hooks to events ), so we’d provide an event for this instead. (Also, just for your information, there is \Drupal::moduleHandler()->alter() for alter hooks, no need to manually pass an array with a reference to invokeAll().)

    However, it seems like this could also be solved by having an alternative when configuring the field to specify a user ID instead of the roles? Or what else would you put into your alter hook implementation (resp. event listener)? Code that looks up a user with the correct roles?
    Setting a fixed user ID is, of course, also not ideal, since that user’s roles can change (though I would of course advise on adding a special user just for that). But as an optional alternative, it might solve a few users’ problems with this.

Production build 0.71.5 2024