Use plugin id to make help section headers HTML IDs

I suggest the following:

- filter the plugin id through clean_id, which converts the underscores to hyphens. Underscores are fine in HTML IDs, but the convention in Drupal seems to be hyphens. (The other ids on h2s in admin/help use hyphens.). So,

<h2 id="{{ plugin.getPluginId()|clean_id }}">{{ title }}</h2>

- For better theme dev UX, I agree that adding a preprocess function so that we can use plugin.plugin_id instead of plugin.getPluginId() would be better.

@andypost Thoughts? Do you want me to attempt a patch for you to review? Or would you prefer to do the patch and have me review?

I took the patch @andypost created and manually made changes to the appropriate files, since hooks have since been moved out of .module files. I also applied my own suggestion to use the clean_id Twig filter to be consistent with the hyphenated HTML ID attribute naming convention and to ensure the plugin ID works as an HTML ID attribute. (That Drupal Twig filter must exist for a reason, right?)

Note: The MR updates template files in 4 locations:

1. The Help module's help-section template (the default template for themes)
2. The Umami installation profile (Classy base theme)
3. Claro admin theme
4. Stable9

So, to thoroughly test, navigate to admin/help and click on any topic. At the top of the page, click the link in the sentence, "See the Help page for more topics" and you should go to /admin/help#help-topics.

On admin/help, inspect the HTML of the section headings (the h2s) and they should all have an ID attribute with the hyphenated name of their help section plugin, e.g. Topics should have an ID of help-topics; Module Overviews should have an ID of "hook-help". ("Getting started" won't have an ID on its H2 as it's not a Help section plugin.)

Do the above inspection for different themes, like Claro and Olivero (I have done this locally). If you want to be super thorough, install Drupal with Umami locally and check out this issue fork. (I have not done this yet.)

Removing "Needs tests" tag because we already have a test for this; it just needed updating.

Looks like more tests need updating, from a quick glance at the failed pipeline.

I've updated 2 assertions that were looking for h2 headings and were missing the id attribute that we're adding with this MR. Tests are now passing, and this is ready for review.

Believe there is 1 open thread if someone could answer that.

I replace the usage of plugin with plugin_id.

@andypost does this still need UX review? My understanding is it's just adding IDs but not chaging the actual headers?

Urgh this is going to clash with the conversion of help tests to Kernel tests :(

Usability review

We discussed this issue at #3585350: Drupal Usability Meeting 2026-04-24. That issue will have a link to a recording of the meeting.. The attendees at the usability meeting were @benjifisher, @pallavi singh3013, @rkoller, @simohell, and @worldlinemine.

In general the group agreed on the issue, it is a good thing to add IDs to the headings available on /admin/help - the issue looks good to go.

The only detail to note, those links seem not necessarily directly actionable. First the user has to know that this page has those IDs added to the headings - for most people that fact can go unnoticed. Then users knowing that IDs got added to the headings have to open the devtools to look up the exact ID in question (in particular with small working memories) and then append the link to the current url so they are able to forward the link to someone else. Those anchors are sort of in lack of a touchpoint to the user in the front end.

So the group wondered about something that is totally out of the scope for this issue, but suitable for a followup issue, if it wouldn't be a good thing to make those links more prominent to the user by applying a pattern similar to the one used on Github project pages? There when a heading is getting hovered on or getting into focus a chain icon is getting shown in front of the heading. That way the user is able to right click and copy the URL pointing to that anchor link. That would be a pattern not only useful for the help page but for Core in general (for example on nodes - the odds are high that someone wants to point someone else to a particular section within an article).

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

forgot to remove the needs usability review tag.

Should this or #3517299: Convert functional tests in help module to kernel tests be postponed? Would assume #3517299: Convert functional tests in help module to kernel tests since that technically could remain functional.

Can the remaining tasks section be cleaned up, if discussion is no more we could probably mark this one as it's working.

This is going to horribly break the MR for the test conversion, because that moves files.

@joachim it's 3 test assertions - nothing is going to break horribly and it'll be fine to merge.