This issue stems from #538904: D8UX: Redesign Modules Page

The Problem

On the modules page, it gets harder and harder to find / enable / disable desired modules, the more modules are installed in a Drupal site. This is partially to do with the previous use of 'packages' which are often misunderstood, and sometimes intentionally misused by module maintainers.

Proposed resolution options

1) get rid of "packages" (see #1371524: Remove packages from modules list and .info files
2) Use something else to organize the modules page

Ideas for "something else"

Module category from drupal.org project form
- doesn't need to be provided by maintainer
- discreet set of options
- can be limiting for modules that don't fit in the options available

Downloaded / uploaded together
- indication of which "modules" came in which "module"
- similar to the updates page (admin/reports/updates)

"tags" or "labels"
- also up to the module maintainer
- unlimited number of options
- .info file syntax: tags[] = Administration

Dependencies
- which modules depend on others
- which modules are required by others

Extensions
- (someone please explain extensions?)

Parents
- (someone please explain parents?)

Files: 

Comments

webchick’s picture

Here's a high-level summary of the hour long discussion we just had about this on IRC. :)

I don't actually think we need another means of organizing the modules page. I think we just need to group sub-modules together (so "Page manager" doesn't appear randomly in the list despite you having downloaded "CTools"), and have a search box at the top. #396478: Searchable modules page

Generally speaking, people don't browse things by category when they're not sure where to find it. They will use the search box first and then, failing that, will use Drupal.org's search box. If we do #1355358: Allow searching for modules on Drupal.org from the modules page we can have the best of both worlds. :)

Jen's position is that if we included a tags[] property with multiple keywords, and let the search box search on that as well as title/description, that would help, and not require keyword overloading in a module description which should be kept short. My position is that if I add the keywords to my project page and we can search drupal.org from the modules page, that solves both problems at once without any extra work for me as a module maintainer.

eigentor’s picture

That sounds awesome.
I was never a fan of the current categorization of modules.
Some kind of guidelines for module developers would be necessary, though.
One might see people stuffing their modules with keywords like in ancient SEO times just to be found more often :P

How about allowing not more than 3 or 4 tags?

jenlampton’s picture

Title: Replace "package" sets on the modules page with "project" groupings » Replace "package" sets on the modules page with a better way to organize modules
Category: feature » task

I still hold that a search on title + description would be miles and miles beyond what we have now. Adding tags or something else to search on would be a bonus, but maybe not required. Maybe I should table the tags vs categories argument, and just focus on #396478: Searchable modules page

But what about grouping "modules" (those files that end in .module) by "module" (those folders that you download and unzip from drupal.org) like on the Available Updates report page? :)

jenlampton’s picture

Title: Replace "package" sets on the modules page with a better way to organize modules » Replace "package" sets on the modules page with "project" groupings

er, meant to change the title.

webchick’s picture

Title: Replace "package" sets on the modules page with "project" groupings » Replace "package" sets on the modules page with a better way to organize modules
Category: task » feature

Yes, please. :D

Also, moving to feature request. This is important, but I'm not sure it's important enough to hold up D8 development, esp. since the parent issue is already a major task.

jenlampton’s picture

Title: Replace "package" sets on the modules page with a better way to organize modules » Replace "package" sets on the modules page with "project" groupings

Okay, but I'm changing the title back again.

Xano’s picture

Title: Replace "package" sets on the modules page with a better way to organize modules » Replace "package" sets on the modules page with "project" groupings
Category: task » feature

I *think* it was webchick who suggested something like allowing modules to configure a 'parent' for them. I imagine it like this:
- Commerce Payment has Commerce as its parent
- Commerce Paypal has Commerce as its parent, even though the two are in different projects.
- Commerce is its own parent (whoa, Oedipus complex?)

If we replace packages with this, we can have this (credits to @yoroy in 538904#198):

Xano’s picture

I had this LONG story written down here and then I accidentally the back button on my mouse.

In short:
**projects (aka downloaded/uploaded together)**
Are useful for downloading stuff and only tell you a certain set of modules was developed together. They imply a relationship between the modules in the project, but modules from project B may belong to those of project A, a use case which sorting by project does not address. This would also require up-to-date project information from drupal.org OR a change to the packaging script.

**tags**
Just like with the current packages, these can make things very unclear for end users. I like @jenlampton's idea of using these for search only. Does not require changes to drupal.org. Can be misused by maintainers adding tons of keywords, but I don't think this is likely.
We probably need to make tags translatable as well, because on a modules page where everything except for those tags is Dutch, no one is going to search using English keywords/tags, unless they only want to filter module names (which are by convention never translated).

**dependencies**
Would add A LOT of clutter, especially for modules that have more than one dependency. Does not require changes to drupal.org.

**predefined categories**
Packages were supposed to be predefined, I think. It speaks for itself this never really worked.

**parent modules**
Would require very little change to info files. Hard to abuse, since it can only have one value which has to match another module's machine name. May not work if parent module is not available (unless this setting uses a module's human-readable name rather than its machine name).

klonos’s picture

+1 for parent modules & a fallback when parent is not present (dreaded "Other" category - perhaps renamed to "Unsorted" or something).

jenlampton’s picture

I still don't see why parent is any different than package, other than a name change. A limit of only one parent presents the exact same problem (is an admin views module located under admin, or views?, is panel content panes located under panels, views, or ctools?), and if it's still provided by module maintainers then it can still be misunderstood and/or abused.

What's the benefit of parent over dependency? One module can be dependent on more than one other, how would a module maintainer decide which one of those is the parent, and why would you want them to? If there is no dependency on the parent, what happens if the sub-module is installed without the parent? Does it become the parent?

I think the idea of creating "categories" where there aren't any is going to be problematic however we try to do it. :/ But I don't think parent is the answer.

However, if we use project, not only will it give admins some clue that more than one "module" can be included in a "module", bit it will give us a nice place in the UI to add an "Update available" indicator, as well as a "location of these files on the system". Two other requests mentioned in #538904: D8UX: Redesign Modules Page that don't currently have a home on the modules page.

Xano’s picture

Well if we use the US English human-readable title to declare a parent module, we wouldn't need a fallback. It's not the best DX, but it would definitely allow us to create a consistent interface with 'parent/child' relationships.

webchick’s picture

Oh please, no. Please don't make me hand-type the name of the module my sub-module ships with N times in N info files. :( The Update Status report can figure the sub-module concept out from merely looking at the file system without me as a module developer having to do any manual stuff. Less work++

Damien Tournoud’s picture

Given the direction we are going (with Git and stuff), we are going to have *more* packages containing a *fewer* number of modules, not the other way around (just an example: the Search API recently split itself into more modules). As a consequence, grouping by packages is soon going to be a synonym for not grouping at all. Do we really want to go there?

Xano’s picture

Some clarification of the parent project idea:
- Parent modules offer the same flexibility (or lack thereof) as packages do, but offer a lot more valid values.
- In other issues we already decided that dependencies aren't always relevant. The fact that Commerce Payment depends on Commerce is useful, because one can guess it extends Commerce, but it's less relevant that the shopping cart depends on Views, because it only uses it rather than extend/improve it.
- Update status info is not always available, nor does it have information about modules that may not even be available locally. The file system is (unless someone messed up) project based. It's definitely useful, but like I illustrated before, module A from project A may extend module B that comes with project C. You can't see this relationship by looking at update status information or the file system.

I agree with @jenlampton that parents are not as good, as there is the issue of needing more than one of them. @webchick's argument of tediously having to retype the module name for every module in a project is fair too. The above list is not meant to hammer my idea through, just to address some of your concerns.

I just realized that we only have projects on Drupal.org. Custom modules have no project information associated with them.

I can't really tell you why, but I'm more and more thinking we may just want to create a simple long list with modules sorted alphabetically and add kick-ass filtering. @jenlampton's tags would come in handy there.

Xano’s picture

In terms of reliable relationships, projects is so far the only one that (if we put that information in info files) actually works and may make sense/adds consistency.

webchick’s picture

Yay! Simple long list with modules sorted alphabetically and add kick-ass filtering++ :D

With the caveat that true sub-modules (meaning /modules/ctools/page_manager.module) should be grouped under the parent project, so that all CTools modules don't get all scattered to the winds when you download it.

klonos’s picture

I understand that leaving the grouping to be handled by file/folder structure is an easy way, but this provides no way to group a separate project under a certain parent/related one (think entity & entity_translation) ...unless we allow modules to be extracted inside other modules' folders too (instead of only under ../sites/all/ or ../sites/site-name/ that we practice now). If so, how do we do that in a way that is as transparent as possible? Do we package the child project in a .tar that includes its parent project's folder at the top of its structure? What happens with projects that are related to multiple others as Jennifer mentioned back in #10 (think i18nviews for example)?

webchick’s picture

My experience has been that most related modules in that way are named with similar prefixes. Entity / Entity Translation is a great example. So is Commerce, Commerce Bulk Product Something Something, Commerce PayPal, etc. So this is a non-issue, IMO.. they'll show up next to/near each other in the listing anyway.

And in cases where they're not, I don't think it actually is a usability improvement for something to arbitrarily re-parent itself under "Views" just because it has something to do with Views. The project I downloaded was called "Views Bulk Operations". That's what I'm going to look for in the list, and I'll easily find it between the "Views" and "Wallaby" modules. I don't want to have to guess first whether the module maintainer, in their divine wisdom, decided to locate it under "Views" or "Administration" or "Other".

Xano’s picture

That's actually a very good point.

Are we still in favor of grouping by project or not?

jstoller’s picture

My thinking has evolved a bit, but much of what I'm about to write I've already posted in #538904: D8UX: Redesign Modules Page. And I posted pictures there. :-)

If a project contains multiple modules, then that project grouping should be provided as one element in the modules list. When I go to enable a module, its typically the project name I'm thinking of...not the sub-module name. This may require an extra click to "open up" the project when I want to enable one of its member modules, but that seems a small price to pay (assuming no page load required).

I suggest requiring that the "base module" in a project have the same machine name as the project itself. All the members of that project would then set a project variable equal to that name. I would then add two new variables to the base modules .info file: project_name and project_description. This allows the project as a whole to have a different human-readable name and description than any of its individual modules. The variables should be optional, however, and should revert to the name and description of the base module if not provided.

To handle the case where one module extends another, I suggest adding an extends[] variable to the .info file. This would be an array of project names, referencing any modules who's functionality the module in question extends, replaces, or somehow augments. When I open up the details of a module package, under the list of member modules, I could then see a list of all the modules that extend this module. This would be in addition to each project being listed on its own, so I wouldn't have to open Views to get find the Views Slideshow module, for instance.

To take one of jenlampton's examples from above, lets consider the Admin VBO Views module. It may be dependent on views and vbo, but it extends user, node and comment. Likewise, the Views default argument from Context module may depend on on context, but it extends views.

This mechanism would handle the grouping of modules into functional sets very well. So if I looked at the details for Views, I would see a list of all the views display modules and such that extend it. If I looked at the details for Fields, I would see a list of all the modules which add new field types. (Note that I am not considering Drupal to be a single package for in this context.)

In addition to functional grouping, I think there is also value to grouping modules into conceptual categories. For this I suggest adding a categories[] variable to the .info files. This array would accept arbitrary strings, much like the package variable does now, but with some differences. First, and most importantly, I propose that we develop a list of generally acceptable categories for developers to use, covering most of the situations one might come across and put this in the documentation. For inspiration I'd look to the menu structure. Something like:

  • Administration
  • Appearance
  • Content authoring
  • Core
  • Development
  • Media
  • Other
  • People
  • Regional and language
  • Structure
  • System
  • Testing and examples
  • User interface
  • Web services
  • Workflow

Another difference from package is that we should never have anything like "Views", since that is a package, not a category. If you want to see a list of projects providing views displays, then you should look at the listing for Views. If you want to see a general list of modules that deal with site structure, you can look at the "Structure" category.

webchick’s picture

I don't quite follow the rationale for project, project_name, and project_description. If my module is part of a parent module, it'll be found in the parent module's folder. Once again, see Update Status. It knows that CTools is the parent module of Page Manager already, without module developers having to put in any extra stuff in their .info files. I guess though that it would be worth investigating that logic further to find out if it's coming from drupal.org or if it's figuring it out from the file system or how that happens.

In terms of extends[], you might want to have a look at #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files where there's a large discussion about that sort of thing. Pulling it into the modules page as a filter is an interesting idea, as long as it doesn't clutter up the page too much.

If we're going to do categories, let's please re-use the list on Drupal.org. No sense in developing two separate taxonomies for modules. If the Drupal.org one needs adjustment, let's handle it in the webmasters queue.

jenlampton’s picture

Title: Replace "package" sets on the modules page with "project" groupings » Remove "package" groupings on the modules page (and from .info files)

Yay! Simple long list with modules sorted alphabetically and add kick-ass filtering++ :D

I'm leaning more and more towards no groupings at all. You're all right. In *most* cases the modules that you want to find near each other are named similarly anyway (Views, Views content panes, Views bulk operations). And, if our search is awesome enough, the groupings won't matter at all anyway. Does anyone use the "groups" drop-down in Views 3 anymore, since the search was added? I only ever use it when I don't know what the name is for the thing I'm looking for, and as discussed previously, in that case I probably want to see everything anyway. I'd be more inclined to add a "category" filter at the top of the list than any kind of groupings.

jstoller’s picture

Yay! Simple long list with modules sorted alphabetically and add kick-ass filtering++ :D

This sounds like a nightmare to me. I mean, I think it's great if the module list and kick-ass filtering are available as one approach to this page, as long as alternate modalities are supported as well. The long list with search is fine when I know exactly which module I'm looking for. However, as I've said before, the majority of the time I spend on this page I am in more of an exploratory mode, without a single defined target. So most of the time I hate, hate, hate that humongous list of modules. It is way too overwhelming and makes it impossible for me to get a good overview of what's happening on the site. I like my modules in smaller groupings. And not a long list of groupings, like we have now, but actual smaller lists, like just the core modules, or just administrative modules. That's the kind of filtering I'm looking for.

I don't quite follow the rationale for project, project_name, and project_description.

The base module of a project may be deserving of its own human-readable name and description. These variables let developers give the overall project a name and description, independent of any member modules. For instance, we might have something like:

; info file for imagecache_actions.module
name = Imagecache Actions API
description = Base for imagecache utilities used by the individual imagecache actions.
project = imagecache_actions
project_name = Imagecache Actions
project_description = A collection of utilities providing additional actions when creating image presets.
If we're going to do categories, let's please re-use the list on Drupal.org. No sense in developing two separate taxonomies for modules. If the Drupal.org one needs adjustment, let's handle it in the webmasters queue.

I think we should discuss this in terms of what works on the module page, irrespective of what D.O does. If in the end what we come up with will work there as well, then that's great. I just don't want to constrain/torpedo this category implementation by restricting the categories at this point. Also, the two are somewhat different. I'm proposing a separation between conceptual categories and functional groupings—categories[] vs. extends[]—but D.O puts both in one list. And even then, on D.O you may not want to list every module that has a module which extends it, but just the big ones with significant ecosystems, like Views.

Moving forward, I would suggest considering two things: What do we need to support the implementation of the module page in Core? But also, what can we do to support Contrib development of features that don't make it into Core? For instance, I'm arguing for some form of category tabs in Core, but not everybody agrees with this. If I loose out and the tabs get cut, most likely someone will create a contrib module that brings those tabs back (module_filter-8.x?). However, they can only do so if the underlying framework is there to support it. Same thing with grouping modules by project. So lets build in that framework, even if Core doesn't make full use of it. The Module filter is using the package variable because that's all it has available. So lets build in something better.

Taxoman’s picture

jstoller’s picture

Title: Remove "package" groupings on the modules page (and from .info files) » Remove/replace "package" groupings on the modules page (and in .info files)

Changing the title. I'm not giving up on this one yet. :-)

jenlampton’s picture

Title: Remove/replace "package" groupings on the modules page (and in .info files) » Come up with better alternatives for groupings on the modules page

I want to be able to make some progress on this issue, so I'm splitting it into two :) First, I'd like to #1371524: Remove packages from modules list and .info files and second (continued here) let's keep working out a better alternative (or maybe several, then we can offer people different ways to group things on the modules page :)

jenlampton’s picture

Issue summary: View changes

adding a few more ideas

jenlampton’s picture

Issue summary: View changes

add a few new options for what we should be doing instead

jenlampton’s picture

Just as a fun experiment, below is a list of modules I have on a site I'm working on now, which I think is a pretty good example of a "standard" Drupal site (if there is such a thing). Let's compare projects, packages, d.o categories, "parents" and "extensions" and see what we get :)

Projects (distinct)
admin_menu
betterselect
ctools
custom_breadcrumbs
date
devel
flag
forward
globalredirect
google_analytics
hint
iframe_filter
image_resize_filter
imagecache_actions
insert
jquery_ui
mollom
nice_menus
nodewords
on_the_web
options_element
page_title
paging
panels
path_redirect
pathauto
quicktabs
service_links
similar
site_map
site_verify
tagadelic
taxonomy_menu
taxonomy_title
token
video_filter
views
views_slideshow
webform
wysiwyg
wysiwyg_filter
xmlsitemap

Packages (distinct)
Administration
CCK
Chaos tools suite
Core - optional
Core - required
Custom breadcrumbs
Date/Time
Development
Flags
ImageCache
Input Filters
Meta tags
Other
Panels
SEO
Service Links
Service Links - Services
Statistics
Taxonomy
Taxonomy Menu
User Interface
Views
Webform
XML sitemap

d.o categories (non-distinct)
Administration
Content
Content Display
Community
Developer
Drush
Evaluation/Rating
File Management
Filters/Editors
JavaScript Utilities
Mail
Media
Paging
Path Management
Rules
Search
Site Navigation
Statistics
Spam Prevention
Syndication
Taxonomy
Third-party Integration
User Access & Authentication
Utility
Views
Other (modules not in categories)

Parent
?

Extensions
?

johnv’s picture

johnv’s picture

Issue summary: View changes

clean up formatting

yoroy’s picture

Priority: Major » Normal
Issue summary: View changes
lpalgarvio’s picture

Version: 8.0.x-dev » 8.1.x-dev

+1 for Module categorization AND tags

WIth tags you can also say that for example, File entity module as well belongs with Media, together with the Field category provided by module categorization.

TLDR, with both you can have presets from drupal.org + any custom tags the author wants.

yoroy’s picture

Issue tags: +ux-hierarchy

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

matthieuscarset’s picture

I'd like to add a small fix to the module page.

No matter the choice we make about categorization of module in this list, I (and surely other users) would prefer to have all groups closed by default.

The attached patch close all groups by default.