Answers.Body: <p>I'm assuming you're talking about <code>DEFINE</code> statements since you mention domain id? Are you able to edit drupal's settings.php? If so you can just put those DEFINEs in there since it loads first and most of the DEFINE settings in civicrm.settings.php check for <code>if (defined(SETTING_NAME))</code>.</p>
  
  <p>If you can't edit drupal's settings.php, I haven't tested this but can you write a little drupal module that sets those defines, and in the <code>system</code> table set that module's weight to something lower than the weight for civicrm so that it runs first.</p>
  
  <p>If you're talking about various <code>$civicrm_setting['xxxxx']</code> entries, then again I haven't tested but the module method might also work but you would set the weight higher than civicrm's weight, so that it loads after.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-27T07:30:29.273Z
Answers.Text: Thanks! Can't edit settings.php but there is a local.settings.php available that can be made writable and that works fine for defining constants and setting any other CiviCRM variables.
Answers.UserDisplayName: Aiden
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-31T20:04:51.717Z
Answers.Text: Note that there are still some pathways that don't use the settings.php file (e.g. the code that is executed to track civimail opens), so there may be some configuration changes that won't work in there. Most of the time settings.php is loaded before civicrm.settings.php, so the local.settings.php file is going to be the right answer.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-25T20:12:43.423Z
Answers.LastActivityDate: 2020-03-25T20:12:43.423Z
Answers.UserDisplayName: Demerit
Body: <p>The drupal hosting system that we are currently using prevents us from making any changes to civicrm.settings.php which I find is sometimes necessary or at least the most sensible solution in certain situations. (One example is to set domain IDs when using Domain Access.) I believe the file is regenerated regularly so changes wouldn't last long anyway.
  I am hoping that someone who knows what they're doing can suggest an elegant way that I could put any code meant for civicrm.settings.php in another file elsewhere, preferably on the site level for multisite situations.</p>
  
  <p>Thanks!</p>
  
Tags: <drupal><civicrm.settings.php><aegir>
Title: Alternatives to editing civicrm.settings.php
ThreadText: # Alternatives to editing civicrm.settings.php
  
  (Asked by: username_0 on 2020-03-24)
  
  The drupal hosting system that we are currently using prevents us from making any changes to civicrm.settings.php which I find is sometimes necessary or at least the most sensible solution in certain situations. (One example is to set domain IDs when using Domain Access.) I believe the file is regenerated regularly so changes wouldn't last long anyway.
  I am hoping that someone who knows what they're doing can suggest an elegant way that I could put any code meant for civicrm.settings.php in another file elsewhere, preferably on the site level for multisite situations.
  
  Thanks!
  
  **Tags:** drupal, civicrm.settings.php, aegir
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-03-25. Score: 1
  
  I'm assuming you're talking about `DEFINE` statements since you mention domain id? Are you able to edit drupal's settings.php? If so you can just put those DEFINEs in there since it loads first and most of the DEFINE settings in civicrm.settings.php check for `if (defined(SETTING_NAME))`.
  
  If you can't edit drupal's settings.php, I haven't tested this but can you write a little drupal module that sets those defines, and in the `system` table set that module's weight to something lower than the weight for civicrm so that it runs first.
  
  If you're talking about various `$civicrm_setting['xxxxx']` entries, then again I haven't tested but the module method might also work but you would set the weight higher than civicrm's weight, so that it loads after.
  
  > **Comments:**
  > **username_0**: Thanks! Can't edit settings.php but there is a local.settings.php available that can be made writable and that works fine for defining constants and setting any other CiviCRM variables.  
  > **username_2**: Note that there are still some pathways that don't use the settings.php file (e.g. the code that is executed to track civimail opens), so there may be some configuration changes that won't work in there. Most of the time settings.php is loaded before civicrm.settings.php, so the local.settings.php file is going to be the right answer.  
  
  ---
  
  