Problem/Motivation

From #2920309-102: Add experimental module for Help Topics item B... Someone at the DrupalCon conversation about this module asked:

How are related topics ordered? Is there a way for someone to modify that order?

My response: Currently there is just "Is this topic top-level?" and if so, display it alphabetically on admin/help. So, right now, the only thing a site owner can modify is "is the topic top-level".

However, any particular site could conceivably use a Menu to make a hierarchical/ordered list of topics. We could add that as a feature, but given that help topics come from multiple modules/sources, I'm not sure it would make sense or how it would work? Maybe we should just add something to the help topics about making a help system and suggest using regular Menus to make a hierarchy if that is desired? We could presumably also facilitate this by making a Block visibility criterion of "Show or hide this block on all help topic pages"?

This issue is to discuss what we should do, and/or do it.

Proposed resolution

Not sure yet.

Remaining tasks

TBD.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

CommentFileSizeAuthor
#12 Screenshot 2023-05-09 at 11.37.23 AM.png137.19 KBmindewen

Comments

jhodgdon created an issue. See original summary.

andypost’s picture

Interesting, menu link plugin is nice idea
Layout builder already can order sections so this could be used

I bet that extra block condition to hide/show blocks is not needed because we could have all topics on /help & /admin/help URLs

jhodgdon’s picture

Title: Facilitate hierarchy and ordering of help topics » Do we need hierarchy/order for help topics?
Project: Configurable Help » Drupal core
Version: » 8.8.x-dev
Component: Code » help.module

Moving this to Core as part of #3027054: Help Topics module roadmap: the path to beta and stable. Also updating the title so it is clearer that this is a "maybe" issue on the Roadmap page.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

Status: Active » Closed (works as designed)

Closing it as there's no reason to bring complexity of hierarchy into documentation

mindewen’s picture

Status: Closed (works as designed) » Active
StatusFileSize
new137.19 KB

Now that this is close to being officially not an experimental module, sites are starting to want to use it to help with internal documentation. A big hurdle to using it is that the topics currently are all in a flat list on the main Help page, intermingled with all the other core and contrib module help topics. Adding some hierarchy and / or ability to organize the topics and navigate them would be extremely useful and I believe would make this module a lot more likely to be widely adopted.

This is what the out-of-the-box topics list looks like. As is, it is hard to read and as the list grows will become even more difficult.

Topics list

What would be very helpful to have (some of these could likely become separate issues):

  • The ability to customize the Help Topics page a bit
    • Group listed topics by site and/or module
    • Add the help search form to the topics listing page
  • Parent/child relationship between topics
  • Add a topic listing block that:
    • Lists parents, children, and sibling topics
    • Customizable block title?
    • Has its own twig template
andypost’s picture

For first stable we decided that having topics searchable is enough, but yes we'll need to deal with hundreds of topics

amber himes matz’s picture

Thank you @Mindewen for your perspective and ideas!

What about enabling Layout Builder integration on for admin/help and provide a default layout which could be overridden by site admins?

- We could make each HelpSection plugin a block, which could be placed in a layout section.
- We add a Topic Category block plugin that creates blocks for each topic plugin prefix's first word and lists all topics with that prefix in that block. For example: book.about, book.configuring, book.creating, book.organizing would be listed in a "Topic Category: Book" block/. This effectively creates blocks for each module's topics, that would then be placed in the layout.
- These blocks (the 3 HelpSections-as-blocks and the Topic Category blocks would be placed in layout sections at admin/help for a default layout that is shipped with core.
- As contributed modules are enabled, their topics are enabled, a new topic category block is created, and it is either placed automatically in the Topics HelpSection. There would need to be a layout section designated as a catch-all for newly enabled modules. Or something.
- This default layout could be overridden and blocks re-arranged as desired.
- The admin-help layout could have a corresponding layout twig template that could also be overridden and customized by the site owner.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

I have a client project where we're using this for internal documentation, but because we're only using it for internal documentation I just altered out all of the help topics that aren't provided by our custom module. This was an extremely brute force approach but so far was all we needed.

We add a Topic Category block plugin that creates blocks for each topic plugin prefix's first word and lists all topics with that prefix in that block. For example: book.about, book.configuring, book.creating, book.organizing would be listed in a "Topic Category: Book" block/. This effectively creates blocks for each module's topics, that would then be placed in the layout.

So to take book, if I had a contrib module called book_plus, I could do book_plus/help_topics/book.plus.html.twig and it would then show up in the 'Book' section?

One problem with this would be that system module's help topics currently have 'system' has the prefix, but they would probably need to be moved into different categories.

I'm wondering if we should add a 'category' to the front matter rather than relying on the prefix? So you could have 'User management' 'Regional and translation' a bit like the system admin sections?

andypost’s picture

As we have fields "categorized" it looks like good idea, IIRC there was some discussion to add kinda Tags

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.