If you’ve never had reason to disable any modules in your Adobe Commerce codebase, you may not have given much thought to how the process of enabling and disabling these packages is handled. You ought to have a good handle on the mechanics and their implications.
Whether modules are enabled, of course, determines if their code is operative in the site. Layout updates, event handlers, plugins, preferences … all of these will be rendered inert if a module is not currently enabled. Disabling modules is an effective way to render them inoperable without removing them from the site’s codebase or dependencies, which is a useful option in certain development and deployment scenarios. The enabled or disabled status of modules is tracked in app/etc/config.php.
The Magento CLI setup:upgrade command, in addition to its typical tasks like applying new schema and patches, will automatically enable all modules present in the codebase that are not already explicitly disabled in config.php. This automatic process, combined with how ubiquitous the upgrade command is in dev workflows, is why some developers may even be oblivious to the concept of enabled modules! It does make sense in many scenarios to let upgrade take care of updates and module enablement all at once; it’s appropriate when first installing third-party modules, or if your initial module code involves schema or patches that must be applied.
However, when initially bootstrapping your own custom module, it’s often more efficient to explicitly enable it instead.
bin/magento module:enable MyVendor_MyModule
This is a much quicker operation than setup:upgrade, particularly if the latter involves time consuming recurring updates.
As a final thought, you are putting app/etc/config.php under version control, right? You should not only do so, but also make sure the enablement (or disablement) of new modules is committed in this file along with the module code or Composer dependency. Don’t rely on setup:upgrade to automatically enable modules in your staging and production environments! Which modules are enabled and disabled is part of the state of your application, so for stability in all deployments, your versioned codebase should explicitly express this state.
Chris Nanninga
Director of Training and Development at SwiftOtter