Enabling a Module

Three places record a module: its files on disk, the modules array in app/etc/config.php, and the database.

Syntaxbin/magento module:enable [-c|--clear-static-content] Vendor_Module

A module can exist on disk and do nothing. Magento keeps a separate list of which modules are switched on, in app/etc/config.php. That is a PHP file returning an array, not JSON. Its modules key maps every known module name to 1 for enabled or 0 for disabled. The file is generated, so it does not declare strict types or follow module coding style.

What each command actually records

bin/magento module:enable Acme_Faq edits that array and nothing else. It then clears the cache and the generated classes, and prints a reminder to run setup:upgrade. No table is created at this point.

bin/magento setup:upgrade rescans app/code and vendor, writes every module it finds back into the array, applies declarative schema and runs data patches, recording each applied patch class in the patch_list table. A module that is not yet listed is written as enabled, so a brand-new module does not strictly need module:enable at all.

bin/magento cache:flush discards the cached merged configuration. In production mode, add bin/magento setup:di:compile and bin/magento setup:static-content:deploy.

What trips people up

app/etc/config.php is shared configuration and belongs in version control, unlike app/etc/env.php, which holds per-environment settings. Enabling a module locally is therefore a change for the whole team.

Example

Example · php
<?php
// app/etc/config.php - generated; module:enable rewrites the 'modules' array
return [
    'modules' => [
        'Magento_Store' => 1,
        'Magento_Theme' => 1,
        'Magento_Catalog' => 1,
        'Acme_Faq' => 1,
    ],
];

// $ bin/magento module:enable Acme_Faq
// The following modules have been enabled:
// - Acme_Faq
//
// To make sure that the enabled modules are properly registered, run 'setup:upgrade'.
// Cache cleared successfully.
// Generated classes cleared successfully. Please run the 'setup:di:compile' command to generate classes.
// Info: Some modules might require static view files to be cleared. To do this, run 'module:enable' with the --clear-static-content option to clear them.

When to use it

  • Switching on a module you have just created and confirming Magento recorded it.
  • Diagnosing a module that is present in app/code but invisible to the application.
  • Turning off a third-party extension without losing its data.
  • Making sure every environment enables the same modules by committing app/etc/config.php.

More examples

Checking what Magento thinks of a module

"Module does not exist" means Magento never found a registration.php for that name, which is a file-path or naming problem, not an on/off problem. "Module is disabled" means the files were found but the modules array holds a 0. Reach for this first when a route 404s or a class is not found: it separates the two failures in one command.

Example · shell
$ bin/magento module:status Acme_Faq
Acme_Faq : Module is enabled

$ bin/magento module:status Acme_Blog
Acme_Blog : Module does not exist

Turning a module off safely

Once a module is disabled its db_schema.xml is no longer read, so the next plain setup:upgrade removes the tables it declared. --safe-mode=1 takes a backup of that data during the upgrade; pair it with --data-restore=1 on the setup:upgrade that follows re-enabling the module. Use this on any environment where the module's data is not disposable.

Example · shell
$ bin/magento module:disable Acme_Faq
The following modules have been disabled:
- Acme_Faq

Cache cleared successfully.
Generated classes cleared successfully. Please run the 'setup:di:compile' command to generate classes.
Info: Some modules might require static view files to be cleared. To do this, run 'module:disable' with the --clear-static-content option to clear them.

$ bin/magento setup:upgrade --safe-mode=1

The order to run commands after deploying code

The commands are not interchangeable and the order matters: schema and data first, then generated code, then static files, then the cache. In developer mode generated code and static files are produced on demand, which is why the short list is enough there. Keep this sequence in the deploy script rather than in someone's memory.

Example · shell
# developer mode
bin/magento setup:upgrade
bin/magento cache:flush

# production mode
bin/magento maintenance:enable
bin/magento setup:upgrade --keep-generated
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
bin/magento cache:flush
bin/magento maintenance:disable

Discussion

  • Be the first to comment on this lesson.