Deprecate hook_help() and combine with Topics

Is there an issue somewhere for the help block help, or is this that issue?

I bet this issue is about to deprecate the hook_help() and the help block (help sections are rendered via \Drupal\help\Controller\HelpController::helpMain()), gonna hack on it

Yes, help block needs own issue

First child issue is done, so now waiting to consider help topics stable

Updated issue summary.

This issue will be meta is we consider it actionable, still not clear how properly transition from requiring help topics instead of hook help

The core's kill-switch for documentation gate in 📌 Move testing of help topic rendering into child of GenericModuleTestBase Active (I re-parented it)

FWIW, I tend to use hook_help significantly to document the specific behaviors of modules on various pages. The important point here is that this kind of help is contextual and may contain live data. See for example https://git.drupalcode.org/project/g2/-/blob/8.x-1.x/g2.module#L305 where the help text is complemented by arguments from the current context.

A nice workaround could be if help topics could receive a context provided by some service, maybe defining injection in the frontmatter.

A nice workaround could be if help topics could receive a context provided by some service, maybe defining injection in the frontmatter.

I imagine @fgm is not the only one to need this. Sounds like "Allow help topics to get context defined in frontmatter" should be opened as a child issue of this one? @fgm do you want to open the issue, or should I? In either case, I'm interested in more details as to what you are looking for, and if you could provide examples of your modules that use context in their hook_help() implementations. Thank you.

@Amber Himes Matz after converting help in G2 help to Help Topics (see https://git.drupalcode.org/project/g2/-/blob/8.x-1.x/g2.module#L305 for the original version, and https://www.drupal.org/files/issues/2023-08-20/3382138.patch → for the converted version, still under review) I'm no longer convinced this is so much needed: a single helper providing access to a \Drupal instance would enable access just about any service by calling all \Drupal static methods as instance methods on that instance, and specifically \Drupal::service()` thus enabling advanced templates to access just about any service without making the frontmatter more complex.

Still think this is worth a followup ?

Looks it need another yaml file to maintain "binding" of topic to routes and paths at least, like menu system doing for local actions and tasks.

Other option is contextual module in core which is also using ContextualLinks render element and manager with alter hook