Include detail pages for Markdown Contents

Created on 30 August 2023, over 1 year ago
Updated 31 August 2023, over 1 year ago

Problem/Motivation

Since we will change the display of entries on the list page to a simple teaser view, we will need to implement detail pages for our Markdown Contents, just like Drupal auto-generates them for our Entity Contents. We will, however, need to manually create and fill these Markdown Content pages.

Steps to reproduce

Proposed resolution

Create pages based off of the delivered Markdown data at some point in the code. We should discuss first on how to implement this.
, the ones that we actually removed purposefully in a previous issue... haha

Remaining tasks

User interface changes

API changes

Data model changes

Feature request
Status

Closed: won't fix

Version

1.0

Component

User interface

Created by

🇩🇪Germany lrwebks Porta Westfalica

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

Comments & Activities

  • Issue created by @lrwebks
  • Status changed to Postponed over 1 year ago
  • 🇩🇪Germany Anybody Porta Westfalica

    This isn't needed, I think. We should focus on Accordion and all contents on the overview page for now.

    Alternatively, we'll use a tree view on the list page. Having separate pages for the wiki entities is just a benefit from Drupals Entity logic, we got for free.

    The reason behind is, that we still need search functionality on full contents on the central page and we shouldn't put too much effort (=money) into this module!

    So what works well and smart, is enough here. Instead, we could for example use URL anchors (#entry-id-123) and JS. But that's a different issue. Postponing this for now, probably close won't fix one day...

  • Okay, if a 'single page' solution is the plan here.. I vote against Accordion. Accordion fails with very long contents, horrible UX. Clicking trough entries would result in a animated nightmare, a probably thousands pixel height pane collapsing, another thousands height pixel pane expanding.. meh.

    I think we need some kind of a "vertical tabs" menu on the left (first entry initally opened).

    Another consideration is the performance, if we have many images and videos, we need to ensure those are lazy loaded. Otherwise this thing will fail very quick. I'd vote for Ajax, but we can solve this later.

  • Status changed to Closed: won't fix over 1 year ago
  • 🇩🇪Germany Anybody Porta Westfalica

    Yes, totally agree with #3.

    Accordion is just an example and could be a first step or alternative (setting).

    What's clear is, that a singe page solution is the way to go here, I think, for various reasons given above. Next step would be to

    1. Understand the users and our needs for the overview page (expectations) and the different ways of navigations used to find what you're looking for (search, tree, grouping, ...)
    2. Draw a wireframe and present the benefits and needs / problems solved
    3. Implement the functionality

    I'll create a new task for that. Closing this one?

  • Yes, I'll create an issue for the navigation solution!

Production build 0.71.5 2024