Add links to Drupal.org project pages to module listings in /admin/modules

+1
Adding link to the project page on d.o would be a very simple way of alerting users that there are additional resources and an issue queue.

However I would only add one link to the project page, using the default wording that we also use for the link on the help page. That way users can find documentation, modules that work together as well as the issues

Linking directly to the issue queue however would probably result into users flooding the issue queue with support requests, so for now I would rather leave the issue queue that one step removed.

We'd have to figure out how to direct folks to the project page, even for sub-modules of a project. This is not inherently obvious, but a lot of modules are nested inside of a project as a sub-module. The link would need to be do the project page, not the module's page.

Re-titling.

@heddn good point. I started working on a patch that relies on regex to get the module name. Should be ready by tomorrow.

As a starting point, the patch supports only contrib modules from D.O by using the key "project" from .info.yml file. For other modules, maybe we can add extra data to .info.yml file but this should be discussed first, I guess.

Here is a first shot.

@tarekdj - Thanks for the patch in #8. Remember to set the issue status to "Needs Review".

The patch changes files in the Stable theme (adds an icon, updates a template and CSS). However changes to Stable (and Classy) theme are not normally allowed. To make this work, I think we need to make the template changes in System module and in the Seven theme. Something like this:

• Add the home icon to core/misc/icons.
• Do not add the icon to the Stable theme.
• Update the template in System module (as you have done).
• Clone the template to the Seven theme.
• Make CSS changes in the Seven theme.

Tagging for Stable and Classy theme maintainers in case they want to make an exception. :-)

Note: I haven't reviewed the logic in ModulesLIstForm.php - I'm working on a mobile phone, so that's a bit tedious. I just skim read the changes and looked at which files are affected. Someone else please review the ModulesListForm logic?

Thanks for this.

I think we can get around having to change the theme files, because there is an issue to get rid of those icons anyway and rather have a dropdown list for the links because on a small screen there is no way what so ever to get to the links: #2574721: Provide access to action links in the modules page on small screens

About the wording: This should be "online documentation" instead of "Module's homepage" because that is the default wording we use for the same link in the help texts. "For more information, see the online documentation for the Foo module."

Hi @ifrik

Here is a patch with changed wording

IMHO, I find "Module's homepage" better than "Online documentation". I'd actually prefer "Project page" over the first two. Of course, it would be nice to include "online documentation" in title attribute for the link.

The reason I think online documentation is not the best way to word it is because it does not link to the online documentation. Clicking on "online documentation" and landing on project page would be annoying (for me, at least). If we say "online documentation", we should link to the documentation that's available for some modules (accessible from sidebar on project page). Of course, we can't get that link without an API call, and I don't want the scope of this issue to expand to that.

I understand the reasoning in #11 but I'd point out that in the help text where it is written as "online documentation", it actually points to the documentation. Also, there is no such text for contrib modules help entries out of the box.

Hi,

looks like there's lots of bike shedding potential on the wording here :-)
Let's keep it simple and consistent.

Project: We don't use "project" in the UI, even though it is in the path on d.o., but so are themes etc there. Using "project" here would introduce a new term without need for it, so that's not such a good idea.

Module: The UI text on the Extend page still refers to "modules" but the page itself got renamed, based on the assumption that users wouldn't know what they are. So we can use that, but "home page" sounds a bit weird since in most cases this will link to a page within d.o.

"Online documentation": That should include any kind of documentation that exist about a module: Dependencies, changes between versions, known issues, and explanations on how to use the module (the part that sometimes, but not always is also called "documentation". This all can usually be found from the project page on d.o.
The help text standard, is supposed to link to this page with the "online documentation" link, and the related test test for this specific wording. This standard also applies for contrib modules.
For core modules we also use this wording - but then we ran into the problem that core modules don't have their own module pages, so we had to resort to finding an other page to link to. (In some cases like Views UI, that really only a stub unfortunately).
So, if we use "online documentation" we can bring people to the same page with the same wording that should ideally be used on the help page, and from there they will find anything else.

What about using composer.json's "support" section which allows for custom URLs for issues and docs. This would solve the issue of supporting sub-module and different documentation versions.

Also by allowing modules and themes to specify the desired homepage and documentation, we are taking into account that some projects are not being hosted on Drupal.org.

Personally, I think we should use composer.json's homepage and support settings to create dropdown menu that allows for a project maintainer to specify any of the following...

• homepage: An URL to the website of the project
• email: Email address for support.
• issues: URL to the issue tracker.
• forum: URL to the forum.
• wiki: URL to the wiki.
• irc: IRC channel for support, as irc://server/channel.
• source: URL to browse or download the sources.
• docs: URL to the documentation.
• rss: URL to the RSS feed.

I am willing to bet in D9, we will be replacing module.info.yml with composer.json files.

Agree with using composer.json's support section, with one caveat: can we make it work for Drupal core modules also? This feature is just as needed for core modules (if not more needed, since core modules are already there so people can't even remember/ask where it came from and look for documentation there), and core modules should set a good, follow-able example.

Closing #857090: D8 Modules' page: Add links to module help, project page + merge operations links to one cell. and #1191084: UX: Link Module Names to Drupal.org as duplicates of this. Adding credit from those issues here.

This is a great idea. Do the points you make in #10 still stand @andrewmacpherson?

Whoops. I've been working on #3012004: Add a link to the module's drupal.org project page in the module admin page, and just found this issue, instead. Since this is older and has more participants, moving progress here. For starters, here's the latest patch from 3012004, which only deals with the project page link. I'm not convinced a direct link to the issue queue is the right approach here. No interdiff, since it's a brand new patch. Supports Claro, too.

Crediting @joachim, too (author of the original patch in the duplicate issue).

Based on an enlightening Slack chat with @andrewmacpherson about the now duplicate #3012004: Add a link to the module's drupal.org project page in the module admin page, I opened #3245622: Module name context missing for 'help' and 'permissions' links on admin/modules about adding some more context to these links for folks using screen readers.

Meanwhile, I'd like to carefully review what's already in here and see if the two patches should be more thoughtfully merged. ;)

Also, the suggestion from @andrewmacpherson was to make the non-visual context a bit less verbose here. Working on that now.

Here's the less verbose link context.

Done reading through this issue more closely...

Definitely don't need/want to touch classy or stable* for this, per the current patches. Removing those tags.

Re: composer.json - as appropriate as all that would be, even #3005229: Provide optional support for using composer.json for dependency metadata still isn't done, much less are we requiring a composer.json. Probably D10 material at this point. So I don't think we should be relying on that here.

Re: "project" - yeah. 😉 It's a loaded term. However, as @andrewmacpherson pointed out in Slack:

I don't think the word "project" is redundant. If it just said "Drupal.org page for Webform", the link would be a bit ambiguous. There are handbook pages, as well as project pages.

This echos the sentiments in #13 that calling this a link to "online documentation" would be misleading at best.

The proposal in #3228567: Decide on consistent naming for future core modules that implement Automatic Updates and Project Browser functionality is to call these things "packages" not "projects", but that's not decided or done. I think "Drupal.org package page" would be even more confusing and weird. I'd think that'd be a release node or something with release notes. Naming Is Hard(tm).

Re: Core - I don't see any reason to try to hide these links for core modules, or to worry about doing anything fancy with submodules. In each case, if the .info.yml file defines the right project key, each (sub)module will get a link to the right project page. If the project was installed from d.o, the packaging script inserts the right project. If you're using Git clones or composer to checkout -dev releases, you need another solution for this problem already if you want the Update manager to work (which also depends on a project key), and you're using something like git_deploy or the fancy composer plugin that rewrites your .info.yml files for you (whatever that's called).

Yes, It'd Be Nice(tm) to support things that don't live on d.o. But I think to do that properly, we'd need to either finish #3005229 and switch to composer.json for all this stuff, or we'd have to introduce new .info.yml keys. The former is a good idea for lots of reasons, but in progress, and not going to be done anytime soon. I believe the later isn't wise in the short term, since "no one" would be defining this key properly, and this feature wouldn't immediately start working for the vast majority of projects (like it does now).

That said, maybe tying this so tightly to Drupal.org (with the icon and link title, as we were doing in #3012004: Add a link to the module's drupal.org project page in the module admin page and now in the latest patches here) isn't wise, either. So, maybe we should keep using the house icon (per #8 / #12) and call the link "Package home page". Although that still sounds more like a link to releases notes or something (IMHO).

Anyway, I don't think there's anything else from patch #12 that should be merged in here (unless we return to using house.svg for the icon). I'm definitely not sure on the right wording here, so I'm tagging for usability review and moving back to NR.

Sorry, forgot to fix the title. Per my previous comments:

• This should work for core, too. Removing "contrib".
• Multiple folks in here (myself included) expressed doubts that direct links to issue queues are desired, so removing that, too.

Per #3228567-13: Decide on consistent naming for future core modules that implement Automatic Updates and Project Browser functionality, maybe the link text here should be:

Extension home page [for @module_name]

?

The proposal in #3228567: Decide on consistent naming for future core modules that implement Automatic Updates and Project Browser functionality is to call these things "packages" not "projects", but that's not decided or done. I think "Drupal.org package page" would be even more confusing and weird. I'd think that'd be a release node or something with release notes. Naming Is Hard(tm).

Let's stick with the word "project" ("Drupal.org project page"), the term "project" refers to everything that makes up a module (D.o project page, issue queue, download bundle, etc), whereas the "packages" is specifically the code that is "packaged up" and shipped through Composer. So sticking with "project" in this context makes sense.

Absolutely. Hard +1 on "Project home page for [...]"

"Project home page [for @module_name]" sounds good. And then we can use the house icon instead of drupal-logo (which is probably safer/better, anyway). I'll work on all that now, stay tuned.

- Change link text to "Project home page [for @module_name]" (the part in [] is visually-hidden).
- Change icon from drupal-logo.svg to house.svg
- Update screenshots in the summary (both Seven and Claro)

I like it! "Project home page" is also good as a more generic term for custom distros that maybe want to modify where that goes for their modules.

Added test coverage for the new link. No "Needs tests" tag needed. 😉

Grrr, I was afraid that might happen:

----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
 1 | WARNING | Remove "project" from the info file, it will be added
   |         | by drupal.org packaging automatically
----------------------------------------------------------------------

There's a work-around. I'll deal with it later today.

Sorry, got really busy at $day_job yesterday. Here's the test fix.

Also, cleaning up a few distractions in the issue summary in anticipation of the UX review.

Fixing typo in the summary. Hoping to get this reviewed as part of #3265255: Drupal Usability Meeting 2022-02-25.

We reviewed this issue at #3265255: Drupal Usability Meeting 2022-02-25.

There was general agreement that this is a positive change.

A few minor tweaks were suggested and agreed by the group:

1. We recommend to remove the word "home" from the link text, simplifying it to just "Project page", we felt that this still conveyed the meaning of the link while keeping the text concise.
2. We recommend changing the icon from a "home" icon to an icon which indicates this is an external link. We noted that Drupal Core does not yet have an agreed external link icon, this is something that is being considered as an addition to Claro and the Drupal Design System, so we were happy to have this change postponed to a follow-up issue until the icon is available. Until the icon is available we were happy that the "home" icon can stay as is. We did however note that a home icon does often refer to a site's own homepage, so we felt that this change also helps avoid the potential for conflation.
3. Similar to the above, we recommend to add the text " (external link)" to the end of the visually hidden span, to help indicate that this link goes to an external site - "Project page for X (external link)".
4. While not strictly a usability point, we did note that in the future once the project browser is in core, it is possible that this link might go to the project page within the project browser itself. We recognised that if that happens it means some of these recommendations would no longer be applicable as the link would then become an internal link. We did note that creating a postponed follow-up issue would be useful to consider that change when the time comes.

Since the three other links that sit next to this one (Help, Configure and Permissions) go to internal pages in the site, we felt it was important to distinguish that this link goes to an external site, we are happy that the recommendations above achieve this.

While setting up for the UX meeting, I also noticed that the patch does not apply to 9.4, it does apply to 9.3 though.

I'll do a reroll for 9.4 and work on #47

Sorry, I changed the status unintentionally.

Here is the reroll patch.

Regarding #47
1. Done
3. Done
Points 2. and 4. need follow-up issues.

Sorry, I sent the wrong files. Here are the right ones.

I didn't see an extra space 🤦
New patch...

For the record, the attendees at today's usability meeting were andregp, Antoniya, AaronMcHale, ckrina, bnjmnm, kimberlly_amaral, worldlinemine, victoria-marina, tmaiochi, rkoller, shaal, and me.

The issue for the meeting (link in #47) will have a link to the recording and a transcript.

Quick patch review:

1. The CSS class module-link-homepage should probably be something like module-link-project-page.
2. Similar to the above, I would change the link key from $row['links']['homepage'] to $row['links']['project_page'].

From a closer look at the patch, I notice that it is actually introducing the "house" icon, during the UX meeting we assumed that the house icon was already present. In that case it might make sense to actually introduce the "external link" icon as described in #47.2. I will ping Cristina in Slack.

Thanks @AaronMcHale! I think we shouldn't introduce an icon for later switching it. I'm attaching the external icon we discussed during the call: I've adapted it to 16px from a free of license icon.

The reason behind using this one and not the house is because the house can be misleading to whoever is running a Drupal site: we know drupal.org is the "house" for Drupal, but the house is usually understood as the homepage for the current site. A drop as an alternative might not make sense for a lot of people too. The external icon, on the other side, is an industry standard and a bigger percentage of users will understand its meaning. To note too that the behavior won't rely on the icon only because it shouldn't be forcing an external link, so not understanding the icon meaning shouldn't be a big deal. It is better explained on the UX recording mentioned in #47.

Thanks so much for the UX review, suggestions and follow-up patches.

Re #56:
The 2 points on variable names: totally agree. I was gonna say the same. All those things where named when this was “home”-specific.

However, no, the patch is only introducing 1 more copy of the existing house icon in the right shade of blue for Claro’s hover state. The house icon is already in use in core.

But sure, I hear the points that an external link arrow would be a better icon.

If we’re going to do the external link icon, wouldn’t that icon’s alt text provide the non-visible clue that y’all proposed to include in the hidden link text? Would that not result in duplicate info? My understanding from previous accessibility reviews and discussions is that the best solution generally is to make the links the same for everyone. The hidden text thing is less evil than nothing, but silo’ing users is not ideal. Trying to channel my inner @andrewmacpherson. 😉 But I really don’t know. I think we should get the accessibility experts to weigh in on this point before we RTBC this. Tagging as such.

Thanks!
-Derek

P.s. re #47.4:

once the project browser is in core, it is possible that this link might go to the project page within the project browser itself.

Everything else made sense, but this does not. 😉 the only way these links appear on admin/modules is if you already installed them. Project browser is designed to help you find and install new stuff. this issue is about helping you find issues and docs for the stuff you already installed. I think it’d be a major UX wtf if I installed something, then was presented a link back to how to install it again. Furthermore, we’re going to want to keep the browser UI focused on helping you decide if you want to install it, not helping you navigate information once you’ve already decided and installed it.

Finally, if we changed these to point to PB, they’d no longer be external links and the whole discussion around icons is reopened.

Everything else made sense, but this does not. 😉 the only way these links appear on admin/modules is if you already installed them...

Yep totally appreciate what you're saying there, the specific point on the PB was my suggestion, and it was based purely on the assumption that PB project page would be similar to the D.o project page, however until the UI has actually been signed off we won't know for sure, and who knows how having PB in core will change the D.o project experience in the long-run. So it sounds like there are just too many unknowns at the moment to even consider that, so let's not bother opening a follow-up for that one. I'm sure if it makes sense at some point in the future than we can revisit it.

However, no, the patch is only introducing 1 more copy of the existing house icon in the right shade of blue for Claro’s hover state. The house icon is already in use in core.

Ah right okay that was a misunderstanding on my part then.

If we’re going to do the external link icon, wouldn’t that icon’s alt text provide the non-visible clue that y’all proposed to include in the hidden link text? Would that not result in duplicate info?

From looking at the patch, it looks like the icon is added as a background image and so it wouldn't have alt text, right?

Okay, I'm working on this. I'll add the new icon and improve the wording.
@AaronMcHale, yes, I checked by looking at the other icons for comparison and the icons don't have alt text.

Here is the patch :)

I think this is almost ready, but it just occurred to me that we'll need an update hook to clear the cache, otherwise the icon won't show up initially.

Edit: not the entire site cache, just rebuild the CSS for the active admin theme.

This is a nice improvement, so thanks for working on it. It looks like the project link is only shown if the module is enabled. I would think that it would be quite useful to be able to research also non-enabled modules ...

Addressed #63 & #64.
Added an interdiff as well.

Perfect @yogeshmpawar, modules which are not yet enabled now also have links. Thanks!

Thank you for the additional work on this.

Agree with showing the link for modules which are not installed.

It did occur to me that in addition to rebuilding the CSS the template cache will also need to be rebuilt, since we're making changes to template files.

I suspect we'll also need a change record to notify theme developers of the changes to the templates, maybe also for the new icon.

Oh and the update hook comment probably needs to be a bit more general, as that's what shows up in the UI. So something like "Add project page links to modules list."

Thanks @AaronMcHale, addressed #70 & added an interdiff. keeping this issue in NW as it requires change record.

"Needs followup" was added in #51 for #47.2, but we now have the external link icon in here (since #62). Per #59 and #61, we don't need/want a follow-up for #47.4. So removing that tag.

I created the CR about the new icon, so removing that tag, too.

@ckrina re: #57: Thanks for the new icon! Looks good.

@AaronMcHale re: #60: Yeah, sorry, was livin' in the past. ;) No <img> tag, only background via CSS, so no duplicate alt text. Removing the "Needs accessibility review" tag I added in #58. Thanks!

@andregp re: #62: Thanks for reworking this. However, I don't think we want to add the new icon to stable. That's only for the state of front-end related assets from Drupal 8. If anything, we might want to add this to stable9, but I don't think we really want to do that, either. I'm not entirely sure anymore. But here's a patch to at least remove it from stable. If we need to add it to stable9, a committer will tell us. 😉

@ressa re: #64 Good catch, agreed!

@yogeshmpawar re: #66: Thanks for diving in to help, too.

Also refreshed the screenshots in the summary with the new icon, so no need for "Needs screenshots" tag.

After discussing with @dww on Slack, we agreed that an additional change record should be created to address the changes to the Twig template and generally address this link being added.

Drupal modules list will now provide links to project pages on Drupal.org

Setting this back to NW as there's an remaining action from comment #69:

It did occur to me that in addition to rebuilding the CSS the template cache will also need to be rebuilt, since we're making changes to template files.

I'll work on it.

What I did was more like a reroll of previous patches, but without changing any themes.

Fixed Failed commands on #77
Attached inderdiff

Hi, I revised the patch #79 but the issue wasn't fixed and then I will wait for someone else to review to confirm the status change

Verified
https://www.drupal.org/files/issues/2022-07-06/2906547-78.patch

Testing Steps:
* Install a new Drupal instance
* Apply patch using composer
* Clear the all caches
* Go to /admin/modules

Test Results:
It not fix the issue. Link is not getting generated.

Refer SS

Created patch for the 9.5.x dev version.
Please review and verify.

https://www.drupal.org/files/issues/2022-07-12/project_link_9.5.x_dev_tested.patch

Tested locally and its result

Before patch:

After Patch:

On Hover:

Verified for Drupal 9.5.x dev version
https://www.drupal.org/files/issues/2022-07-14/project_link_9.5.x_dev_94...

Testing Steps:
* Install a new Drupal instance
* Open '/admin/modules'

Test Result:
Verified that after applying patch each modules have project which redirect them to drupal.org respected module page. It also shows the project link to uninstall module and core modules too.

To maintain consistency for all module the modules which do not have their own project info link then it will have https://www.drupal.org/project/drupal/ link.

Refer SS
After Patch patch for core modules:

After Patch patch for contrib modules:

Test Result Pass
Someone please review this patch

I have tested and verified patch #94 for drupal version 10.1.x-dev .The patch was suitable for 10.1.x-dev . I think we can re-roll the patch for latest version if we not need to add any additional features. Adding screenshots for the reference of 10.1.x.

+    // Generate link for the module's drupal.org project page, if the info.yml
+    // file declares the project the module belongs to.
+    // Generate link for module's project page, if it has one.
+    if (isset($module->info['project'])) {
+      $row['links']['project'] = [
+        '#type' => 'link',
+        '#title' => $this->t('Project <span class="visually-hidden">@module</span>', ['@module' => $module->info['name']]),
+        '#url' => Url::fromUri('https://www.drupal.org/project/' . $module->info['project']),
+        '#options' => [
+          'attributes' => [
+            "target" => '_blank',
+            'class' => ['module-link', 'module-link-project'],
+          ],
+        ],
+      ];
+    }
+
+    // for those module whose info['project'] value is NULL
+    else {
+      $module_Drupal = "drupal";
+      $row['links']['project'] = [
+        '#type' => 'link',
+        '#title' => $this->t('Project <span class="visually-hidden">@module</span>', ['@module' => $module->info['name']]),
+        '#url' => Url::fromUri('https://www.drupal.org/project/' . $module_Drupal),
+        '#options' => [
+          'attributes' => [
+            "target" => '_blank',
+            'class' => ['module-link', 'module-link-project'],
+          ],
+        ],
+      ];
+    }

These two blocks are almost identical. We could simply have the if statement set the value of the #url, then we would need to duplicate the whole array.

Hi,
I have applied the patch from #94(project_link_9.5.x_dev_94.patch) in drupal 11.x version as the core version has changed to 11.x. So I made the necessary changes regarding the project link and attached the interdiff and the patch file. Please review it.

Thanks for the patch.
Remember to set an issue to 'needs review' when you post a new patch :)

1. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -314,6 +314,28 @@ protected function buildRow(array $modules, Extension $module, $distribution) {
   +      $proj_url = Url::fromUri('https://www.drupal.org/project/' . $module->info['project']);
   

   Variable names shouldn't use abbreviations.

2. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -314,6 +314,28 @@ protected function buildRow(array $modules, Extension $module, $distribution) {
   +    } else {
   

   'else' should not be coddled - should be on a new line.

3. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -314,6 +314,28 @@ protected function buildRow(array $modules, Extension $module, $distribution) {
   +      // for those module whose info['project'] value is NULL
   

   Comments should be in sentence case with a full stop.

4. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -314,6 +314,28 @@ protected function buildRow(array $modules, Extension $module, $distribution) {
   +      $module_name = "drupal";
   

   Drupal, if written in a human-readable text, should be 'Drupal' with a capital.

5. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -314,6 +314,28 @@ protected function buildRow(array $modules, Extension $module, $distribution) {
   +      $proj_url = Url::fromUri('https://www.drupal.org/project/' . $module_Drupal);
   

   I don't see where this variable has been defined. Also, wrong case.

6. +++ b/core/modules/system/tests/modules/system_test/system_test.module
   @@ -79,6 +79,12 @@ function system_test_system_info_alter(&$info, Extension $file, $type) {
   +  // prevent putting it directly into the .info.yml file.
   

   Comment needs to be a full sentence.

7. +++ b/core/modules/system/tests/modules/system_test/system_test.module
   @@ -79,6 +79,12 @@ function system_test_system_info_alter(&$info, Extension $file, $type) {
   +    $info['project'] = 'system_test';
   

   I don't understand what this code is for.
   If we need this test module to have a 'project' key to test it, why not just put it in the info file?

Hi,
I have made some more changes in the code based on #103 and have regenerated the patch again. Please do review it once and let me know.

Code looks good to me and the links work great for a bunch of contrib projects already!

I don't have joachim's eye but i think everything mentioned in 103 has been addressed.

A few notes however, most important first:

1. Projects that do not have an explicit project defined should absolutely not have a project page link. I don't see it discussed anywhere but linking to https://www.drupal.org/docs/extending-drupal/installing-modules for dozens of core, custom, and laggard contrib modules adds visual clutter and will make people less likely to use and get any value out of the useful links. I do not see this discussed anywhere in this issue and consider the introduction a hard no from this reviewer. There simply should not be any Project link if none is available, same as there's no Help, Configure, or Permissions link if any of those are inapplicable.
2. If there is no immediate short-term plan for d.o core modules to take over their namespaces at drupal.org/project/ then i think it is imperative to allow links to other locations, at least on drupal.org. (A project_page option for *.info.yml files that can override building the link based on project, say.) Honestly i think we should allow links to non-Drupal project pages or standalone project websites. (I am make public and contribute on d.o any potentially useful module myself, but we know this feature would be useful for university or large organization deployments with many in-house modules, and other not-on-d.o projects.) All that would be a follow-up issue and maybe should be a separate "More information" link or something. Actually even if we never ditch *.info.yml for composer.json, if we allow more links, we should use the same keys, as jrocowitz outlined, for the non-project page links— or d.o can start parsing the composer.json and including these links on the d.o project page! All that said as long is 1) is done i think we should get this patch in and then figure out the right solution for core and custom projects.
3. It's pretty notable the lack of icon for Project compared to the other links. I think this is supplied by Claro so not part of this patch, but noting this was discussed before in this issue thread and the usability group recommended an icon which indicates this is an external link (as well as adding the text " (external link)" to the end of the visually hidden span). Rather than making the icon before the word Project the "arrow out of box" icon that is usually used after a link to indicate it is external, i would advocate for the old-school globe website icon, 🌐 available in UNICODE and as an SVG here. The globe icon would really help make up for dropping the word "page" or "homepage" from the phrase "Project page" that was initially proposed. Also not reason to hold up this patch.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Hi,
I have made some more changes in the code based on #108 and have regenerated the patch again. Please do review it once and let me know.

1. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -92,14 +92,14 @@ class ModulesListForm extends FormBase {
   +          $container->get('module_handler'),
   +          $container->get('module_installer'),
   +          $container->get('keyvalue.expirable')->get('module_list'),
   +          $container->get('access_manager'),
   +          $container->get('current_user'),
   +          $container->get('user.permissions'),
   +          $container->get('extension.list.module')
   +      );
      }
   

   This indentation shouldn't be changing.

2. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -141,7 +141,7 @@ public function getFormId() {
   -    require_once DRUPAL_ROOT . '/core/includes/install.inc';
   +    include_once DRUPAL_ROOT . '/core/includes/install.inc';
   

   Unrelated change?

3. +++ b/core/modules/system/src/Form/ModulesListForm.php
   @@ -175,9 +175,11 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +      $modules = array_filter(
   +            $modules, function ($module) {
   +                return !$module->isObsolete();
   +            }
   +        );
   

   Indentation being changed.

I'm going to stop there -- it looks like your IDE has let loose and changed lots of formatting.

Hi,
I have made the changes in my patch according to #111 and have regenerated the patch again. Please do review it once and let me know.