Document a list of modules used by Drupal CMS

I did not have much time, but for a start, here is a quick list of contrib modules taken from recipes ymls. I am unable to tell which modules are approved by tracks and which are only temporary from the prototype.

Base

• login_emailusername →
• trash →

Accessibility Tools

• editoria11y →

Admin Theme

• coffee →
• gin →
• gin_toolbar →
• sam →
• navigation →

Anti-spam

• antibot →
• honeypot →

Basic HTML editor

• linkit →

Blog

• better_exposed_filters →
• scheduler →

Content type basics

• pathauto →
• quick_node_clone →

Dashboard

• dashboard →

Events

• add_content_by_bundle →
• smart_date →
• date_augmenter →
• addtocal_augment →
• pathauto →

Forms

• webform →

Full HTML editor

• linkit →

Image media type

• focal_point →

Locations

• add_content_by_bundle →
• address →
• geofield →
• geocoder →
• leaflet_views →
• metatag →
• pathauto →

Recommended maintenance

• automatic_updates →
• project_browser →
• upgrade_status →

Media tools

• media_entity_download →
• media_file_delete →

Multilingual support

Basic Page

Advanced SEO

• field_group →
• metatag →
• robotstxt →
• seo_checklist →
• simple_sitemap →
• sitemap →
• token_or →
• yoast_seo →

Basic SEO

• easy_breadcrumb →
• hreflang →
• pathauto →
• redirect →
• token →

Content workflows

• diff →
• scheduler →

I'll leave the final decision on this up to the overall feelings of track leads, but I'll be honest speaking from my position as the technical octopus of this project - I'm not super in favor of doing this right now.

Drupal CMS is being rapidly iterated on and a lot of module choices are very much in flux. What came from the prototype and what didn't isn't really relevant until a relatively finalized list of modules is nailed down (which likely to happen closer to our general release date, and will be influenced by Drupal 11 compatibility, etc.)

So IMHO this is worth doing, but not now. I think this issue should be postponed.

Would it be useful if there was a job which basically did something like `composer show ` and filter to just drupal/ packages.

This helps show modules added via indirect dependencies.

Then it could be a job artifact as a text file

Drupal CMS is being rapidly iterated on and a lot of module choices are very much in flux.

I agree and understand this point of view. However, I think that if we would like to get as much as possible community folks involved, we need to make this somehow clear - at least which parts of the official repo are temporary and which are not. It was a bit unfortunate that we copied the whole repo from the prototype, because it was communicated earlier, that Drupal CMS has no code and then suddenly it had (understand there were some reasons for doing this, but still). This is a source of some confusion now and was also being asked multiple times, what is the real status.

Not saying we need this done today, but hopefully in a reasonable time long before the general release. Imagine a situation, that someone wants to help and will start creating issues about removing/changing modules already included in the repo (without knowledge, what is official and what not). That will create unnecessary workload, as these would need to be postponed/closed and it will also take waste the time of the contributor. Another reason for not waiting too long is to prevent a situation, when the response to contributor wanting to change a module will be "it is too late" (for the first/general release).

I do not want to add more work regarding Drupal CMS, but make it as transparent as possible, which is something that has always been a Drupal asset. And also prevent wasting time/efforts on both sides, as there is not much time in general. So thanks for considering this!

It was a bit unfortunate that we copied the whole repo from the prototype, because it was communicated earlier, that Drupal CMS has no code and then suddenly it had (understand there were some reasons for doing this, but still).

For the record, The reasoning for this is documented: https://git.drupalcode.org/project/drupal_cms/-/wikis/Historical-and-Pro...

Also, "no code" might not have meant "an empty repo" -- "no code" might just mean it is comprised of solely of recipes, which have no code. Drupal CMS has no glue code modules of its own, and will not. (Except for the installer, but that doesn't count since it is uninstalled by the installer itself.)

without knowledge, what is official and what not

"Official" is an interesting word choice - that decision is strictly up to the track leads and the leadership team. Documenting the list of modules currently being used wouldn't really help draw a distinction between what's official and what isn't. Things from the prototype aren't necessarily "unofficial".

There is no reason a contributor couldn't go right ahead this very moment and change any of Drupal CMS's recipes, adding/removing modules, etc. in whatever way they pleased. If those changes are approved by the relevant track lead(s), and there are no egregious technical problems (like broken tests or sketchy dependencies), it would almost certainly be merged. I think a similar approach will continue even after release, since backwards compatibility is a distant concern in Drupal CMS (a benefit of it being a bunch of recipes in a trench coat).

when the response to contributor wanting to change a module will be "it is too late" (for the first/general release).

Why would it ever be too late? Recipes have no update path. We could change the modules in use whenever we want, even after release. I imagine there will be some sort of vetting process (at least, that's my hope) but I don't foresee any reason to ever close the gate on a particular module being considered for inclusion in Drupal CMS (or, for that matter, being considered for removal).

Also, regarding #4: that sounds like an interesting side project, if you want to sling a PR at me, and I'd be fine merging a thing like that if the leadership +1ed it.

In the meantime, I'm marking this as postponed.

(sorry for longer post)

I would like to reiterate myself, that I do not mean this as an extra work, but the opposite, to make the whole process transparent and to avoid extra questions / work.

I believe that starting from scratch would have greatly slowed down our velocity, which IMHO outweighed the benefit of a clean commit history. Why reinvent the wheel when you can iterate on a solid start?

While I agree with this regarding to the installer, ddev and other Drupal CMS "core" code, I disagree with it regarding to the tracks recipes.

Things from the prototype aren't necessarily "unofficial", and things that came later aren't necessarily going to stick around. These decisions are currently being made loosely.

This is what I am a bit concerned about. There should be a governance → in place and a transparent process, or? Again, I am not saying today (I do not want to slow down the development), but within a reasonable timeframe.

There is no reason a contributor couldn't go right ahead this very moment and change any of Drupal CMS's recipes, adding/removing modules, etc. in whatever way they pleased. If those changes are approved by the relevant track lead(s), and there are no egregious technical problems (like broken tests or sketchy dependencies), it would almost certainly be merged.

But given the fact, that most of the tracks seems to be still in a analytical phase (research, planning, ...), I am not sure this will work. Realistically it will end up postponed and create a noise in the issue queue. Especially if other contributors do not necessarily need to know what is the status of each track - can you for example tell the status of the Analytics track according to this issue #3461542: [META] Track 18: Proposal for analytics → ? There is also this blog post https://www.drupal.org/about/starshot/blog/drupal-starshot-initiative-up... → , but I do not see the track mentioned there.

Also what would be the reason to make changes to recipes from prototype now, if most of the tracks are currently targeting this goal: For now, the scope is to produce the proposal only, not to develop the recipe.?

Why would it ever be too late? Recipes have no update path. We could change the modules in use whenever we want, even after release. I imagine there will be some sort of vetting process (at least, that's my hope) but I don't foresee any reason to ever close the gate on a particular module being considered for inclusion in Drupal CMS (or, for that matter, being considered for removal).

Yes, we can change a module at any time, but I hope that we are not going to "experiment" on community (even if there are no BC concerns) and not start changing some modules on a regular basis (like that we will have a "email_registration" in January, then "mail_login" in February a then "login_emailusername" in March). I suppose this is why each track is doing an analysis to select the most appropriate modules for the start. And once a module is "officially" in, I think (and hope) that it will be a bit harder to change that decision (therefore it is good to know where the "line" is, so that contributors can address these things earlier).

I understand that I am a bit influenced by the Drupal core processes and Drupal CMS processes should be a bit different, but in the end, I think the goal is to provide a stable product, as Drupal CMS aims to be a new default download. And even it is named as a fast-moving product, for me that does not mean "experimenting", but more of an improving.

I agree that the current situation is somewhat confusing, but unfortunately this is part of the process. We are building something new in a way we've never done before. All I can say to that is the confusion will lessen as we decide things. This applies to governance too, we are working on documenting some initial policies that we will release in the coming weeks and months.

As far as "stability", Drupal CMS is not out yet, so I don't feel that we need to be concerned with stability *at this point*. Our aim is to get to a stable release, and until then (or closer to that point) I don't think it's worth trying to document an official list of modules. If there are people in the community who want to do that, knowing that it is subject to change (potentially many/frequent changes) until the release, that's obviously fine!

Certainly once we get to a release, we will not chop and change modules without good reason.

This should be automated. We can surely scan all composer.json files and extract a list of modules from which we can generate a MODULES.md or something, which lists all of the modules in use and links to them. This could probably be a custom Drush command that is only part of our dev repository.

Assigning to myself to figure out how to do this. This is the kind of juicy thing I can have fun with while everyone else is at DrupalCon.

I am a fan of https://github.com/joachim-n/composer-manifest which creates a YML file listing all the installed packages and their version.

Not as simple as a Drupal module list, but since the only folks that are asking for this are developers, it may provide all the information that is needed and more without having to develop anything custom.

Cool, thanks @thejimbirch! (and joachim).

Leaving to @phenaproxima to decide if he wants to use this and then to wire it up, but running it in the built zip directory gives this output:

packages:
    asm89/stack-cors: v2.2.0
    carbonphp/carbon-doctrine-types: 3.2.0
    chi-teck/drupal-code-generator: 4.1.0
    clue/stream-filter: v1.7.0
    commerceguys/addressing: v2.2.3
    composer/installers: v2.3.0
    composer/semver: 3.4.3
    consolidation/annotated-command: 4.10.0
    consolidation/config: 3.1.0
    consolidation/filter-via-dot-access-data: 2.0.2
    consolidation/log: 3.1.0
    consolidation/output-formatters: 4.6.0
    consolidation/robo: 5.1.0
    consolidation/site-alias: 4.1.0
    consolidation/site-process: 5.4.0
    davedevelopment/stiphle: 0.9.4
    dflydev/dot-access-data: v3.0.3
    doctrine/annotations: 2.0.2
    doctrine/collections: 2.2.2
    doctrine/deprecations: 1.1.3
    doctrine/inflector: 2.0.10
    doctrine/lexer: 2.1.1
    dragonmantank/cron-expression: v3.4.0
    drupal/add_content_by_bundle: 1.2.2
    drupal/address: 2.0.2
    drupal/addtocal_augment: 1.2.3
    drupal/ai: 1.0.0-beta4
    drupal/ai_agents: 1.0.0-alpha1
    drupal/ai_image_alt_text: 1.0.0-alpha1
    drupal/ai_provider_anthropic: 1.0.0-beta2
    drupal/ai_provider_openai: 1.0.0-beta1
    drupal/ai_simple_provider_installer: 1.0.0-alpha3
    drupal/antibot: 2.0.4
    drupal/automatic_updates: 3.1.6
    drupal/autosave_form: 1.7.0
    drupal/better_exposed_filters: 7.0.2
    drupal/bpmn_io: 2.0.2
    drupal/captcha: 2.0.7
    drupal/checklistapi: 2.1.6
    drupal/coffee: 2.0.0
    drupal/core: 11.1.0-rc1
    drupal/core-composer-scaffold: 11.1.0-rc1
    drupal/core-project-message: 11.1.0-rc1
    drupal/core-recommended: 11.1.0-rc1
    drupal/crop: 2.4.0
    drupal/ctools: 4.1.0
    drupal/dashboard: 2.0.0-beta1
    drupal/date_augmenter: 1.1.1
    drupal/drupal_cms_accessibility_tools: 1.0.0-rc1
    drupal/drupal_cms_admin_ui: 1.0.0-rc1
    drupal/drupal_cms_ai: 1.0.0-rc1
    drupal/drupal_cms_analytics: 1.0.0-rc1
    drupal/drupal_cms_anti_spam: 1.0.0-rc1
    drupal/drupal_cms_authentication: 1.0.0-rc1
    drupal/drupal_cms_blog: 1.0.0-rc1
    drupal/drupal_cms_case_study: 1.0.0-rc1
    drupal/drupal_cms_content_type_base: 1.0.0-rc1
    drupal/drupal_cms_events: 1.0.0-rc1
    drupal/drupal_cms_forms: 1.0.0-rc1
    drupal/drupal_cms_image: 1.0.0-rc1
    drupal/drupal_cms_news: 1.0.0-rc1
    drupal/drupal_cms_olivero: 1.0.0-rc1
    drupal/drupal_cms_page: 1.0.0-rc1
    drupal/drupal_cms_person: 1.0.0-rc1
    drupal/drupal_cms_privacy_basic: 1.0.0-rc1
    drupal/drupal_cms_project: 1.0.0-rc1
    drupal/drupal_cms_remote_video: 1.0.0-rc1
    drupal/drupal_cms_search: 1.0.0-rc1
    drupal/drupal_cms_seo_basic: 1.0.0-rc1
    drupal/drupal_cms_seo_tools: 1.0.0-rc1
    drupal/drupal_cms_starter: 1.0.0-rc1
    drupal/easy_breadcrumb: 2.0.9
    drupal/easy_email: 3.0.3
    drupal/easy_email_express: 1.0.3
    drupal/easy_email_standard: 1.0.2
    drupal/easy_email_text_format: 1.0.2
    drupal/easy_email_theme: 1.0.0
    drupal/easy_email_types_core: 1.0.3
    drupal/easy_email_types_default: 1.0.1
    drupal/eca: 2.1.0-beta1
    drupal/eca_modeller_bpmn: 2.0.8
    drupal/eca_ui: 2.0.8
    drupal/editoria11y: 2.2.0-rc7
    drupal/field_group: 3.6.0
    drupal/focal_point: 2.1.2
    drupal/friendly_captcha_challenge: 0.9.18
    drupal/friendlycaptcha: 1.1.3
    drupal/geocoder: 4.25.0
    drupal/geofield: 1.62.0
    drupal/gin: 3.0.0-rc14
    drupal/gin_toolbar: 1.0.0-rc6
    drupal/google_tag: 2.0.7
    drupal/honeypot: 2.2.0
    drupal/jquery_ui: 1.7.0
    drupal/jquery_ui_resizable: 2.1.0
    drupal/key: 1.19.0
    drupal/klaro: 3.0.0-rc13
    drupal/klaro_js: 3.0.0
    drupal/leaflet: 10.2.29
    drupal/linkit: 7.0.0-alpha2
    drupal/login_emailusername: 3.0.0-rc1
    drupal/mailsystem: 4.5.0
    drupal/menu_link_attributes: 1.5.0
    drupal/metatag: 2.1.0
    drupal/pathauto: 1.13.0
    drupal/project_browser: 2.0.0-alpha6
    drupal/redirect: 1.10.0
    drupal/robotstxt: 1.6.0
    drupal/sam: 1.3.2
    drupal/search_api: 1.37.0
    drupal/search_api_autocomplete: 1.9.0
    drupal/search_api_exclude: 2.0.3
    drupal/selective_better_exposed_filters: 3.0.3
    drupal/seo_checklist: 5.2.2
    drupal/simple_search_form: 1.6.0
    drupal/simple_sitemap: 4.2.2
    drupal/sitemap: 2.0.0
    drupal/smart_date: 4.2.1
    drupal/svg_image: 3.2.0
    drupal/symfony_mailer_lite: 2.0.2
    drupal/token: 1.15.0
    drupal/token_or: 2.3.0
    drupal/trash: 3.0.9
    drupal/webform: 6.3.0-alpha2
    drush/drush: 13.3.3
    egulias/email-validator: 4.0.2
    enshrined/svg-sanitize: 0.20.0
    geocoder-php/common-http: 4.6.0
    geocoder-php/nominatim-provider: 5.7.0
    grasmash/expander: 3.0.1
    grasmash/yaml-cli: 3.2.1
    guzzlehttp/guzzle: 7.9.2
    guzzlehttp/promises: 2.0.4
    guzzlehttp/psr7: 2.7.0
    html2text/html2text: 4.3.2
    illuminate/collections: v11.34.2
    illuminate/conditionable: v11.34.2
    illuminate/contracts: v11.34.2
    illuminate/macroable: v11.34.2
    illuminate/support: v11.34.2
    itamair/geophp: '1.6'
    joachim-n/composer-manifest: 1.1.6
    laravel/prompts: v0.1.25
    league/container: 4.2.4
    league/html-to-markdown: 5.1.1
    masterminds/html5: 2.9.0
    mck89/peast: v1.16.3
    mtownsend/xml-to-array: 2.0.0
    nesbot/carbon: 3.8.2
    nikic/php-parser: v5.3.1
    openai-php/client: v0.10.3
    pear/archive_tar: 1.5.0
    pear/console_getopt: v1.4.3
    pear/pear-core-minimal: v1.10.16
    pear/pear_exception: v1.0.2
    phootwork/collection: v3.2.3
    phootwork/lang: v3.2.3
    php-http/discovery: 1.20.0
    php-http/guzzle7-adapter: 1.1.0
    php-http/httplug: 2.4.1
    php-http/message: 1.16.2
    php-http/multipart-stream-builder: 1.4.2
    php-http/promise: 1.3.1
    php-tuf/composer-stager: v2.0.0-rc6
    phpowermove/docblock: v4.0
    psr/cache: 3.0.0
    psr/clock: 1.0.0
    psr/container: 2.0.2
    psr/event-dispatcher: 1.0.0
    psr/http-client: 1.0.3
    psr/http-factory: 1.1.0
    psr/http-message: '2.0'
    psr/log: 3.0.2
    psr/simple-cache: 3.0.0
    psy/psysh: v0.12.6
    ralouphie/getallheaders: 3.0.3
    revolt/event-loop: v1.0.6
    sebastian/diff: 5.1.1
    simshaun/recurr: v5.0.2
    symfony/clock: v7.2.0
    symfony/console: v7.2.0
    symfony/css-selector: v7.2.0
    symfony/dependency-injection: v7.2.0
    symfony/deprecation-contracts: v3.5.1
    symfony/error-handler: v7.2.0
    symfony/event-dispatcher: v7.2.0
    symfony/event-dispatcher-contracts: v3.5.1
    symfony/filesystem: v7.2.0
    symfony/finder: v7.2.0
    symfony/http-foundation: v7.2.0
    symfony/http-kernel: v7.2.0
    symfony/mailer: v7.2.0
    symfony/mime: v7.2.0
    symfony/polyfill-ctype: v1.31.0
    symfony/polyfill-iconv: v1.31.0
    symfony/polyfill-intl-grapheme: v1.31.0
    symfony/polyfill-intl-idn: v1.31.0
    symfony/polyfill-intl-normalizer: v1.31.0
    symfony/polyfill-mbstring: v1.31.0
    symfony/polyfill-php81: v1.31.0
    symfony/polyfill-php83: v1.31.0
    symfony/process: v7.2.0
    symfony/psr-http-message-bridge: v7.2.0
    symfony/routing: v7.2.0
    symfony/serializer: v7.2.0
    symfony/service-contracts: v3.5.1
    symfony/string: v7.1.8
    symfony/translation: v7.2.0
    symfony/translation-contracts: v3.5.1
    symfony/validator: v7.2.0
    symfony/var-dumper: v7.2.0
    symfony/var-exporter: v7.1.6
    symfony/yaml: v7.2.0
    tijsverkoyen/css-to-inline-styles: v2.2.7
    twig/twig: v3.15.0
    voku/portable-ascii: 2.0.3
    webmozart/assert: 1.11.0
    willdurand/geocoder: 4.6.0
    wpai-inc/anthropic-sdk-php: 0.2.1
    yethee/tiktoken: 0.5.1

There is also drush pm-list, but unfortunatelly it is not possible to filter/group the output by projects by default, so it would display also submodules, which is probably not something we want.

I wrote a Composer script that generates this list in conjunction with drush pm:list. It requires Drupal CMS to have been installed already, but since this is a totally internal dev-facing script, I figure that's a safe assumption. The list is generated by our CI process and exposed as an artifact.

For whatever it's worth, now that we're at RC, I think I can safely say that every module used in Drupal CMS is approved by the track leads. It's true that some of them were also in the prototype, but the track leads have thoroughly removed any module they didn't want.

So the current list is canonical. It may continue to evolve, obviously, but the concern about prototype modules is moot now.

OK, I ended up abandoning doing this on CI, but I did make this generate a nice Markdown-formatted list of modules/themes/recipes that are depended upon, grouped by recipe. An example of the output: https://git.drupalcode.org/project/drupal_cms/-/blob/7c5e21a6994e8d3229f...

Stellar! Marking RTBC

Thanks, all. Merged into 1.x.

Automatically closed - issue fixed for 2 weeks with no activity.