# Contrib modules/tools list **URL:** \ **Category:** Using farmOS\ **Created:** [February 16, 2023, 9:21am UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531 "2023-02-16T09:21:54Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [February 16, 2023, 9:21am UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/1 "2023-02-16T09:21:54Z")
Is there some place/page where contrib modules/projects/tools that extend the core farmOS functionality are listed? The only one I’ve stumbled upon is the ‘[Other modules](https://v1.farmos.org/development/projects/#other-modules)’ section on the old v1 documentation page. It could be quite useful to create a new one for modules/tools compatible with farmOS v2, especially that there are already quite a few of them. I started to collect modules I’ve found in a google spreadsheet, and at the moment it already contains over 50 modules. [farmOS v2 contrib modules - Google Sheets](https://docs.google.com/spreadsheets/d/1S4MAleGEWjZvOTPiLzCsOcq7ez5QnWaKj8iKx5P3Zm8/edit) When it comes to the best format and place to store the contrib project list, there could be created a github repo in which contrib modules/tools list could be stored as a json file(s). This approach would provide several benefits: - it should be quite easy to contribute (for example add a new module) through github ui, either by creating a pull request or an issue, - json file format and the list being publicly available from the internet would also allow for some integrations like: - automatically displaying the list on the documentation site, - creating custom source plugin for [Project Browser | Drupal.org](https://www.drupal.org/project/project_browser) which would allow installing new contrib modules from the drupal admin ui, without the need to manually execute composer commands. Any thoughts? Or maybe there already exists such list somewhere and I just didn’t find it? ---
**Author:** ![Symbioquine](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/symbioquine/32/284_2.png) [@Symbioquine](https://farmos.discourse.group/u/Symbioquine)\ **Post date:** [February 16, 2023, 3:42pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/2 "2023-02-16T15:42:10Z")
That’s awesome, thanks for putting that together! ---
**Author:** ![paul121](https://avatars.discourse-cdn.com/v4/letter/p/54ee81/32.png) [@paul121](https://farmos.discourse.group/u/paul121)\ **Post date:** [February 16, 2023, 6:29pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/3 "2023-02-16T18:29:23Z")
> [@wotnak](#): > > Or maybe there already exists such list somewhere and I just didn’t find it? Modules on [Drupal.org](http://Drupal.org) can say what “ecosystem” they are a part of. That is then used to build this farmOS ecosystem list: [https://www.drupal.org/project/farm/ecosystem](https://www.drupal.org/project/farm/ecosystem) But I agree, it would be nice to have another place like a repo to store this information. We don’t expect all modules to be listed on [Drupal.org](http://Drupal.org). And there is value in having a directory of more custom modules that aren’t necessarily designed for others to use, but are open source and can be referenced as examples or any other reason. Some way of tagging these subtleties would be nice 🙂 > [@wotnak](#): > > creating custom source plugin for [Project Browser | Drupal.org](https://www.drupal.org/project/project_browser) Thanks for sharing this! I did not know the project was this far along ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [February 16, 2023, 6:44pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/4 "2023-02-16T18:44:57Z")
This is great @wotnak! Thanks for compiling it! > [@paul121](#): > > And there is value in having a directory of more custom modules that aren’t necessarily designed for others to use, but are open source and can be referenced as examples or any other reason. Some way of tagging these subtleties would be nice 🙂 Yea I had a similar thought… any “official” list we have _must_ have some way of designating “true contrib” modules vs “custom” modules. The expectations are very different between those. “Contrib” means it is intended for general use. “Custom” means it is built for one specific group/user’s needs. Custom modules may have implicit assumptions that don’t apply to other instances (eg: hard-coding asset names/IDs into forms), and there is no guarantee that update hooks are provided. So at the very least I think the spreadsheet should have a “type” column for “contrib”, “custom”, “unknown”, etc… so that it is clear what the user’s expectations can be. > [@paul121](#): > > Modules on [Drupal.org](http://Drupal.org) can say what “ecosystem” they are a part of. That is then used to build this farmOS ecosystem list: [Ecosystem modules for farmOS | Drupal.org](https://www.drupal.org/project/farm/ecosystem) Anything published to [drupal.org](http://drupal.org) is considered “contrib”, and should therefore set the expectation that it is designed for general use and is well maintained. The other benefit of publishing to [drupal.org](http://drupal.org) is it makes it possible to translate the module via strings in [localize.drupal.org](http://localize.drupal.org). ---
**Author:** ![paul121](https://avatars.discourse-cdn.com/v4/letter/p/54ee81/32.png) [@paul121](https://farmos.discourse.group/u/paul121)\ **Post date:** [February 16, 2023, 6:51pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/5 "2023-02-16T18:51:22Z")
> [@mstenta](#): > > Anything published to [drupal.org](http://drupal.org) is considered “contrib” If we were to create such a github repo with this information… maybe we could use the [Drupal.org](http://Drupal.org) API (assuming this exists?) to find the farmOS ecosystem modules and auto-populate + update all of the “contrib” modules. This could then easily include things like latest versions and release dates of these contrib modules. ---
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [February 19, 2023, 11:52am UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/6 "2023-02-19T11:52:04Z")
I’ve created a repo with initial projects list in json format for easier experimentation. [GitHub - wotnak/farmos-community-projects: Community projects list for farmOS v2.](https://github.com/wotnak/farmos-community-projects) Currently used schema is described in [Define projects.json schema · Issue #2 · wotnak/farmos-community-projects · GitHub](https://github.com/wotnak/farmos-community-projects/issues/2). I’ve also done some initial exploration in the direction of providing a custom source plugin for [Project Browser](https://www.drupal.org/project/project_browser) module based on the projects list from the repo. [GitHub - wotnak/farm\_project\_browser](https://github.com/wotnak/farm_project_browser) ![image](https://global.discourse-cdn.com/free1/uploads/farm_os/original/2X/9/97e28a4d696face7a98d32e76b26542194ed4bea.png) ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [February 21, 2023, 1:33pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/7 "2023-02-21T13:33:20Z")
Amazing work @wotnak!! > [@wotnak](#): > > I’ve created a repo with initial projects list in json format for easier experimentation. [GitHub - wotnak/farmos-community-projects: Community projects list for farmOS v2.](https://github.com/wotnak/farmos-community-projects) Where would you prefer feedback? In this forum topic or in GitHub issues? Couple of quick thoughts here, to be reorganized/addresses later - and apologies if these sound critical - I mean them as a critique for ALL of us who may be helping to maintain this moving forward… 🙂 - If the end-goal is to list these modules on [farmOS.org](http://farmOS.org) (which we should!) then I do NOT think we should include custom modules/projects. Or, if we do, then they should be in a separate page or section that _explicitly_ states that we do NOT recommend installing them. These kinds of projects may be useful to refer to for other developers, but we do not want to create any expectations that they will work for end-users. In general, I think we should be very careful and intentional about which modules we list on [farmOS.org](http://farmOS.org) and what expectations we set. The risk is that end-users end up confused/frustrated when they think a module will do something and it doesn’t - or worse: it breaks their install. - With the above in mind, I wonder if we should establish a process of consent, whereby we _ask_ module maintainers if they want their module listed, along with a process for developers to propose additions. And make it clear to them that this means setting an expectation with the end-users about the stability of their project. Modules that we “recommend” on [farmOS.org](http://farmOS.org) should meet a certain set of quality standards, IMO. One of which should be: “this module cleans up after itself when it is uninstalled”. Otherwise we also need to educate end-users on how to test modules in a dev instance before installing them in a production instance, etc. There are a few modules _I_ created that are in this list, which I would NOT recommend anyone install. So just generally I’m worried about quality control and the expectations that we set. - I also worry: “who is going to maintain this?” History has proven that initiatives like this have a lot of interest in the beginning, but can quickly decay and become outdated/unmaintained if no one is staying on top of it. Automating it would be great, but there’s a lot of questions there as well. And I also don’t want anyone to feel _obligated_ to maintain it either. It’s unpaid work. But once we set this ball rolling, maintaining it becomes an obligation for the farmOS community (assuming it becomes part of [farmOS.org](http://farmOS.org)). I’m just raising that as a consideration - not to dissuade. 🙂 The “keep it simple” strategy (eg: keeping the list small and focused on contrib modules that are intended for wider use) is one way to minimize this burden. - One idea: maybe we have some additional attribute that let’s maintainers set expectations with a 1-5 scale… something like: 1 = don’t use this module except as an example for developers, 5 = this is actively maintained and intended for general use. Worth noting [drupal.org](http://drupal.org) has a similar system for denoting the maintenance status of modules. - I notice that the `src` attribute sometimes points to _sub-modules_ within a single repo (eg: [https://github.com/wotnak/farmos-community-projects/blob/95e9024ac35b23155626e4812e425bbe8903514e/projects.json#L6](https://github.com/wotnak/farmos-community-projects/blob/95e9024ac35b23155626e4812e425bbe8903514e/projects.json#L6)). This feels weird to me. I do like the idea of highlighting different modules within a repo, but it seems like this current approach will be hard to use/maintain. > [@wotnak](#): > > I’ve also done some initial exploration in the direction of providing a custom source plugin for [Project Browser](https://www.drupal.org/project/project_browser) module based on the projects list from the repo. [GitHub - wotnak/farm\_project\_browser](https://github.com/wotnak/farm_project_browser) This is very cool! I haven’t used the Project Browser module myself. This is something to keep an eye on - and maybe it will be worth considering for inclusion in farmOS core in the future. I tend to be _very_ careful about adding additional modules/dependencies to farmOS core, though (having spent a good chunk of my time over the past 10 years BLOCKED on major upgrades because of them). If we end up considering this for farmOS core I’ll have a lot more questions… 🙂 All the critiques aside, THANK YOU for spending time on this! It is really important that we start to organize what the community is working on - so that everyone can see what’s happening! It’s just the little details and considerations to figure out next. Broadly speaking I think this is a great idea. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [February 21, 2023, 1:40pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/8 "2023-02-21T13:40:27Z")
> [GitHub - wotnak/farm\_eggs: Provides functionalities for tracking egg harvests.](https://github.com/wotnak/farm_eggs) This one also jumps out at me and raises a question… First of all, WOW! I didn’t even know that you were working on a 2.x port of this module. That’s great! Second of all, because this module is maintained by the farmOS community (it is part of the [farmOS · GitHub](http://github.org/farmOS) GitHub organization), we should not recommend anyone install a fork of it, because it is creating a potential future conflict when we have the “official” 2.x version available. Hypothetically (having not actually looked at your 2.x version’s changes): what if the fork’s changes are not accepted, and instead a different approach is taken? We then have two different modules that share the same `farm_eggs` namespace - and if anyone installed the fork, but wants to switch to the official, their is potential pain/complexity in doing so. Side note: can we talk about your fork sometime soon? 😃 ---
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [February 21, 2023, 3:50pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/9 "2023-02-21T15:50:56Z")
List of custom modules/projects could be helpful as a reference for developers but also for end users to see what’s possible with farmOS, but I agree that there need to be a clear warning that those are not recommended to install and can cause problems. Putting them on a separate page with a warning on top would be probably the best option. We could also keep it in the repo as a separate list to further emphasize that these are not the same as contrib ones. When it comes to contrib modules, I think we could require them to be published on [drupal.org](http://drupal.org) to be included in the list. This would ensure every contrib module is installable using composer and can have translations contributed using [localize.drupal.org](http://localize.drupal.org). I also really like @paul121 ideas around automating some parts of the list maintenance [Query drupal.org for contrib projects · Issue #4 · wotnak/farmos-community-projects · GitHub](https://github.com/wotnak/farmos-community-projects/issues/4). Building on it, we could adopt the following workflow: - new contrib module is published to [drupal.org](http://drupal.org) and assigned to farmOS ecosystem, - it is automatically added to the list, - github issue is created for manual verification/review of the module, - if it is verified to follow stability/best practices guidelines, `recommended` property is manually set for it to true. On the site, we could then display: - list of recommended modules (ones with `recommended` property manually set), - warning that the following contrib modules were not verified, - list of the remaining contrib modules (ones without `recommended` property set), - link to the separate page with custom modules. This approach would allow for adding new contrib modules without maintainers time being the blocking factor, but also set clear expectations which modules are vetted and recommended. ---
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [February 21, 2023, 3:52pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/10 "2023-02-21T15:52:29Z")
Yeah, at first it was supposed to be only a simple v2 port, mainly for my own use, but later I also implemented some feature request ([1](https://github.com/farmOS/farm_eggs/issues/1), [2](https://github.com/farmOS/farm_eggs/issues/5), [3](https://farmos.discourse.group/t/eggs-module-installation-development/645)) I thought could be useful and then started changing/adding more things and have [plans](https://github.com/users/wotnak/projects/1) for even more. It also became a bit of a playground for me for getting familiar with and testing ideas around quick forms and general farmOS apis. At this point I should probably just change the namespace of my fork and maybe contribute back parts of it to the main repo. > [@mstenta](#): > > Side note: can we talk about your fork sometime soon? 😃 Sure. We can chat on the farmOS [element.io](http://element.io) chat, I can also drop by on the dev call this week, or we can schedule a one on one call. ---
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [February 21, 2023, 4:54pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/11 "2023-02-21T16:54:44Z")
> [@mstenta](#): > > This is very cool! I haven’t used the Project Browser module myself. This is something to keep an eye on - and maybe it will be worth considering for inclusion in farmOS core in the future. I tend to be _very_ careful about adding additional modules/dependencies to farmOS core, though (having spent a good chunk of my time over the past 10 years BLOCKED on major upgrades because of them). If we end up considering this for farmOS core I’ll have a lot more questions… 🙂 Project Browser is one of the Drupal core strategic inititives [Client Challenge](https://www.drupal.org/about/core/strategic-initiatives/project-browser), so it should be well maintained, and it is planned for inclusion in Drupal core so farmOS will probably gain it as an indirect dependency at some point even if we won’t use it. ---
**Author:** ![paul121](https://avatars.discourse-cdn.com/v4/letter/p/54ee81/32.png) [@paul121](https://farmos.discourse.group/u/paul121)\ **Post date:** [February 21, 2023, 6:49pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/12 "2023-02-21T18:49:49Z")
I agree with all of @mstenta sentiments! It’s better to be cautious with the expectations we set here. I’m optimistic that such a list wouldn’t be too hard to maintain, especially if we go with an “opt-in” and set nice schemas/standards for what is expected to be contributed to the module (as already being proposed!) As far as the [farmOS.org](http://farmOS.org) modules list, perhaps it would be best to start with only the “recommended” contrib modules. IMO I think it’s quite important to have a list of these on [farmOS.org](http://farmOS.org). These should also be easiest to maintain - once it is “recommended” I think we assume it will be there for awhile. > [@mstenta](#): > > One idea: maybe we have some additional attribute that let’s maintainers set expectations with a 1-5 scale… I really like this concept! Especially if the “description” is exposed to users, not the number. One tier could be “well maintained with external funding”… 🙂 Could this be combined with a more generic `recommendations` or `considerations` text as well? Some modules might be well maintained also but require a separate API key, service or other special consideration that is best described in a quick sentence. The more we talk about contrib modules, the more I think we should have a dedicated list for them. It seems that they could even have a slightly different schema too. So.. with [farmOS.org](http://farmOS.org) in mind, what about this for next steps: - Continue thinking on a schema for contrib/custom modules (maybe consider two separate schemas) - Once we have a good schema, create a repo in the farmOS organization with _only recommended contrib_ modules to start. Also add these to [farmOS.org](http://farmOS.org). - @wotnak and others can continue hacking on other contrib/custom module features in a fork/separate repo - Add additional features to core farmOS list & [farmOS.org](http://farmOS.org) in separate feature requests over time I think it would be really valuable to have lists of both contrib and custom modules (custom modules/other farmOS related projects) on [farmOS.org](http://farmOS.org). But starting slow with good contrib modules makes most sense! ---
**Author:** ![paul121](https://avatars.discourse-cdn.com/v4/letter/p/54ee81/32.png) [@paul121](https://farmos.discourse.group/u/paul121)\ **Post date:** [February 21, 2023, 6:52pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/13 "2023-02-21T18:52:14Z")
> [@wotnak](#): > > Building on it, we could adopt the following workflow: I like this workflow, however I do think that none of this should be “fully automated”. A module shouldn’t be added to the list unless an issue/pr is merged by maintainers. Especially if that goes directly to [farmOS.org](http://farmOS.org) people could spam it by creating nonsense projects. But we should definitely explore using automation to create those issues/prs as described! 🙂 > [@wotnak](#): > > Project Browser is one of the Drupal core strategic inititives I’m curious if we could leverage the project browser UI on our “Install modules” form… we may not need the complexity of project browser for actually downloading and installing something, but just the UI would be amazing to have. Thanks for starting & pursuing all of this @wotnak- would love to chat more on the community dev call this week ! ---
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [February 22, 2023, 4:16pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/14 "2023-02-22T16:16:59Z")
I pushed some changes to the repo: - added initial json schema for the list, - [farmos-community-projects/schema.json at main · wotnak/farmos-community-projects · GitHub](https://github.com/wotnak/farmos-community-projects/blob/main/schema.json) - [JSON Schema Viewer](https://json-schema.app/view/%23?url=https%3A%2F%2Fraw.githubusercontent.com%2Fwotnak%2Ffarmos-community-projects%2Fmain%2Fschema.json) - adjusted the list to match the schema, - moved modules not published on [drupal.org](http://drupal.org) to separate custom.json file. Also updated the pr to [farmOS.org](http://farmOS.org): - adjusted the code to be compatible with the list schema changes, - improved the look of the page, replaced simple list with grid of cards, - added examples of how additional info (recommendations/considerations) could be displayed. [https://deploy-preview-67--gracious-brattain-bdd606.netlify.app/community/modules](https://deploy-preview-67--gracious-brattain-bdd606.netlify.app/community/modules) ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [February 23, 2023, 5:34pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/15 "2023-02-23T17:34:07Z")
Notes from dev call 2023-02-23: Questions: - Should we list “core” modules? - Some way of categorizing? - Forum category, each topic is for a specific module, comments for reviews? Potential flags: - Core/contrib/custom - Stability status - Whether or not requires Composer - Flag that it requires non-free services (eg Google API key) - Number of users - Available on Farmier? ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [February 25, 2023, 8:42pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/16 "2023-02-25T20:42:56Z")
> [@wotnak](#): > > Building on it, we could adopt the following workflow: > > - new contrib module is published to [drupal.org](http://drupal.org) and assigned to farmOS ecosystem, > - it is automatically added to the list, > - github issue is created for manual verification/review of the module, > - if it is verified to follow stability/best practices guidelines, `recommended` property is manually set for it to true. I like this workflow @wotnak ! > [@paul121](#): > > I like this workflow, however I do think that none of this should be “fully automated”. A module shouldn’t be added to the list unless an issue/pr is merged by maintainers. Especially if that goes directly to [farmOS.org](http://farmOS.org) people could spam it by creating nonsense projects. But we should definitely explore using automation to create those issues/prs as described! 🙂 All good points! > [@paul121](#): > > I’m curious if we could leverage the project browser UI on our “Install modules” form… It is a nice UI, I agree. I am still hesitant, but maybe I can be convinced. 🙂 In either case let’s keep these as two separate initiatives… the higher priority right now is getting contrib modules listed on [farmOS.org](http://farmOS.org). ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [January 15, 2024, 11:40am UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/17 "2024-01-15T11:40:32Z")
This fell off my radar until I was looking at open PRs this morning and found [Contrib modules/projects listing page by wotnak · Pull Request #67 · farmOS/farmOS.org · GitHub](https://github.com/farmOS/farmOS.org/pull/67) @wotnak I forget what the current status is - maybe we could restart the conversation? It would be awesome to get at least a simple first step page up on [farmOS.org](http://farmOS.org) that shows modules! Happy to help make a strategy and/or decide on the steps/phased approach via chat or call sometime if that helps! ---
**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\ **Post date:** [January 16, 2024, 3:20pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/18 "2024-01-16T15:20:59Z")
Ah, completely forgot about this. Maybe the first step could be to just create a static markdown page, on which we could manually list contrib modules. It would quickly bring some value, and can be improved later. When it comes to the end goals, I would like to create something like the [Nuxt Modules page](https://nuxt.com/modules): - the modules are added in a [separate repo](https://github.com/nuxt/modules) in which they are described in yaml files, one file per module - then in github action json file is built, which is later used to render modules on the listing page - in the modules repo we could also add some automated actions that would: - update modules metadata - for example short description (from module .info.yml file) or maybe installs count fetched from [drupal.org](http://drupal.org) api or stars fetched from [drupal.org](http://drupal.org) and [github.com](http://github.com) depending on where given project is hosted - scan [drupal.org](http://drupal.org) to find new contrib modules that were marked as in the farmOS ecosystem and automatically create pr to add them to the repo - [https://www.drupal.org/api-d7/node.json?type=project\_module&field\_project\_ecosystem=2208549](https://www.drupal.org/api-d7/node.json?type=project_module&field_project_ecosystem=2208549) ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [January 16, 2024, 3:35pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/19 "2024-01-16T15:35:21Z")
> [@wotnak](#): > > Maybe the first step could be to just create a static markdown page, on which we could manually list contrib modules. It would quickly bring some value, and can be improved later. I completely agree! This would be a great first step, and wouldn’t be too hard to maintain for as long as we need to. PS: Happy cake day! 🍰 😄