Contrib.social

Allow a module to be blocked from display on Project Browser

Open on Drupal.org →
Created on 23 August 2022, almost 3 years ago
Updated 31 May 2023, about 2 years ago

Problem/Motivation

There are reasons a module shouldn't appear in the Project Browser list
-It may be only used as a required dependency of another module (i.e. an API only)
-The module maintainer may not want it listed there
-The community may decide it is not appropriate to list it there

Steps to reproduce

Proposed resolution

For a maintainer choice:
-Create an option in the module.info.yml project_browser:false
or
-Create a file no_project_browser in the module root folder

For the community:
-Maintain a deny-list

Remaining tasks

  • ✅ File an issue about this project
  • ☐ Manual Testing
  • ☐ Code Review
  • ☐ Accessibility Review
  • ☐ Automated tests needed/written?

Slack discussion that initiated this issue:
@Warped: Would there be a use for a .no_project_browser file in a project root to prevent it from being shown in the project browser?
@chrisfromredfin: We are adding support for deny list for projects, so probably that would be the better way to handle exclusions.
@Warped: There are good reasons for either way. A maintainer might want to exclude a module that is only an API, and would be a dependency of another module, or that it is too complex for a non-programmer and they get too many support issues. Allowing maintainers to decide means less community involvement for maintaining a list. But there may be community reasons for a deny list. Maybe both are a good compromise?
@chrisfromredfin: I'd love it if you opened an issue about it. We could discuss at tomorrow's meeting. Something like "consider a project_browser: false in module.info.yml for maintainers to opt out" ??

✨ Feature request
Status

Active

Version

1.0

Component

Drupal.org changes

Created by

🇺🇸United States warped

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 2 years ago →
    🇺🇸United States chrisfromredfin Portland, Maine

    Though yes this is related, this is a bit of a different ask. This mostly comes from user confusion where "ctools" is the most installed module, but it's rarely installed by a non-developer. It would I think actually be a Drupal.org change to allow a flag like "is developer project" and then we have a default filter that filters OUT developer-only modules by default (but allow power users to opt in to showing all).

  • Comment 9 days ago →
    🇺🇸United States phenaproxima Massachusetts

    I would be on board with doing this as traits that could be used by existing sources. Maybe call them something like AllowListTrait and DenyListTrait, which explicitly reject projects with certain internal IDs.

  • Comment 9 days ago →
    🇺🇸United States phenaproxima Massachusetts

    I actually think we should broaden the scope here and give all sources these superpowers:

    • Sort projects into an arbitrary order (already doable, just implemented per-source rather than in the base class)
    • Show or hide specific projects by ID

    We could easily add these configuration options to ProjectBrowserSourceBase.

  • Comment 9 days ago →
    🇺🇸United States phenaproxima Massachusetts
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024