The attached patch converts a module's name to a link to its project page so users don't have to search for it themselves anymore. The only possible drawback of this approach ist that if users remove core modules from /modules, links will appear to non-existent project pages if those modules are dependencies.
| Comment | File | Size | Author |
|---|---|---|---|
| missing_module_link_00.patch | 1.2 KB | xano |
Comments
Comment #1
dave reidI like the idea and I'm using the same idea in #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files and it's D5/6 implementation, module_supports. My concern is leading users to 404s (a module not hosted on d.org,, etc). Brainstorming...maybe instead of linking straight to http://drupal.org/project/project_name, we could link to a search on d.org (http://drupal.org/search/node/project+name+type%3Aproject_project)?
Comment #2
xanoI didn't consider the fact that a lot of modules are custom made or aren't hosted at d.o. A search would definitely be better in those cases.
//Edit: my initial solution wouldn't work for modules shipped in packages either.
Comment #3
catchUpdate status seems to get around this issue, wondering if we could make use of the same mechanism - although I've got a feeling it relies on the module being installed in the first place...
Comment #4
xanoUpdate uses cron, right? It periodically checks d.o for updates. The modules list is built real-time and therefore cannot contact d.o to verify the existence of certain modules.
Comment #5
catchIt uses cron to check for updates, but the information is cached. I'm suggesting we use the same XML information to determine whether a project is hosted on Drupal.org - this would only need to be done very rarely. With hook_update_status_alter() (or whatever it's called), organisations with their own packaging / deployment would be able to do the same thing - if modules are managed in an internal release system or whatever.
Comment #6
xanoOne tiny problem: Update.module isn't always enabled. We would have to move certain parts of its code to core if we want to use it to fix this issue.
Comment #7
dave reidMarking this as a duplicate of #210243: Allow for an optional 'download link' entry in the .info/.yml files so that missing module dependencies can be rendered as links..
Comment #8
xano