Ability to disable modules outside config.php file

jakwinkler commented 1 year ago

Description

I do have a case where I'm about to change multiple Adobe Cloud code (3 instances) into one single code instance. There are 100 modules in the projects but 5 of them only on specific instasnces:

two on one instance
two on second instance
one on the third instance

I do not want to work with php bin/magento mod:disable / mod:enable CLI. I would like to be able to load additional env.config.php file (or whatever I can call it) that

checks for environment variables
if variables are set, config of that file is being merged to list of active modules

This way I can have one common code base, with 3 additional config files that are merged based on environment variables.

The reason is simple, it is related to Bootstrap.php file as there is no option to pass

public static function createConfigFilePool()
    {
        return new ConfigFilePool();
    }

anything to the config to be merged

Expected behavior

Add Something like:

public static function createConfigFilePool()
    {
        return new ConfigFilePool(
              getenv('env_modules') ? ['env_modules' => sprintf('%s.php' , getenv('env_modules'))] : []
         );
    }

Something like this will allow us to disable modules based on environment value.

Benefits

Ability to work on one code base and disable modules per environment without CLI operations to disable/enable modules.

Additional information

No response

Release note

No response

m2-assistant[bot] commented 1 year ago

Hi @qsolutions-pl. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release
For more details, review the Magento Contributor Assistant documentation.
Add a comment to assign the issue: @magento I am working on this
To learn more about issue processing workflow, refer to the Code Contributions.

Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

fredden commented 1 year ago

@qsolutions-pl It's a good idea to put store configuration in app/etc/config.php so that themes can be deployed without also needing a database. I imagine doing this may be difficult in the set-up you are proposing.

Whoever, config.php is a PHP file, and can contain arbitrary PHP code. The contents of this file shouldn't change on a production system. This file should be tracked as part of version control, so you may be able to put your own custom logic into the file to support your use-case. Be careful if going down this route as several Magento command-line actions will re-write the file.

I'd suggest that you put common libraries/modules into suitable Composer packages and maintain three repositories - one for each instance.

References: https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/files/config-reference-configphp.html https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/deployment/build-system.html https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/cli/configuration-management/export-configuration.html

magento / magento2