Add 'homepage' to .info.yml

A “homepage” key already exists in composer files. Can core parse that value?

For what it is worth, I am not sure this all that desirable, especially since we want to reduce the re-implementation of Composer features in our dependency parsing functionality. (See #3005229: Provide optional support for using composer.json for dependency metadata.)

Re: #2: There's not necessarily an accurate composer.json to parse. Even if we had #3005229: Provide optional support for using composer.json for dependency metadata that's still optional. And we could be dealing with a custom module that doesn't have a project homepage.

Obviously, it wouldn't be included if empty.

FWIW, the release history XML includes a 'link' value:

https://updates.drupal.org/release-history/token/current

<project xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>Token</title>
  <short_name>token</short_name>
  <dc:creator>Dave Reid</dc:creator>
  <type>project_module</type>
  <supported_branches>8.x-1.</supported_branches>
  <project_status>published</project_status>
  <link>https://www.drupal.org/project/token</link>
  ...

That's what the available updates report uses for this, which is why project names are links at /admin/reports/updates and /admin/reports/updates/update

If update.module is enabled, we could have an API to get project info from it. But a) not everyone turns on update.module and b) there's some weirdness with what update.module would do if it hasn't fetched data yet.

Alternatively, the d.o packaging script could easily add a 'homepage' key to all .info files while it's inserting the right 'project' and 'version' keys, although I know some folks don't like that packaging is touching the .info files at all. Adding #3036459: Packaging info from .info.yml often creates conflicts when patching as related. That's obviously way out of scope here, too, but raising it for consideration.

Regardless, everything would have to be able to handle cases where there's no value, for all the possible reasons:

• Custom module without a project homepage at all.
• Older version of .info files that doesn't define the new key.
• Relying on update.module but not enabled.
• Relying on update.module but hasn't / can't fetch.
• ...

Given that update.module already handles this for itself, I'm not sure how many other spots in core would care about this. ;) Maybe this is/should be headed for "won't fix". Quick brainstorm of possible uses:

1. Error messages about update + post install hooks (original use-case that spawned this).
2. On the "Extend" page (/admin/modules), inside the collapsed details, under 'Machine name', we could have a link. Would involve a lot of duplicate links (e.g. core has ~50 modules on this page, each one would point to the same 'Homepage'), but at least they'd all be under separate collapsed details. Also some UI considerations on what the link text should be, since 'Homepage' might be really weird in this context. Probably 'Project homepage' or something would be better.
3. On the "Appearance" page (/admin/appearance) we could add a 'Theme homepage' link under each theme. Seems like confusing noise.

Can anyone think of any other spots that might want this? I'm not going to bother with a summary update for all this unless it's more clear this is actually worth pursuing...

Thanks,
-Derek

This kind of changes should target 9.1.x now, thanks!