Answers.Body: <p>You'll see from <a href="https://github.com/civicrm/civicrm-drupal/blob/7.x-master/civicrm.config.php.drupal#L36" rel="nofollow"><code>civicrm_conf_init()</code></a> that CiviCRM assumes the site's <code>settings.php</code> and <code>civicrm.settings.php</code> 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.</p>
  
  <p>I believe this could be addressed fairly easily (eg via available Drupal functions like <a href="https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/conf_path/7.x" rel="nofollow"><code>conf_path()</code></a> for the config directory and <a href="https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_get_path/7.x" rel="nofollow"><code>drupal_get_path()</code></a> for the module path), and it would probably make CiviCRM a better "Drupal" citizen if that was the case.</p>
  
  <p>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.</p>
  
  <p>These are scripts like <code>extern/ipn.php</code> (for which <code>civicrm/payment/ipn/%processor_id</code> would be preferable: <a href="https://issues.civicrm.org/jira/browse/CRM-9779" rel="nofollow">CRM-9779</a>), and other files in that <code>extern</code> directory.</p>
  
  <p>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.</p>
  
  <p>Some background:</p>
  
  <ul>
  <li><a href="https://forum.civicrm.org/index.php?topic=32545.0" rel="nofollow">Forum: Remove CiviCRM entry points except via CMS frontend</a></li>
  <li><a href="https://issues.civicrm.org/jira/browse/CRM-11212" rel="nofollow">CRM-11212: Drupal does not bootstrap from extern/rest.php</a></li>
  <li><a href="https://issues.civicrm.org/jira/browse/CRM-9779" rel="nofollow">CRM-9779: Common payment notification framework for payment processor extensions</a></li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-10T22:46:32.390Z
Answers.Text: 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?
Answers.UserDisplayName: Sohal Khatwani
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-10T22:58:08.943Z
Answers.Text: Instead of writing custom code, consider contributing to the project to address the underlying issue(s). There are [many ways you can do this](https://civicrm.org/get-involved), 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 :)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-10T03:21:59.773Z
Answers.LastActivityDate: 2016-08-10T03:21:59.773Z
Answers.UserDisplayName: Chris Burgess
Body: <p>We have setup CiviCRM to run as part of an installation profile. So instead of the default <code>sites/all/modules</code> folder, CiviCRM is installed in <code>profiles/ourprofile/modules/contrib/civicrm</code>. </p>
  
  <p>CiviCRM works perfectly and so we have had no issues. However, when testing an email campaign I keep getting this error message </p>
  
  <blockquote>
    <p>Could not load the settings file at: (followed) by a path to civicrm.settings.php file. </p>
  </blockquote>
  
  <p>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. </p>
  
  <p>I know the easiest solution is to move CiviCRM to the <code>sites/all/modules</code> folder. However, this will make it harder for us to maintain versions for CiviCRM as part of our profile. </p>
  
  <p>Any advice is appreciated. Thanks. </p>
  
Tags: <civimail><civicrm.settings.php>
Title: Civimail Urls don't load and show Could not load the settings file at:
ThreadText: # Civimail Urls don't load and show Could not load the settings file at:
  
  (Asked by: username_0 on 2016-08-10)
  
  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.
  
  **Tags:** civimail, civicrm.settings.php
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-08-10. Score: 1
  
  You'll see from [`civicrm_conf_init()`](https://github.com/civicrm/civicrm-drupal/blob/7.x-master/civicrm.config.php.drupal#L36) 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()`](https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/conf_path/7.x) for the config directory and [`drupal_get_path()`](https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_get_path/7.x) 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](https://issues.civicrm.org/jira/browse/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:
  
  * [Forum: Remove CiviCRM entry points except via CMS frontend](https://forum.civicrm.org/index.php?topic=32545.0)
  * [CRM-11212: Drupal does not bootstrap from extern/rest.php](https://issues.civicrm.org/jira/browse/CRM-11212)
  * [CRM-9779: Common payment notification framework for payment processor extensions](https://issues.civicrm.org/jira/browse/CRM-9779)
  
  > **Comments:**
  > **username_0**: Thanks username_1. 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?  
  > **username_1**: Instead of writing custom code, consider contributing to the project to address the underlying issue(s). There are [many ways you can do this](https://civicrm.org/get-involved), 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 :)  
  
  ---
  
  