Add ability to specify config file for modx:install

[hugopeek]

What does it do ?

This adds the ability to define a physical config file for the modx:install command as follows:

Gitify modx:install latest /absolute/path/to/config.xml

It doesn't need to be a .xml file btw, can also be a temp file like /tmp/tmp.CDyHpH4jYP. Just make sure the file has proper read permissions..

Why is it needed ?

Currently, the required configuration options are passed through the command line during Gitify modx:install. This prevents the installation process from being automated further.

Related issue(s)/PR(s)

As described in #193.

[hugopeek]

Getting some errors now, so it needs a bit of tweaking still..

[hugopeek]

Never mind, it's working fine. Used the same variable name twice in a bash script, so it was feeding Gitify the wrong path..

[Mark-H]

This should probably check if it can find the file, and not just "is it set"

[hugopeek]

Good one. I updated that, so it aborts when the file is not found. I think checking for valid XML is a bit too much here, also because there's no need for the config file to start with an XML declaration (meaning more difficult to check).

I also noticed that the config file was being deleted automatically by the unlink function down the road, so added an exception there too.

[Mark-H]

How would you use this? Can this move the core path (like #223) or would you need to manually move those directories?

[hugopeek]

Usage: by providing an XML file with all the config variables. For example:

<modx>
    <database_type>mysql</database_type>
    <database_server>localhost</database_server>
    <database>gitify_test</database>
    <database_user>dbuser</database_user>
    <database_password>123</database_password>
    <database_connection_charset>utf8</database_connection_charset>
    <database_charset>utf8</database_charset>
    <database_collation>utf8_unicode_ci</database_collation>
    <table_prefix>modx_</table_prefix>
    <https_port>443</https_port>
    <http_host>gitify-test.loc</http_host>
    <cache_disabled>0</cache_disabled>
    <inplace>0</inplace>
    <unpacked>0</unpacked>

    <language>en</language>
    <cmsadmin>Hugo</cmsadmin>
    <cmspassword>123</cmspassword>
    <cmsadminemail>comms@ff.com</cmsadminemail>

    <core_path>/var/www/gitify-core/core/</core_path>

    <context_mgr_path>/var/www/gitify-test/manager/</context_mgr_path>
    <context_mgr_url>http://gitify-test.loc/manager/</context_mgr_url>
    <context_connectors_path>/var/www/gitify-core/connectors/</context_connectors_path>
    <context_connectors_url>http://gitify-test.loc/connectors/</context_connectors_url>
    <context_web_path>/var/www/gitify-test/</context_web_path>
    <context_web_url>http://gitify-test.loc/</context_web_url>

    <remove_setup_directory>1</remove_setup_directory>
</modx>

I tried changing the core path this way, but that doesn't move the entire core folder for me. Only core/components is added in the designated location (empty), but I assume the goal would be to move the whole core folder? The config.core.php file also points to the default location, so I guess this feature would need a little more work still..

[hugopeek]

By the way, is it possible to add flags to the command line arguments somehow? So that the command can be something like Gitify modx:install --config '../config.xml'? Now, it always needs the version argument first..

[alexander-mart]

I tested this patch today on MODx 2.5.7-pl and Gitify 0.12.0.
This is cool feature, which be able to use gitify modx:install in no-interactive mode with Gitlab CI (gitlab-runner) to deploy MODx site to the different envirements: staging, pre-production and production.

Please, implement accept this PR, and change command format to
Gitify modx:install --config '../config.xml' 😉

Thanks for @hugopeek for this important work!

[Mark-H]

Yes flags should be possible, please look at the symfony console docs for details.

[sebastian-marinescu]

Make it a flag

[sebastian-marinescu]

Directly after $wd, adding this, is making the core_path-magic work:

        $cp_option = "";
        $doc = new \DOMDocument;
        if ($doc->load($config)) {
            $cp = $doc->getElementsByTagName('core_path')->item(0)->nodeValue;
            $cp_option = "--core_path=" . $cp;
        } else {
            $output->writeln("<error>Provided config file is not valid.</error>");
        }

        // If core_path is provided, move the core directory to specified new path
        if (!empty($cp) && !file_exists($cp)) {
            $output->writeln("Config provided a non-standard core_path, moving directory now...");
            exec("mv {$wd}core {$cp}", $cpOutput, $cpReturn);
            if ($cpReturn) {
                $output->writeln("<error>Moving core-directory failed - maybe a permissions issue?</error>");
            }
            $output->writeln("<comment>{$cpOutput[0]}</comment>");
        }

        // Actually run the CLI setup
        $output->writeln("Running MODX Setup...");
        exec("php -d date.timezone={$tz} {$wd}setup/index.php --installmode=new --config={$config} {$cp_option}", $setupOutput);

[hugopeek]

@sebastian-marinescu I'm not that familiar with advanced installs and don't have energy left to test your suggestion..

Shall we create a separate PR for that, and try to get this merged first?

[sebastian-marinescu]

@hugopeek If I remember it correctly, my thinking was that now that a user can provide a different core-path through the config-xml, Gitify and the InstallCommand should acknowledge that and move the extracted core/ directory to the new specified location.

I'll test your branch soon with two config-files and then also with one changing the core-path.

[hugopeek]

@Mark-H What's keeping this PR from being merged? I added a flag as @sebastian-marinescu suggested and I've been using it for years without issue.

This change is not intended to be used for moving the core folder. Only to run the installer without user interaction, which is necessary when using Gitify through a CLI tool like an automated installer or a Gitlab runner (as @alexander-mart pointed out).

And from what I understood, MODX3 won't support moving the core folder anyway, so.. Good to go? :)

[hugopeek]

Oh sorry, I didn't see that there are conflicts. Will sort that out first.

[muzzwood]

Hi @hugopeek , I'll be doing a bunch of testing and merging towards the end of this week. This one is top of the list! :)

[hugopeek]

Thanks @muzzwood :) I was also looking at it already. It has become incompatible after this pull request was merged: #223

That adds some code after $config = $this->createMODXConfig(); which expects the config array to be present with a few new properties. My PR however prevents te createMODXConfig from running, because that would invoke the interactive part. So there is no config array.

I'll try to move things around a little so these 2 functionalities can co-exist. Would be nice if the corePathParameter can also be used in a physical config file.

[Mark-H]

Perhaps in the InstallModxCommand, replace:

$config = $this->createMODXConfig();

with

$providedConfig = read_and_parse_to_array($providedFilePath);
$config = $this->createMODXConfig($providedConfig);

and then in createMODXConfig, only interactively ask for values not present in $providedConfig.

[hugopeek]

@Mark-H That's a good idea! I did that, and now it integrates nicely with the option to specify an alternative location for the core. If a path is specified outside of the project root in config.xml, it will be moved. And only properties not set in config.xml will invoke a question.

[muzzwood]

This works great, @hugopeek . Nice work!