Problem/Motivation

This is a follow up to the work started in #2660144: [Plan] Update core components. That issue removed some legacy components were deleted.

This issue it to resolve points 2 and 3 from that issue. Also, keep in mind that we are moving to GitLab where these will become labels.

  • Components that are hard to differentiate - batch system vs. form system.
  • Sheer number of components - i.e. one per module.

Currently the component list consists of 85 modules, 35 systems, 9 themes, 3 db driver, plus markup, javascript, CSS, phpunit, composer, documentation, meeting, Umami demo, user interface text, single directory component and other.

Perspectives to consider

  • As a user I want easy choices related to the 'thing' I am doing
  • As a maintainer of a subsystem, I need a way to filter my issues.

Proposed resolution

Use a card sort to aid making a decision here

Limited to 15 people.

General points of agreement

  • Keep the component list and MAINTAINERS.txt in sync

This list does not include components that have been removed from D8+ or are D7 only.

  1. CSS - CSS
  2. announcements - announcements_feed.module
  3. base - cron system, lock system
  4. ban - ban.module
  5. contact - contact.module
  6. batch - batch system
  7. bootstrap - bootstrap system
  8. cache - cache system, page_cache.module
  9. coding standards -
  10. composer - composer
  11. configuration - configuration entity system, configuration system, config.module
  12. database - database system, mysql db driver, postgresql db driver, sqlite db driver
  13. update - database update system
  14. entity - entity system,
  15. edit - ckeditor5.module, editor.module
  16. extension - extension system
  17. field - field system
  18. fields - comment.module, datetime.module, field_ui.module, file.module, link.module, number.module, options.module, telephone.module, text.module
  19. file - file system
  20. form - form system, inline_form_errors.module
  21. image - image system
  22. help - help.module
  23. install - install system
  24. javascript - javascript
  25. mail - mail system
  26. layout - block.module, block_content.module, layout_builder.module, layout_discovery.module, field_layout.module, settings_tray.module
  27. localization - language system, language.module, locale.module
  28. log - dblog.module, syslog.module
  29. media - media system, breakpoint.module, image.module, responsive_image.module
  30. meetings
  31. menu - menu system, menu_link_content.module, menu_ui.module, path.module
  32. migration - migration system
  33. multilingual - language system, transliteration system, config_translation.module, content_translation.module, language.module, locale.module
  34. node - node system,
  35. plugin - plugin system
  36. render - ajax system, asset library system, markup, render system, theme system, contextual.module, filter.module
  37. request processing - request processing system, big_pipe.module, dynamic_page_cache.module
  38. routing - routing system
  39. search - search.module
  40. single directory components - single directory components
  41. statistics - statistics.modules
  42. system - system.module
  43. taxonomy - taxonomy.module
  44. testing - phpunit
  45. themes - claro, olivero, stable9, stark, starterkit_theme
  46. token - token system
  47. toolbar - toolbar.module
  48. typed data - typed data system
  49. umami - umami demo
  50. update - automatic_updates.module, update.module
  51. user - user system, history.module, user.module, shortcut.module
  52. interface text - user interface text
  53. views - views.module, views_ui.module
  54. web services - basic_auth.module, jsonapi.module, rest.module, serialization.module
  55. workflow - content_moderation.module, workflows.module, workspaces.module
  56. other -

Remaining tasks

To decide:

  • Keep the specific components/labels for specific modules or not

Comments

quietone created an issue. See original summary.

quietone’s picture

quietone commented

Here is a suggested start. It does not cover all the current components.

  • configuration - configuration entity system, configuration system, config.module
  • database - mysql db driver, postgresql db driver, sqlite db driver
  • entity
  • fields - field_ui.module, number.module, options.module, link.module, telephone.module, text.module
  • help
  • layout -
  • localization - language system, language.module, locale.module
  • meetings
  • menu - menu system, menu_ui.module, menu_link_content.module, path.module, path+alias.module
  • migration
  • plugin system
  • render - ajax system, asset library system, forms system, theme system, markup
  • routing - routing system
  • single directory components
  • testing
  • themes - claro, engines, olivero, stable9, stark, starterkit_theme
  • translation - transliteration system, content_translation.module, config_translation translation_entity.module
  • umami demo
  • update - database update system, update.module, automatic updates
  • views - views.module, views_ui.module
  • web services - basic_auth.module, jsonapi.module, rest.module, serialization.module
quietone’s picture

quietone commented
Issue tags: +Component maintainers, +Project governance
quietone’s picture

quietone commented
Related issues: +#2702321: Group core components into broad categories
andy-blum’s picture

andy-blum
he/him/his
Primary language English
Location Ohio, USA
commented

would it be possible to alphabetize the components as well?

catch’s picture

catch
he/him
Primary language English
commented

No solutions but possible problems:

Entity and fields is tricky, the individual field types are not part of the entity API, but the field API very much is, and issues could end up in the wrong place because of that. We sometimes get the same issue with node/user/comment/taxonomy issues that could be entity-type-specific, could be entity system but just discovered via a specific entity type. Same with content_translation and entity where there's a lot of overlap.

I wouldn't put the database update system and update module together because they're dealing with very different things, but this is complicated by automatic updates module which is dealing with both.

quietone’s picture

quietone commented
Issue summary: View changes
Status: Active » Needs review

In the hope of generating discussion I made a suggestion in the IS. It is limited to D8+ components and I am sure there are mistakes.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

I get that we want to reduce the amount of labels/components, but I'm not sure about grouping together different modules and things that have different maintainers. As a maintainer of a subsystem, I need a way to filter my issues.

Examples for that would be different database backends, but also config/translation being *very* different beasts that have little to no overlap. But also themes, olivero and claro have completely different maintainers.

So IMHO, the components for issues should be based on the components we have in MAINTAINERS.txt and if we want to clean up, we should start there?

Another problematic use case is things that we remove from core. For example you put the form system and inline_form_errors in the same component. if we were to remove the module from core it would be _very_ tedious to find all relevant issues and move them to the contrib module.

IMHO, the solution for that with gitlab issue labels would be multiple labels. For example, both localization and translation could actually be a common multilingual label but then each module within that would also have it's "sub-label" and we'd add both to an. That would of course result in even more labels technically speaking, but that's going to happen anyway because we'll also need to make all tags labels?

cilefen’s picture

cilefen commented

+1 that whatever we do, it should align with MAINTAINERS.txt, including if that means modifying MAINTAINERS.txt.

ckrina’s picture

ckrina
she/her
Primary language Catalan
Location Barcelona
commented

But also themes, olivero and claro have completely different maintainers.

Agreed. As a Claro maintainer it's really useful being able to filter by Claro itself.

quietone’s picture

quietone commented

Yes, the components and MAINTAINERS.txt should be more in alignment. And because of that I don't think it is necessary to start this discussion on how to group the components in a new issue about MAINTAINERS.txt. We just need to keep in mind the two places these 'groups' are used.

For some reason I did not mention in the IS that we could use scoped labels. I am guessing that this is the sub-label referred to in #8. That will allow us to maintain the module or theme granularity.

@Berdir, are you suggesting this change?
Replace

  1. localization - language system, language.module, locale.module
  2. translation - transliteration system, content_translation.module, config_translation

with

  1. multilingual - language system, language.module, locale.module, transliteration system, content_translation.module, config_translation
smustgrave’s picture

smustgrave commented
Category: Task » Plan

Moving to plan.

But also a +1 to redoing MAINTAINERS.txt as we currently have 26 gaps in it.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

> @Berdir, are you suggesting this change?

If and only if we keep the specific components/labels for the specific modules (whatever they will be called), yes. The separation between localization and translation seems arbitrary to me.

That was just one example, I'll try to take another closer look under that assumption and make more suggestions.

quietone’s picture

quietone commented
Issue summary: View changes

Updated the IS to include the preference for keeping the extension granularity and the 'multilingual' suggestion. Also, sorted the items on the right side of the hyphen by system then by extension.

@Berdir, thanks. I am looking forward to your suggestions.

quietone’s picture

quietone commented
Issue summary: View changes

There has been little engagement with this issue and I also think this is a difficult task to do in an issue. A few days ago I thought a card sort exercise of some sort will help. I am only just starting to explore that.

Also, I updated the IS to show that there is agreement on keeping this in sync with MAINTAINERS.txt. I have moved the point about agreement on keeping the module level distinction to a remaining tasks for further discussion. I did that because of my experience as a migrate maintainer. Quite a few migration issues were neglected because they were filed in some module component. It was purely by accident that I found one and then added extra searching to my habits. I'd like to consider that a bit more and hear other opinions.

poker10’s picture

poker10 commented

As the D7 EOL is in January 2025, I am curious what exactly does this mean?

This list does not include components that have been removed from D8+ or are D7 only.

Don't we need to preserve D7 components until the EOL?

quietone’s picture

quietone commented

@poker10, yes, the D7 world needs to be included in some way. When I made this is seemed that starting with D8+ only would make this simpler due to less components, but also to encourage long term thinking.

How about the D7 components are added but say, in italics, so we can see the difference. You are invited to add them to the IS :-)!

poker10’s picture

poker10 commented

I checked the list of components and compared it with the proposal in the IS. Here are my thoughts:

D7 only components which are missing in the proposal:

  • base system - add to the group "base"?
  • xml-rpc system
  • aggregator.module
  • blog.module
  • color.module
  • dashboard.module
  • menu.module - add to the group "menu"?
  • openid.module
  • overlay.module
  • php.module
  • poll.module
  • profile.module
  • rdf.module
  • simpletest.module - add to group "testing"
  • trigger.module
  • Bartik theme - add to group "themes"
  • Seven theme - add to group "themes"

I also found few D7/D10 components which are missing:

  • action.module - D10 only, missing in the proposal
  • book.module - D7 + D10
  • forum.module - D7 + D10
  • tour.module - D10 only, missing in the proposal
  • tracker.module - D7 + D10
  • documentation - not included anywhere in the proposal

I have not updated the IS with these two groups yet, as I think it would be better to check if some of them could be assigned to existing groups in proposal, instead of adding all of them as new groups. Once we reach consensus, we can update the IS according to this.

quietone’s picture

quietone commented

I had the idea that a card sort would help us resolve this. I reached out to https://maze.co/ and https://support.optimalworkshop.com for support. They both replied in the negative.

Anyone have other ideas to make this easy for us?

catch’s picture

catch
he/him
Primary language English
commented

@poker10 the Drupal 10 ones that are missing are (I assume) because those modules are planned to move to contrib for Drupal 11. Maybe we can apply @quietone's italics idea for those too.

Documentation for me is more of a topic than a component, although sometimes it's used for documentation for core on Drupal.org which is kind of a grey area compared to the actual documentation queue.

smustgrave’s picture

smustgrave commented
Priority: Normal » Major
mstrelan’s picture

mstrelan commented

I was pointed here after I brought up with @quietone and @larowlan at DrupalSouth that there is nowhere to log issues for GitLab CI or for the related code quality checks (phpstan, phpcs, cspell, eslint). Not just issues with the pipelines themselves but for improving phpstan, implementing phpcs rules, etc. Perhaps we should have a "CI" component, or a "Code quality" component.

quietone’s picture

quietone commented

Good news, a card sort may happen after all! No details yet, just sharing that this issue is not forgotten.

poker10’s picture

poker10 commented

To give an update here regarding my previous comment #8 - that comment was relevant until D7 EOL (or until all D7 issues were hidden on d.o.). D7ES programs use their own systems or s.d.o. queue (where components are not same as on d.o.). So I think we probably do not need D7 components anymore (if there is no need for them for Gitlab migration or other technical reasons).

quietone’s picture

quietone commented
Status: Needs review » Active

This dropped of my radar but it may happen early next year. Changing status because of that.

quietone’s picture

quietone commented

Re #18 and the components not listed in the issue summary. This issue is to improve the organization of the active components. The ones that are inactive could be grouped into an 'archive' or 'deprecated' group. The Gitlab migration issue has a comment about using 'deprecated'.

I asked in #gitlab some questions about the component field to get a better understanding of the plan.

quietone’s picture

quietone commented
Issue summary: View changes
dww’s picture

dww
we/he/they
commented

These can't both have the label: "update". This has historically been a source of confusion, anyway. But we can't have 2 tags with the exact same name:

13. update - database update system
...
50. update - automatic_updates.module, update.module

I don't love that Update Status and the new Update Manager (what I think we're branding "autoupdates.module" as) are the same component, but I'll get used to it. 😅 However, we need to distinguish from the db/post_update systems. Maybe:

13. database updates
50. code updates

?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

quietone’s picture

quietone commented

In Slack, fjgarlin explained that components no longer in use will have a (deprecated) suffix. See https://git.drupalcode.org/project/drupalorg/-/blob/7.x-3.x/drupalorg_gi...

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented

I've opened #3572360: Rename user system => authentication/authorization system just now. Hopefully that can get in while we are solving the larger problems.

quietone’s picture

quietone commented
Issue summary: View changes

Still trying to use a card sort for this and the problem of cost still remains. The free option allows for 15 participants and I think we should do that. So, I think we should just do that. As for selecting people I think we should try for a range of views, a range of experience in the core queue, front end, back end etc.

Keep in mind the results are to aid deciding if any change should be made.

What do you think?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Some (more, years later) drive-by comments:

* as catch already said, the split between entity type and field type providing modules is pretty confusing. comment is in field, content_block is in layout. node is separate. those 3 are all more similar to each other than the other modules in their current groups, and they will get similar/and slimmer over time as we unify and standardize more things. I'd split them in roughly 3 groups: entity/field api (including ui), entity-type-providing modules (node, comment, block_content, taxonomy) and field-type providing modules (datetime, telephone, link, ..). Still worth keeping most if not all of them as dedicated comments
* media.module actually too, that's more like node/comment, an entity-type-providing module and has little to nothing to do with breakpoints, image styles and so on.
* the 3 different menu elements possibly could be combined, at least some of them. path.module is something entirely different though, that's more about routing/request processing, and not menus. we also have the path alias module now.
* page cache and dynamic page cache are also more request processing than caching, similar to rendering/render caching.
* SDC is part of render?

but ultimately, with a few exceptions, all these still deserve to their own thing IMHO, more parent/related components. not sure if gitlab gives us some tools to handle that, adding multiple labels sounds a bit complicated, possibly automated through a bit? if you add telephone.module label, it also gets the parent label automatically, but you can also assign stuff to the parent?