On the "Extend" page (admin/modules), there are 3 modules that are in the "Multilingual" group (not identified as "Core"), and all of the rest are in "Core".

This seems wrong to me:
- The multilingual ones should be relabeled "Core - Multilingual", or they should be part of Core.
- And if we're going to allow the multilingual modules to be in a separate group, then we should make some more groups. Like maybe putting the field modules in a group so you could actually find them?

This is made even worse by the fact that for some reason we've decided all the modules must have cryptic one-word names. So you can't very easily scan down the list and immediately know what they're for.

Comments

adammalone’s picture

adammalone
Primary language English
Location Sydney
CreditAttribution: adammalone commented

Unfortunately feature freeze has passed so putting module_filter-esque functionality in is probably off the cards.

That being said I do like the way it groups them and makes it easy to navigate and isolate the different module groups.

The only question then, if this is proceeded with, is how exactly to group the modules. At a very quick glance I've come up with a few groups.

  • Core - Services
    • REST
    • Serialization
    • JSON-LD
    • XML-RPC
  • Core - Fields
    • E-Mail
    • Entity Reference
    • Field
    • Field SQL Storage
    • Field UI
    • File
    • Image
    • Link
    • Number
    • Telephone
    • Text
  • Core - Content
    • CKEditor
    • Node
    • Comment
    • Book
    • Block
    • Custom Block
    • Edit
    • Text Editor
    • Aggregator
  • Core - Metadata
    • RDF
    • Path
    • Search
  • Core - Multilingual
    • Content Translation
    • Interface Translation
    • Language

There could also be additional groups to group the remaining content - I'm still unsure of whether this would be positive or negative for the module admin page.

mitchell’s picture

mitchell CreditAttribution: mitchell commented
Status: Active » Closed (duplicate)

See #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality..

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Status: Closed (duplicate) » Active

Sorry, but this is really not a duplicate of that other issue, and that other issue may or may not be resolved (in spite of it being labeled "task" it's really a feature request). This issue is about the existing categories being inconsistent for the core modules, and if that other one doesn't fly, we'll still have this bug.

I do agree that if that other issue gets resolved this one will be obsolete, but I still think we had better leave this bug open until that one gets fixed.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

See #1833184: Find a consistent naming scheme for translation-related modules for the original discussion and reason for why this is using the package name "Multilingual".

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

@jhodgdon: the point of using "Multilingual" vs. "Core - Multilingual" for the category was that an actual site builder does not care where features come from. The relevance of which module comes from core and which comes from contrib for site building is minimal. However not being able to see all your modules for a task because some of the came from core and some came from contrib is bad.

As for categorizing all the other modules (not only multilingual), #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality. makes the point that taxonomy for example which is not categorized in #1 could go to "fields", "metadata" and "content" at the same time depending on how you look at it. Which is why the tagging issue was born.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

Righto. I think this issue here won't fix.

adammalone’s picture

adammalone
Primary language English
Location Sydney
CreditAttribution: adammalone commented
Status: Active » Closed (won't fix)

Tagging seems like a more logical solution based on what Gabor says in #5 as there are modules can't be categorized discretely.

Won't fix in preference of #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

While I agree that people don't care too much where their modules come from, it is also quite helpful as a site builder to be able to see at a glance that some modules are part of Core and will be updated when you update core, and some are in your sites/all/modules or wherever you've put them. Anyway, it looks like I'm in the minority on that idea, so I'll drop it. But it *is* important to me as a site builder. I'll comment on the other issue.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

@jhodgdon: I agree it is useful to see what is in core when considering upgrading core. Update status module nicely shows all the modules shipped with core as well as other projects nicely grouped by their source package not by their use.