Contrib.social

[META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters

Open on Drupal.org →
Created on 18 July 2024, 2 months ago
Updated 12 September 2024, 16 days ago

Overview

Extracting this from #3440578-80: JSON-based data storage proposal for component-based page building → because that's a long issue with a lot of different discussions, and it probably needs its own issue.

Both core search module and search_api module rely on view modes so that site builders can decide how content gets rendered into the search index. For core search module it hard codes the 'search' view mode, for search_api, you can configure which view mode to use.

The search view mode almost always wants to have all of the field content that the default view mode does (body field especially), but without elements that would 'pollute' the search results like field labels, related content blocks, CTAs, social widgets etc. so that if I search for "newsletter" or "Facebook" I don't get every article on the site back in the results, but only the ones with content actually mentioning newsletters or Facebook.

This means the search view mode is 99.9% of the time going to want to render both the 'fixed' and 'loose' content that is entered for the default view mode.

There is a very similar problem if you wanted to show for example the 'full' content of the entity in a newsletter subscription via an e-mail view mode - simplenews does this I think. When rendering content for a newsletter, you would probably want to remove a newsletter sign-up element, but probably different things to what you'd remove for search indexing otherwise.

Proposed resolution

I can see how we could do this if all prop content is in entity fields (such as the 'field union JSON' model from #3440578-80: JSON-based data storage proposal for component-based page building → ), because we already have a model for configuring how those are displayed in different view modes. Although it would still need some work specific to 'field union JSON' fields because each delta could be a different union, and hence use a different component/formatter - but the data would be equally available regardless of which view mode you're in.

I have no idea how it would work with the current XB data model, because the 'static prop' data is all in a single field value (JSON blob), and that single field value holds content that is specific to a view mode. We would need to provide a way for experience builder to configure rendering that data in a different way - but it's arbitrary what data is in there.

User interface changes

🌱 Plan
Status

Active

Component

Data model

Created by

🇬🇧United Kingdom catch

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

Comments & Activities

  • Issue created by @catch
  • Comment 2 months ago →
    🇬🇧United Kingdom catch
  • Comment 2 months ago →
    🇬🇧United Kingdom catch
  • Assigned to effulgentsia
  • Comment 17 days ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Thank you for opening this hyper-critical issue!

    Since ✨ JSON-based data storage proposal for component-based page building Active was proposed by @effulgentsia, I think it'd be helpful to read even just a high-level take on how @effulgentsia imagined this would work 😇🙏

  • Comment 16 days ago →
    🇬🇧United Kingdom catch
  • Comment about 3 hours ago →
    🇬🇧United Kingdom catch

    Replying to @lauriii from 📌 Refactor the XB field type to be multi-valued, to de-jsonify the tree, and to reference the field_union type of the prop values Active .

    I believe there should be an easier way for managing the challenges related to the search indexing.

    Do you have any concrete proposals for this? The use cases have been identified for several months now, and I do not believe any alternative way to do it has been proposed. Neither for Experience Builder itself, nor examples from other content builders - other than ones that have no concept of this whatsoever and require custom templates to be written for each alternative rendering.

    In the meantime, more and more cases continue to be identified, which all currently rely on very similar concepts.

    So far:

    1. Optional fields that later need to be incorporated into other view modes.

    2. Custom teaser text. that doesn't appear in the main content.

    3. Search indexing - both core search module and search_api. Search API has over 120,000 installs.

    4. Newsletters via simplenews - simplenews has over 20,000 modern Drupal installs.

    5. Alex Pott's German content audit module

    In Barcelona I brought up the case of wanting the show the first four (or however many) components of an article in a newsletter with a link to read more. iirc the alternative solution to this was for the site builder to create two content slots, one for content that would appear in the newsletter teaser, one for content that wouldn't. This requires the site builder to know in advance of building their entire site that they will need to do this. It also prevents them from being able to increase or decrease the amount of teaser content later because it would be baked into the content model itself.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024