The bin/magento setup:upgrade Command will Enable Non-Enabled modules

[astorm]

Preconditions

1. Magento installed via composer --create-project method, confirmed 2.1.3, 2.1.5, 2.1.6

Steps to reproduce

1. Create a new module in app/code ($ pestle.phar magento2:generate:module AbcCorp Testbed 0.0.1
2. Run php bin/magento setup:upgrade
3. Examine app/etc/config.php

Expected result

1. AbcCorp_Testbed should not appear in app/etc/config.php

Actual result

1. AbcCorp_Testbed appears in app/etc/config.php, and is enabled

It's a reasonable developer expectation that setup:update should not enable modules that were not previously enabled. This bug came from real world interactions with working developers who hit this bug. This bug caused unexpected Setup Upgrade code to run, and resulted in lost real world working billable hours.

[alankent]

The reason for the current behavior is:

• If you install Magento for the first time, you expect all the modules to be turned on by default.
• If you purchase and install a new extension, you expect it to be installed and turned on by default.
• If you upgrade from say 2.1 to 2.2 and there are new modules important to CE, you expect them turned on by default.

Bottom line is I think there are more use cases where you want new modules turned on by default than turned off by default. Is it in this case more of a question of "if I am half way through creating something under app/code, I don't want it turned on until I have finished, otherwise things break". That is more setup:upgrade ideally should not recognize it as a module at all (don't add to config.php until its complete). Then when its "done", then turn it on. (And no, I don't have a definition of "done" in my mind yet.)

[alankent]

To be more precise, do you think the problem is modules are being picked up and turned on by default, or is the problem that the module is being recognized as module before it is ready for use?

It would be great to get a bit better insight into the original root cause of the problem. I can see that using 'Composer require' and then having upgrade not turn on a module (you have to do extra steps) would also be confusing to people (especially for CE upgrades). So it would be helpful to understand the original problem as to why someone wanted a new module turned off. (My example was I had a half built module that did not load yet - caused bin/magento to break for me. So I can believe there is a problem here worth thinking about.)

[lfolco]

I think that it's just not clear that running setup:upgrade will enable any module that happens to live in app/code that had not been explicitly enabled/disabled. I discovered this when I downloaded a module to take a look at it, put it in app/code (I had an IDE project open), and then ran setup:upgrade for a different module, and all of a sudden the downloaded module was enabled and the database scripts were run.

As a developer, I would prefer to explicitly enable/disable modules rather than have a catch-all mechanism. Or a flag on setup:upgrade --disable-auto-enable or something along those lines.

[korostii]

It would be nice to see the following:

• just the composer modules (placed under vendor) enabled by default (since you must've explicitly installed those via composer already, and something published through composer is more likely to be ready to use)
• and have the local ones under app disabled until an explicit bin/magento module:enable command is executed (since these are the user's own handwritten modules, and he knows better when they're ready).

Surely, such a separation can be done?

[astorm]

@alankent

1. A user adds a module to their app/code folder but does not enable it (because they don't want it enabled)

2. Developer does something unrelated to enabling modules.

3. Yet, somehow, a module is enabled

That's just wrong behavior. Your system fails to honor the implicit contract of the module:enable and module:disable commands. Your system fails to honor the intentions of its users.

If you install Magento for the first time, you expect all the modules to be turned on by default.

No. I, and other users, would not expect a module that's not part of Magento to be enabled by the installer. I'd expect the installer to know which modules it needed and install them, and then potentially offer to install any extensions it sees but doesn't know about.

If you purchase and install a new extension, you expect it to be installed and turned on by default.

No. I, and other users, would expect whatever system I used to install the extension to also enabled the extension I just installed, and only that extension.

If you upgrade from say 2.1 to 2.2 and there are new modules important to CE, you expect them turned on by default.

No. I, and other users, would expect the upgrade process to look at the list of extensions currently enabled, as well as any new extensions added by 2.2, and enable them.

Those three points are just -- weird. To have made an expedient choice with some side effects like this is one thing, and a part of software development. But to double down on that choice's negative side effects, to sell that it's the right behavior, as though the problem can't be fixed?

Just weird.

[bvboas]

I think @alankent is right here.

How many times did we tell Windows to index the file we just copied from an external drive?

How many times did we install an app on a MAC by drag-n-drop and didn't expect macOS to associate an file extension?

How many times did we created an email account and went to the options to enabled it?

I don't think is reasonable to expect that when you place code inside a dir that is used as extension location, to nothing happen when you say to the software. "Please update".

I think the current behavior is the expected one. Additional options can be added to exclude packages, or similar options...

[lfolco]

Currently, the only way to make sure that non-enabled (but not disabled) modules do not run their setup scripts is to enable the module, then disable it. At the very least, it would be nice to have the option to immediately disable a module without having to enable it first (currently you get a "No modules were changed." message).

[bh-ref]

I encountered the same problem some time ago: #2622

We switched our workflow since then: if there is a Magento update with new modules, we run setup:upgrade on our development systems which adds the module to app/etc/env.php. If we decide to not use the module, we let the module entry there, but turn it from 1 to 0:

<?php
return array (
  'modules' => 
  array (
    ....
    'Legit_Module' => 1,
    'Unwanted_Module' => 0,
   ...
  ),
);

If we deploy this code base to the productive environments, the update / setup scripts won't be executed. We use this workflow for Magento updates and extensions we maybe want to be enabled on development systems, but not on the productive systems (so we maintain different app/etc/env.php).

But to be honest, I do not know how well this works with updates via composer, we always use the compressed archives for updating Magento.

And I totally see why developers see the current behavior of app/etc/env.php as weird. I seems it boils down to the question: who is installing modules? A technically savvy user or someone who is thankful that he has not to take more actions for the module to be enabled?

[rparsi-commer]

Is is possible to disable a custom module via its' etc/module.xml file?