Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-12006

Disabled Extensions with Modules can break the ACP/UCP/MCP

    Details

    • Type: Bug
    • Status: Unverified Fix
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1.0-a1
    • Fix Version/s: 3.1.0-a3
    • Component/s: Extensions
    • Labels:
      None

      Description

      If an enabled extension is disabled it can cause the ACP (and probably the MCP, UCP too) to fatal error.

      This happens if the disabled extension has ACP modules, and the module is the first-top level module on the ACP page.

      Example, an extension has its own ACP module to ACP_CAT_DOT_MODS. It is the first or top level module assigned to ACP_CAT_DOT_MODS, so when that ACP tab is loaded, the page fails. The module is still loaded, but the data it is looking for is no longer accessible, so you get errors notices about undefined indexes, etc.

      Likewise, even if your Module is not at the top of a module management tree, a disabled extension leaves behind raw lang vars of its module names in the ACP, and if you click on one of those links to that module, you get the broken module page.

      When an extension is disabled, you should not see any artifacts of its existence in the board - including its ACP/MCP/UCP modules.

        Issue Links

          Activity

          Hide
          nickvergessen Joas Schilling added a comment -

          I think the modules should be disabled

          Show
          nickvergessen Joas Schilling added a comment - I think the modules should be disabled
          Hide
          nickvergessen Joas Schilling added a comment -

          After some investigation, I think the best thing here is, to advice the extension authors to use the phpbb\extension\base::disable_step() Method to manually disable modules.
          Looking at the DB, there is no way to found out, which migration added a certain module, so having the author to manually do that seems like the better solution to me.

          However this causes a problem with re-enabling. Because one would need to manually overwrite enable_step() step aswell, which could then have strange results on initial enabling of the extension or while "updating" one.

          Show
          nickvergessen Joas Schilling added a comment - After some investigation, I think the best thing here is, to advice the extension authors to use the phpbb\extension\base::disable_step() Method to manually disable modules. Looking at the DB, there is no way to found out, which migration added a certain module, so having the author to manually do that seems like the better solution to me. However this causes a problem with re-enabling. Because one would need to manually overwrite enable_step() step aswell, which could then have strange results on initial enabling of the extension or while "updating" one.
          Hide
          ..::Frans::.. ..::Frans::.. [X] (Inactive) added a comment -

          How about adding a field tot the modules table that holds the extensions name/path for example?

          Show
          ..::Frans::.. ..::Frans::.. [X] (Inactive) added a comment - How about adding a field tot the modules table that holds the extensions name/path for example?
          Hide
          EXreaction EXreaction [X] (Inactive) added a comment -

          I think it would be better to have a new auth type option added for the module than have them manually enable/disable them.

          E.g. acl_a_foo && ext_foo_bar

          Show
          EXreaction EXreaction [X] (Inactive) added a comment - I think it would be better to have a new auth type option added for the module than have them manually enable/disable them. E.g. acl_a_foo && ext_foo_bar
          Hide
          nickvergessen Joas Schilling added a comment -

          sounds like a good idea (maybe auth needs a rename at any day)

          Show
          nickvergessen Joas Schilling added a comment - sounds like a good idea (maybe auth needs a rename at any day)

            People

            • Assignee:
              EXreaction EXreaction [X] (Inactive)
              Reporter:
              VSE Matt Friedman
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development