1

We have setup CiviCRM to run as part of an installation profile. So instead of the default sites/all/modules folder, CiviCRM is installed in profiles/ourprofile/modules/contrib/civicrm.

CiviCRM works perfectly and so we have had no issues. However, when testing an email campaign I keep getting this error message

Could not load the settings file at: (followed) by a path to civicrm.settings.php file.

Nothing loads and the links don't work. I read a few comments on Github that there is a similar issue for multisite on CiviCRM. However, this is a single site and I am not sure what do next as there is not much information on how this can be fixed.

I know the easiest solution is to move CiviCRM to the sites/all/modules folder. However, this will make it harder for us to maintain versions for CiviCRM as part of our profile.

Any advice is appreciated. Thanks.

Improve this question

1 Answer 1

Reset to default
1

You'll see from civicrm_conf_init() that CiviCRM assumes the site's settings.php and civicrm.settings.php have a specific (relative) location to the CiviCRM codebase. When CiviCRM is installed in a profiles folder, this isn't the case, so config discovery fails.

I believe this could be addressed fairly easily (eg via available Drupal functions like conf_path() for the config directory and drupal_get_path() for the module path), and it would probably make CiviCRM a better "Drupal" citizen if that was the case.

AFAIK the reason CiviCRM doesn't use functions provided by the host CMS when initialising site config is just to handle a few remaining locations where CiviCRM scripts are called directly, without being initialised via the CMS itself.

These are scripts like extern/ipn.php (for which civicrm/payment/ipn/%processor_id would be preferable: CRM-9779), and other files in that extern directory.

While a patch to support locating CiviCRM in the profiles directory alone could be contributed, I'd encourage working towards eliminating remaining scripts in those deprecated locations. Then CiviCRM doesn't have to duplicate the logic of each CMS's config discovery (amongst other benefits), and it'll "play nicer" in that CMS ecosystem.

Some background:

Improve this answer
2
  • Thanks Chris. I gather we will need to write a custom module to resolve this issue? I wonder should CiviCRM resolve this issue if it redundant code that has not been updated?
    – Sohal Khatwani
    Aug 10, 2016 at 22:46
  • Instead of writing custom code, consider contributing to the project to address the underlying issue(s). There are many ways you can do this, including contributing code directly, or paying others to do the work for you. Even posting questions like this is a contribution - but to fix the problem you're facing, more effort than that will be needed :)
    – Chris Burgess
    Aug 10, 2016 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.