External libraries link broken in status page

Added a small patch for fixing the closing tag, and added in unique IDs for the rows generated in the help page (including the missing "libraries" fragment).

Those look to me like changes that should each have their own commit.

I actually wrote one commit for each, but the diff put them in one patch. Should I separate them into two patches?

This issue seems to be just about the missing closing tag. Perhaps the first two hunks of the patch should be in their own issue or at least make a separate patch and clear comment about what it does. Thanks!

Alright, to make it a bit more clear, I just adjusted the summary which would encapsulate the current patch, which overall is "the external library link is broken - the tag is broken, and it points to something that doesn't exist" and this patch fixes both of those. Hopefully that works and is a bit more succinct in describing what is fixed.

I have added the missing closing tag. I need more time to look at the other part of it.

The first hunk should probably use ::getUniqueId() and perhaps also a prefix to ensure a unique value.

Why does the second hunk add attributes? None of the other ones have that.

For the first hunk, it is using the array key that is assigned to each row in protected function initVideos() (also used for the keys on groups in protected function initGroups()). But yes, it would be possible that when new sections are added, the array key is missed being added and it could be missing.

For the second hunk, the difference is between the array being rendered through Url::fromUri (see below) where we have to declare the attributes to assign the ID that a fragment could scroll to, versus in the first hunk it is being rendered through a table theme function.

$link['url'] = Url::fromUri($link['url']);

I'll be honest, even though this would semantically be correct to add IDs to the group sections that could be scrolled to using a link fragment, it doesn't actually work because the groups are in that scroll box controlled by the search filter input, so the page does not actually scroll down to the targeted group. This is probably just an artifact of how it was originally built, but ideally it would be value that the search box picks up as a default filter value if passed through the URL, but that would be a net-new feature.

This sounds like a bigger change to that page, best seen as a new feature request. The part already committed is clearly a bug. I'll close this ticket because that is fixed. Please make a child ticket if you want to continue this. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.