the new config.php approach

[tzyganu]

I've seen that in the latest alpha versions there is no more local.xml. Instead there is a config.php that contains the db credentials (and others).
I've also seen that there is not more active attribute in the module.xml of every module. Instead this functionality was moved to the same config.php mentioned above.
I see a possible issue with this approach.
Since config.php contains the db credentials, this file is not going to be versioned, but the list of enabled/disabled modules should be versioned.
In the current implementation, each time I create a new module and want to deploy it, after getting the code from the versioning system I have to manually edit the config.php file from the instance where I'm deploying to add declare my new module.

How about putting the module list in a separate file modules.php?.. that can look like this:

return array (
    'Magento_Core' => 1,
    'Magento_Authorization' => 1,
    'Magento_Store' => 1,
    ....
 );

and in the config.php just get the modules like this:

'modules' => require_once 'modules.php';

I know that the list of modules is generated on install. This means that in the approach I'm proposing, the setup script needs to check if modules.php exists. If it does, move along, if not create it.

Does this make sense?

[pavelnovitsky]

👍

[barbazul]

+1
El 12/12/2014 05:36, "Pavel Novitsky" notifications@github.com escribió:

[image: 👍]

—
Reply to this email directly or view it on GitHub
#800 (comment).

[antonmakarenko]

When we refactored local.xml into config.php, we considered breaking down each segment into a separate file, but didn't implement it (just yet) under assumption that including one PHP-file will work faster than including multiple files. It could be a big deal, since this operation is not cached (you can have opcode caching though).

But local.xml was not versioned either. Moving list of modules to deployment configuration made the problem of versioning just more evident.

The good news is that there are ways to customize deployment configuration:

1. Provide a custom file (which you can have under version control or whatnot)

# in httpd.conf or .htaccess
SetEnv "MAGE_CONFIG_FILE" staging.php
SetEnv "MAGE_CONFIG_FILE" live.php

2. Provide an array with override values

# in an entry point script, index.php
$params = $_SERVER;
$params['MAGE_CONFIG'] = ['modules' => ['your list of modules goes here...']];
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $params);
/** @var \Magento\Framework\App\Http $app */
$app = $bootstrap->createApplication('Magento\Framework\App\Http');
$bootstrap->run($app);

[buskamuza]

@tzyganu , additionally to status of a module, config.php stores sequence of the modules basing on "sequence" section from module.xml, so ideally config.php should not be updated manually. It's a temporary solution, until we have a separate setup tool for enabling/disabling modules.

How do you think, if such tool would exist, would you need to keep this file under version control? From your description, it still looks necessary, as it's easier to deploy the file with code base than to run some tool additionally to deploying files. But just in case want to be sure about it.

[tzyganu]

@antonmakarenko

Moving list of modules to deployment configuration made the problem of versioning just more evident.

I don't understand this. Before, the information if a module is enable d or disabled came from the module.xml file, which was part of a module. There was not versioning problem.

@buskamuza I was not aware that this was a temporary solution. Indeed if there is/will be a tool that allows module status manipulation there is no need to version the list of installed modules.

[buskamuza]

Thanks, @tzyganu . I can't promise anything, but at least we have a use case now :)

[alankent]

We are endeavoring to use Composer to add modules. Ideally you should be able to automatically assemble a site from a composer.json file with minimal changes afterwards. Zero would be nice! If enable/disable flags are inside the module directory, it creates issues for example if you want to update the module with the next patch level. It is cleaner to have any file that is a part of the module (any file versioned with the module) not need to be changed at a site. The enable/disable flag is intended to be changed at a site, so has been moved out of the module/composer package. That way a composer update will not flip the value of enable/disable by mistake.

[tzyganu]

@alankent. I'm not questioning your motives for taking this approach. I'm all on board with it. It makes sense. I'm just trying to identify possible issues I may face as a developer that works on a simple project and receives a request to add a new module that does something. I'm trying to compare the current deploy strategy I have for Magento 1 (I'm not saying I have the best deploy strategy) and how it could work on Magento 2. From my point of view, having the list of modules in the same file as the db credentials seamed like and issue.

[antonmakarenko]

@tzyganu

Let's compare Magento 1 VS Magento 2 deploy strategy.

In Magento 1, the list of enabled modules was in a separate file app/etc/modules/Mage_All.xml plus it searched for all other xml-files at app/etc/modules/*.xml. These files were merged together with local.xml -- so technically, it was all deployment configuration. So in order to enable a module, the developer had to add a file to app/etc/modules or edit Mage_All.xml.

In Magento 2, the intended use cases:

• either do it through Setup CLI - it will manage the config.php for you. The config.php is not under version control
• or maintain your own deployment configuration file under version control
• or inject values through environment (can be combined with both above approaches)

Considering the strategy you described, I'd recommend to have your own configuration file under version control, but inject DB credentials through environment.

If you want a separate file -- do you want it only for list of modules or a separate file for each segment (encryption key, session config, DB config, caches config, modules...)? Can you provide a use case of your deploy strategy when keeping them in separate files matters?

[tzyganu]

@antonmakarenko
Thanks for the explanation. Now it's starting to get clear. It seams that I understood wrongly the idea.
I thought that once this config.php file is generated it can never be re-generated again.
I will close this issue.

[tzyganu]

@antonmakarenko Just to be clear for everyone can you post an example on how the config.php can be updated to take into account newly created modules? Let's say that I create a new module called Namespace_Module located in app/code, that is not available online (cannot use composer). how can I update the config.php file to take into account this module without editing it directly.

[wojtekn]

@antonmakarenko I will share deploy strategy which I use and I believe many people use that in similar way. As far as I understand @tzyganu does that in similar way.

I keep app/etc/local.xml in .gitignore list to avoid committing that to the repository. It's being created and filled manually on each environment (live, dev, local). Then when I want to add new community or custom extension to the site I do following (steps simplified and assuming everything works perfect):

1. Add extension code in local environment
2. Commit extension code to the repository feature branch
3. Merge feature branch to develop branch and deploy to dev environment
4. Merge feature branch to master branch and deploy to live environment

It works regardless of deployment type (SCP, FTP) and in most cases only requires to disable Magento cache before deployment and/or clear that after deployment.

This strategy can be possible as Magento 1 uses local.xml to configure environment specific stuff (db access, cache storage, session storage) and stores information about modules in another place (app/etc/modules/*).

It looks it isn't possible to achieve that currently in Magento 2 as it incorporates information about used modules to environment specific configuration file.

@antonmakarenko you proposed three solutions, but each of them has limitations:

1. using Setup CLI requires to run commands through SSH after deploying module, so it makes some deployment types not usable (eg. FTP)
2. storing environment specific config.php in repository introduces security issues
3. injecting value through environment could work only on specific environment, not always it's possible to edit domain configuration.

Actually it requires to run custom script or do manual work to deploy new module for Magento 2 on each environment.

Proposed solution which is about moving module list to its own file sounds good for me. For now I don't see reason to have each segment from config.php in separate file, but moving modules list to another file could solve problem and make such strategy working with Magento 2.

[antonmakarenko]

@tzyganu

how can I update the config.php file to take into account this module without editing it directly.

For now manual editing is the only way. We plan to add this feature to Setup CLI during "dev beta" milestone.

@wojtekn

Thanks for sharing. Your arguments make sense to me. I'll submit it as a feature request for now (unless you want to contribute a pull request?)

[mzeis]

I agree with @wojtekn, it's the same way we work and I know of many others doing it like that. Thanks @antonmakarenko for acknowleding the feature request.

For us the approach in M1 worked very well that you can enable/disable modules with an active setting per module and overwrite that setting in a non-versioned file (local.xml) or in a project specific extension which controls stuff like activating / deactivating extensions, providing default settings for System > Configuration and so on.

While I won't be able to provide a pull request in the foreseeable future: is there another way I can help with this issue?