Standardize the list entry display between entity and markdown content

Created on 25 August 2023, over 1 year ago
Updated 5 September 2023, over 1 year ago

Problem/Motivation

We are currently rendering all the entity contents through the ProjectWikiEntityContent view builder, which defines the looks on how the base field definitions have set their 'view' display options. Meaning, the complete entity with every field is rendered through
the ProjectWikiValueObject's "content" property (which is desired).

The problem is, that this "content" differs from the "content" of markdown contents, leading to duplicate attributes being rendered (like category) for entity contents, but not for markdown contents.

Steps to reproduce

Proposed resolution

Standardize how both contents are displayed through "content".

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Fixed

Version

1.0

Component

Code

Created by

🇩🇪Germany Grevil

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

Comments & Activities

  • Issue created by @Grevil
  • 🇩🇪Germany Grevil

    If this issue seems unclear, postpone it for now.

  • 🇩🇪Germany lrwebks Porta Westfalica
  • This issue is more about the provided data for the Twig templates, not about the User Interface, "Code" should be fine here.

    In a perfect solution, both types of Wiki entries, should use the same Twig file, with the same content-variables, I guess.

    But I am also fine with having a seperate Twig file for the MD contents and the entity contents, it this makes things easier and probably cleaner on the backend side. We could simply let the MD template inherit from the other one and just replace the variables.

  • 🇩🇪Germany Anybody Porta Westfalica

    In a perfect solution, both types of Wiki entries, should use the same Twig file, with the same content-variables, I guess.

    Absolutely! That should be our goal here! (And it was supposed to have been don that way). By using the same twig file or at least inheriting from the same one.

    Also see https://www.drupal.org/project/project_wiki/issues/3384205#comment-15212970 Include detail pages for Markdown Contents Closed: won't fix

  • Assigned to thomas.frobieter
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica

    @thomas.frobieter I think the basic idea here, standardizing the output is still correct! So I'll leave this open.

    But the key task is this one: 📌 [META] Implement wiki overview as single-page Active

  • 🇩🇪Germany Grevil

    In a perfect solution, both types of Wiki entries, should use the same Twig file, with the same content-variables, I guess.

    They both do! Maybe the issue summary wasn't clear enough.

    Inside the twig template file (which is used by both types of wiki entries), we render the "content" of the wiki entry:

          <div {{ content_attributes.addClass('project-wiki-entry__teaser') }}>
            {{content}}
          </div>
    

    Which is provided by the ProjectWikiValueObject 'content' attribute. Both Markdown and Drupal entities are parsed into an ProjectWikiValueObject, before getting rendered through the twig file.

    But of course, the parsing methods from both Wiki Entry types are different. The 'content' of the ProjectWikiValueObject parsed by the Drupal Entity goes through Drupal's view builder before assigning it as 'content' and the markdown entity simply uses its HTML output as 'content'. This leads to different rendering outcomes of "content" inside twig template.

    Meaning, that for the Drupal entity the rendering outcome of "content" is based on how the entity's basefield definition defines its fields "view display". For example, inside the twig template we have this code:

        {% block entry_teaser %}
          <div {{ content_attributes.addClass('project-wiki-entry__teaser') }}>
            {{content}}
          </div>
        {% endblock entry_teaser %}
        {% block entry_metadata %}
          <div class="project-wiki-entry__metadata">
            <div class="project-wiki-entry__metadata-item">
              <span class="project-wiki-entry__metadata-item-label">{{ 'Category'|t }}:</span>
              <span class="project-wiki-entry__metadata-item-value">
                {{ category }}
              </span>
            </div>
    
    

    For a markdown entry, this looks fine, but since our drupal entity might have a view display definition for "category", "category" will be rendered through both twig entries "content" and "category", leading to duplicate entries.

    Rendering the content through the view builder was wished by @Anybody, to harness the power of Drupal's field view configuration. So if we want to fix this, there are multiple approaches:

    • Kill the view display of fields in the Drupal entity's base field defintion which are rendered inside the twig file seperately (category, title).
    • Use its own display type for viewing the drupal entity.
    • Do not render the content through the view buiilder.
  • For a markdown entry, this looks fine, but since our drupal entity might have a view display definition for "category", "category" will be rendered through both twig entries "content" and "category", leading to duplicate entries.

    In case of the Drupal entity, we only need to remove the categories field from the content render array (we can do this using the Twig without filter, or probably by unsetting the field in PHP), so its not printed twice (the Entity title should already be seperated by default, so it shouldn't be included in 'content').

    We simply need to provide all important fields (or lets say, all fields used by MD & Entity entries) as a custom variable for twig (like 'category') and determine its value in PHP.

  • 🇩🇪Germany Grevil

    My solution would've been to simply remove the category display view from the drupal entity's basefield defintion. That's why this was originally assigned to @LRWebks, since the fix is quite ez.

  • 🇩🇪Germany Grevil
        $fields['category'] = BaseFieldDefinition::create('string')
          ->setLabel(t('Category'))
          ->setDescription(t('The category that this entry fits in (leave blank for no category).'))
          ->setDisplayOptions('form', [
            'type' => 'string_textfield',
            'weight' => 0,
          ])
          ->setDisplayOptions('view', [
            'type' => 'string',
            'label' => 'inline',
          ]);
    

    Just remove

          ->setDisplayOptions('view', [
            'type' => 'string',
            'label' => 'inline',
          ]);
    

    and that's it. Only problem would be, that we wouldn't see the category of the entity in the normal entity view mode. That's why I suggest using a different view mode for rendering the entry on the project wiki list.

  • @grevil Okay, lets have a look at this together later on. I need to have a quick look on the content structure.

    Can you please prepare this (dsm(content) in an MD entry and an entity entry) and then let me know?

  • 🇩🇪Germany Grevil

    Just discussed this internally with @thomas.frobieter, and we'll fix this as mentioned in #11.

    • Grevil committed e07707a7 on 1.x
      Issue #3383438 by Anybody, thomas.frobieter: Standardize the list entry...
  • Status changed to Fixed over 1 year ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024