- 🇺🇸United States nicxvan
I think this is a partial duplicate https://www.drupal.org/project/drupal/issues/937814 📌 [meta] Smarter UI/API separation for modules Active
Also recipes might solve this.
In both the new plugin manager and the module listing page, we need a way, from a user perspective, to "enable a project". Right now, we can't "enable a project" in the general case, because projects are not required to provide a module named after the project (for example CCK and Ubercart do not have modules named CCK and Ubercart).
Furthermore, it may be hard for people to figure out exactly which modules do what in a project. Offering developers a way to point their users in the right direction would be a usability improvement. It's also the only way that the plugin manager can do anything significant when installing a project, without adding yet another prompt. Similarly, there has been discussions on ways to quickly enable a project directly in the module listing page (in #538904: D8UX: Redesign Modules Page → ).
I think we should dismiss the idea of implementing it in a project-level metadatafile (see ✨ provide a project meta information file Closed: outdated ): we already have metadata files for modules, we don't need one for the project simply to fulfill that one requirement here.
An alternate solution could be to add a parameter to the module.info files flagging those modules as default or prioritize them in some way. We could have something like:
name = Devel
description = Various blocks, pages, and functions for developers.
package = Development
dependencies[] = menu
core = 6.x
priority = high
(Here, priority = high would mean that the module would be enabled by default. Priority = medium would mean the project would show up, but would be optional and priority = low would mean the module is basically library code that the user is likely to never see. just an idea.)
Another alternative would be to simply enforce a naming convention: enable the module named after the project when installing or "enabling" a project. Dependant modules would be enabled along and everything would be fine. Part of porting to D7 would be to follow that convention, modules would have to be renamed and dependencies would be managed accordingly. For example, the cck and ubercart projects would provide modules named CCK and ubercart that could just be dependency stubs for the right modules.
Those are just suggestions of the possible implementation, but I think we first need to agree that we need to have that distinction between modules within a project. This is why I am opening this issue separately from ✨ provide a project meta information file Closed: outdated , which is too focused on a specific technical solution.
To sum up, I have heard of 4 separate implementation proposals here:
* project-level metadata (no other use case,
✨
provide a project meta information file
Closed: outdated
)
* drupal.org settings available through update_status hooks (requires connectivity)
* metadata stored in already existing metadata files ("priority", proposed above)
* just enable the module named after the project (my suggested implementation above)
In my opinion, the naming convention is the cleanest and most elegant solution.
This issue stems from discussions around ✨ provide a project meta information file Closed: outdated , #538660: Move update manager upgrade process into new authorize.php file (and make it actually work) → and #538904: D8UX: Redesign Modules Page → . A quick review of those issues is recommended before posting here. I would also recommend people to keep to constructive criticism, patches or alternatives implementation when commenting on this thread.
Postponed: needs info
11.0 🔥
extension system
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I think this is a partial duplicate https://www.drupal.org/project/drupal/issues/937814 📌 [meta] Smarter UI/API separation for modules Active
Also recipes might solve this.