Add "Disable Add new module page" option to settings page

Created on 17 May 2023, over 1 year ago
Updated 31 May 2023, over 1 year ago

Problem/Motivation

The Drupal Core "Add new module" feature is a menu option on the "Extend" menu. It offers the option to add a module to the site from a URL or through an upload. It does not use Composer, so seems at odds with the Project browser approach.

This menu could be confusing for novice Drupal site builders, as it is not obvious that it is unrelated to the Project browser, and that dependencies will not be managed for modules added in this way.

Steps to reproduce

Open the Extend menu on any D8+ site. Click on "Add new module".

Proposed resolution

Ultimately this option should be removed from Drupal core, or at least not available on the default menu system. Issue 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active is open for this.

As an interim measure, consider adding a new module that simply disables the "Add new module". The module could go further, and prevent access to the Add new module page, but this seems excessive since the goal is simply to prevent confusion.

After discussion, the preferred option seems to be adding a checkbox to the settings page, and disabling the "Add new module" page if it is checked.

I'm unsure whether the module should be a sub-module of Project browser, or an independent project.

It would be useful for the module to be enabled when the DrupalPod link opens so that new users trying out Project Browser for the first time aren't confused by the menu option.

Remaining tasks

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

Fixed

Version

1.0

Component

User experience

Created by

🇮🇪Ireland lostcarpark

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

Comments & Activities

  • Issue created by @lostcarpark
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • @lostcarpark opened merge request.
  • 🇮🇪Ireland lostcarpark

    I have created a simple module called "Disable add new moldule" as a sub-module.

    I used a RouteSubscriber to deny access to the "/admin/modules/install" route. I had hoped this would hid the menu, since normally the menu system will hide menus you don't have access to, but I think the admin user has access to all menus.

    Instead I used "hook_menu_links_discovered_alter" to remove any menu items with the route.

    I also added a functional test to verify access is denied to the Add new module page, and that uninstalling the module restores access.

    I considered adding a test that the menu was removed, but I don't think Add new module appears on any menu unless you have Admin Toolbar enabled, and I didn't want to add a test that depends on a contrib module.

  • Status changed to Needs review over 1 year ago
  • 🇮🇪Ireland lostcarpark

    One question to consider is should this be a sub-module, or just a setting in the main project browser modules? Or perhaps even just decide that .tar modules are incompatible with PB and disable the page when PB is enabled.

    Advantages of merging: Keeps everything self contained.

    Advantages of separate module: Module only needs to do one thing. When .tar functionality gets removed from core, easier to remove from PB.

    Thoughts?

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • 🇮🇪Ireland lostcarpark

    After discussion with @chrisfromredfin and @timplunkett on Slack, I have moved the functionality into the Project Browser module. I've added an option to the Project browser settings, enabled by default.

    TODO:

    At present, after changing "Disable add new menu" setting, it is necessary to rebuild cache for the changes to take effect.

    Add additional tests to test for changing setting.

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • 🇮🇪Ireland lostcarpark

    I tried various methods of clearing partial cache to make "Add new module" page show after changing the setting. I could get the menu item to appear. However, I was unable to find a cache to clear to make the page accessible. At present, I am using drupal_flush_all_caches();, which is a bit heavy handed, but it does avoid adding new dependency injection, so will make it easier to remove this feature when the "Add new module" page gets removed in Drupal core.

    Still need to add some tests for the settings page.

  • 🇮🇪Ireland lostcarpark

    Updated issue title and description to reflect that this is now a setting in the PB module, not a separate module.

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • 🇮🇪Ireland lostcarpark

    Added test to verify that unchecking the "Disable add new module" enables the Add new module page, and that re-checking it disables the page again.

    I think this is ready for review.

  • 🇪🇸Spain fjgarlin

    I tested via drupalpod and the functionality is the expected one.

    I made a few comments in the code, mostly about which caches to clear (if any). As they are mostly questions rather than asking for changes (I guess it depends on the answers) I'm leaving the issue status as it is now.

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Status changed to Needs work over 1 year ago
  • 🇪🇸Spain fjgarlin

    I added some really minor suggestions, just small clean-up and variable renaming, but they are really minor. If you even feel that they're not needed please say so.

    I also re-tested things via drupalpod, and found a weird behavior:
    * When checking the disable checkbox, things work as expected. The link to install new modules shows before the change, and does not show after the change.
    * When unchecking the disable checkbox, things don't change. The links to install new modules does not show before the change, and still does not show after the change.

    Obviously, this is due to not clearing all caches now, but I still think it's the way to go, so it seems like we might need to add something more so that both scenarios work as expected.

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Status changed to Needs review over 1 year ago
  • Status changed to Needs work over 1 year ago
  • 🇪🇸Spain fjgarlin

    We still need to address the case where the link won't show back when unticking the checkbox.

    We also need to clear the render cache. I've been testing and adding this line fixes the issue, we just need to add the service via dependency injection.
    \Drupal::service('cache.render')->invalidateAll();

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Status changed to Needs review over 1 year ago
  • 🇮🇪Ireland lostcarpark

    Thanks! I've added the render cache invalidation.

  • Status changed to RTBC over 1 year ago
  • 🇪🇸Spain fjgarlin

    Great. I've tested multiple times and reviewed the code a few times as well. I'm going to mark it RTBC.
    Thanks so much for this feature!

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • 🇺🇸United States chrisfromredfin Portland, Maine

    Double-checked, reviewed, and tested in DrupalPod -- and love it!

  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Status changed to Fixed over 1 year ago
  • 🇺🇸United States chrisfromredfin Portland, Maine
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024