- Issue created by @Grevil
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
@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.
- Status changed to Fixed
over 1 year ago 7:29am 5 September 2023 Automatically closed - issue fixed for 2 weeks with no activity.