Allow different Magento webroot for local.xml discovery

[real34]

It would be great to allow running the command from elsewhere than the Magento root.

For instance in a prject using modman with a htdocs subdirectory for the actual magento code it would be great to just run vendor/bin/apply.php dev config/env-settings.csv --basedir=htdocs/ (or similar) from the project root.

So far I had issue with the CoreConfigData handler because the path to local.xml is hardcoded in

EnvSettingsTool/Est/Handler/Magento/AbstractDatabase.php

Line 36 in 4b76507

$localXmlFile = 'app/etc/local.xml';

for reading database credentials.

[fbrnc]

Hi @real34,
currently EnvSettingsTool assume you run it from you Magento web root. Not only is the path to the loxal.xml file hardcoded, but it also assumes all the other files (for marker replace or xml files) are relative to the current working directory which is the expected to be the Magento root.

We also prefer having Magento in htdocs while the actual project root is one level up. In our deploy scripts we run EnvSettings like this

cd htdocs && ../tools/apply.php devbox ../Configuration/setttings.csv

I agree that it would be nice to add more flexibility here. Ideally we'd have a separate commandline option pointing to the Magento root dir (similar to what you're suggesting and what n98-magerun is doing).

Currently the apply.php is very limited and adding custom parameters is pretty ugly since the script is expecting the first parameter to be the environment and the second one to be the path to the settings.csv file. We're planning on porting this to Symfony console which then would provide much more elegant ways to configure additional parameters.

So unless this is very important to you (PR are welcome :) stay tuned for the Symfony console version... :)

[real34]

Thanks for your feedback. I totally understand, and opened the issue to keep track of this new feature.

We just started to use the tool in my team @occitech and so far came up with the same deploy command! It is not a big deal.

Waiting for the Symfony console version is fine, or we will find time for the PR now that we know what other impacts it can have.