CiviCRM Community Forums (archive)

Hey there,

I have a problem (maybe specific to my set up and if that is the case, then the first lot of info in quotes below should help).

I have my civicrm codebase at /clients/demo/git/drupal/sites/all/modules/civicrm
/clients/demo/git/drupal is linked to /var/www/demo/

Running

ubuntu@colombia:/var/www/demo/sites/all/modules/civicrm/bin$ sudo php UpdateAddress.php -nxxx -pxxx -kxxx

gives the following error:

<br />Sorry, could not able to locate bootstrap.inc.

(which seems to come from CRM/Utils/System/Drupal.php)

I added a /var/www/demo/sites/all/modules/civicrm/settings_location.php, with the following...

<?php
define( 'CIVICRM_CONFDIR', '/var/www/demo/sites' );
?>

...but that didn't help.

PS. i would have run this same script via a URL but I get a 'Console_Getopt: Could not read cmd args (register_argc_argv=Off?)' error there (which has been reported elsewhere).
PPS. have checked at the username and password and key and this is being passed OK

Thanks, people

Hi All,

I'm running into this problem as well.

It turns out that Debian Squeeze defaults to setting register_argc_argv to off in /etc/default/apach2/php.ini, which causes UpdateAddress.php to fail if you are using mod_php.

And - running directly via the command line fails if you have a multi-site installation because it can't determine the location of civicrm.settings.php.

It seems like both problems are fixable - via the web, the arguments could be parsed using $_SERVER['QUERY_STRING'].

Regariding the command line - maybe an extra argument could be passed to indicate which site to work on? Maybe something like this is already being considered?

jamie

Thanks for pointing me in the right direction for the cli fix. Anyone else have ideas on why UpdateAddress.php doesn't use cli.php? If not I can take a stab and patching it.

jamie

I see why this script was left behind. This is not as simple a task as I thought.

cli.php expects --user|-u, --pass|-p, and --site|-s.

UpdateAddress.php allows you to pass: --name, --pass, --key (for authenticating) and --start, --end, --parse, --geocoding.

So - when using cli.php, we get errors saying "unrecognized options." I've started to patch cli.php so it's more abstracted - allowing you to create a cli object and specifiy the custom options. However, we're still left with the UpdateAddress.php wanting the username passed as --name and cli.php wanting it passed as --user. I'm inclined to change UpdateAddress.php to use the cli.php standard, but that will break existing scripts. Is that the right direction?

Also - cli.php seems to insist that CIVICRM_CONFDIR is defined, even if you've passed the site name. I"m not sure why that is and am working around it.

I'm tempted to scrap this work altogether and instead submit a patch to civicrm.drush.inc which could handle it all much more elegantly. But then, joomla users would be left out.

Thoughts?

jamie

I think it should be safe enough to fix it and do the right thing. Would be good to expand cli.php to allow additional parameters.

lobo