Considerations for setting paths for CLI upgrade

222 Posts

gadamiak Reply #1, 12 years, 7 months ago

I'm testing upgrading from CLI. I've scripted the upgrade from Git procedure except this one. It will close the gap.

Back to question: how should the paths be set up for CLI to work? I followed the docs and the sample [tt]config.dist.xml[/tt] and made some attempts but still get error:

<title>MODX Revolution Core Finder</title>
<h2>Your MODX_CORE_PATH is invalid</h2>
...
<label>MODX_CORE_PATH</label>
<input type="text" name="core_path" id="core_path" value="/srv/www/sites/site_domain/public/core/" size="80" maxlength="255" />
<span class="field_error">ERROR: Your MODX_CORE_PATH is invalid; please specify the correct path in the field above and click Submit.</span>

Unfortunately, the error comes from a HTML page, which is dumped to screen. This is not CLI friendly. Anyway, the error comes from the core path, which is set correctly IMO.

I use the following folder structure:

[tt]/srv/www/modx/dev/[/tt] -- the MODX snapshot from Git (in this case my dev workspace)
[tt]/srv/www/sites/site_domain/public/[/tt] -- the site files and folders

The site folder contains all required files hardlinked from Git snapshot plus any other folders and files like [tt]assets/[/tt]. This setup works without problems and allows for easy upgrades via shell script and browser. However, it apparently fails in case of CLI upgrade, because of paths.

My [tt]config.xml[/tt] contains:

<!-- Paths for your MODX installation -->
<mgr_path>/srv/www/modx/dev/manager/</mgr_path>
<mgr_url>/manager/</mgr_url>
<connectors_path>/srv/www/modx/dev/connectors/</connectors_path>
<connectors_url>/connectors/</connectors_url>
<web_path>/srv/www/modx/dev/</web_path>
<web_url>/</web_url>
<assets_path>/srv/www/sites/site_domain/public/assets/</assets_path>
<assets_url>/assets/</assets_url>
<core_path>/srv/www/modx/dev/core/</core_path>
<processors_path>/srv/www/modx/dev/core/model/modx/processors/</processors_path>

<!-- Paths for the default web context that is installed. -->
<context_mgr_path>/srv/www/sites/site_domain/public/manager/</context_mgr_path>
<context_mgr_url>/manager/</context_mgr_url>
<context_connectors_path>/srv/www/sites/site_domain/public/connectors/</context_connectors_path>
<context_connectors_url>/connectors/</context_connectors_url>
<context_web_path>/srv/www/sites/site_domain/public/</context_web_path>
<context_web_url>/</context_web_url>

The path values are taken from the [tt]config.core.php[/tt] for that site. I also tried paths for site folder (ie. the same as in 'context' section) in the first ('MODX') section, but got the same problem.

How should I set them up to make CLI upgrade work? [ed. note: gadamiak last edited this post 12 years, 7 months ago.]

This is the web: the only thing you know about who will come is that you don't know who will come.

222 Posts

gadamiak Reply #2, 12 years, 7 months ago

On attempt to run setup in the browser, I was presented the same error page. After typing and saving the correct path to core I re-run setup from CLI. This time it didn't complain about paths, but has thrown another error:

php ./index.php --installmode=upgrade
PHP Fatal error:  Class 'xPDODriver_' not found in /srv/www/modx/dev/core/xpdo/xpdo.class.php on line 1626

However, upgrade from the browser went without problems.

This is the web: the only thing you know about who will come is that you don't know who will come.

222 Posts

gadamiak Reply #3, 12 years, 7 months ago

Another update. After a successful upgrade from a browser, I re-run CLI upgrade. This time it didn't complain about anything and upgraded without problems.

So, the conclusion is: before upgrading from CLI for the first time a traditional upgrade must be run. I guess, it's worth mentioning in the docs to save others time and confusion. Also a more detailed description of paths options should be added. Maybe even the nodes in [tt]config.dist.xml[/tt] should be named more explicitly to avoid confusion in case of a shared core installation, like [tt]core_mgr_path[/tt] instead of [tt]mgr_path[/tt].

There is also another issue with CLI installer. It complains about insufficient memory limit when it is set to [tt]-1[/tt], which means 'no limit'. This value is often the case for CLI php.ini and shouldn't be a problem for installer.

This is the web: the only thing you know about who will come is that you don't know who will come.

222 Posts

gadamiak Reply #4, 12 years, 7 months ago

Quote from: gadamiak at Sep 28, 2011, 09:08 AM

Also a more detailed description of paths options should be added. Maybe even the nodes in [tt]config.dist.xml[/tt] should be named more explicitly to avoid confusion in case of a shared core installation, like [tt]core_mgr_path[/tt] instead of [tt]mgr_path[/tt].

After some more testing I find nodes should be really renamed to be self explanatory. In my case (see paths above) after upgrade a warning shows in dashboard about installer still present with a path to [tt]/srv/www/modx/dev/setup/[/tt], which is plain wrong. This path is part of the Git snapshot, not the path to installer folder for this particular domain.

So instead I should set it to:

<web_path>/srv/www/sites/site_domain/public/</web_path>

However, the node name belongs to the 'core' group, which was misleading for me. [ed. note: gadamiak last edited this post 12 years, 7 months ago.]

This is the web: the only thing you know about who will come is that you don't know who will come.

4,149 Posts

splittingred Reply #5, 12 years, 7 months ago

Hi gadamiak,

The CLI installs are definitely still in testing, so you're bound to find errors. Thanks for investigating.

Can you file those as issues here: http://bugs.modx.com/ so that they don't get lost on the forums?

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

222 Posts

gadamiak Reply #6, 12 years, 7 months ago

I will (the bugtracker is down ATM). In the meantime, I've been testing it further, and unfortunately it doesn't work well. I can't get the path to work reliably.

I guess, this needs refactoring. Looking at the config file for a site and in [tt]core/config/[/tt] there are 6 paths required, which are set in my case to:

MODX_CORE_PATH = /srv/www/modx/dev/core/
MODX_PROCESSORS_PATH = /srv/www/modx/dev/core/model/modx/processors/
MODX_CONNECTORS_PATH = /srv/www/sites/site_domain/public/connectors/
MODX_MANAGER_PATH = /srv/www/sites/site_domain/public/manager/
MODX_BASE_PATH = /srv/www/sites/site_domain/public/
MODX_ASSETS_PATH = /srv/www/sites/site_domain/public/assets/

The paths are not differentiated to 'core' and 'context'. Wouldn't that suffice for the CLI install/upgrade too?

My URLs are (just for reference:

MODX_CONNECTORS_URL = /connectors/
MODX_MANAGER_URL = /manager/
MODX_BASE_URL = /
MODX_ASSETS_URL = /assets/

This is the web: the only thing you know about who will come is that you don't know who will come.

222 Posts

gadamiak Reply #7, 12 years, 7 months ago

Quote from: splittingred at Sep 28, 2011, 01:27 PM

Can you file those as issues here: http://bugs.modx.com/ so that they don't get lost on the forums?

Here they are: #5835, #5836, #5837.

This is the web: the only thing you know about who will come is that you don't know who will come.

222 Posts

gadamiak Reply #8, 12 years, 1 month ago

I've given up CLI upgrades since my last posting and now took another take on it. Despite improvements I still encounter problems with core path, which gets calculated from site webroot just like I reported before.

The folder structure described above hasn't changed. I'm still running MODX from Git and the upgrade process is scripted in Bash. The setup is called from inside 'setup' directory with:

php ./index.php --installmode=upgrade-advanced

Finally I managed to run the setup successfully by providing it with core path and config key manually:

php ./index.php --installmode=upgrade-advanced --core_path=/srv/www/modx/dev/core/ --config_key=my_config_key

It finished ok and the site got upgraded. However, both core path and config key should get extracted from [tt]config.core.php[/tt] and [tt]config.xml[/tt]. But they don't.

BTW, the install script returned a message:

Installation finished in 9,0945 s
zend_mm_heap corrupted

What's it about?

This is the web: the only thing you know about who will come is that you don't know who will come.

222 Posts

gadamiak Reply #9, 12 years, 1 month ago

Quote from: gadamiak at Mar 26, 2012, 02:11 PM

zend_mm_heap corrupted

I found this info about [tt]unset()[/tt]ting references, which seem to produce that error. Shouldn't that be verified in the installer?

This is the web: the only thing you know about who will come is that you don't know who will come.