3

Wondering what the "best practice" approach would be for disabling secure pages on local dev. I'm running a site on Acquia Cloud and have access to the environment variable AH_SITE_ENVIRONMENT and I could easily do something like:

if (isset($_ENV['AH_SITE_ENVIRONMENT'])) {
  switch ($_ENV['AH_SITE_ENVIRONMENT']) {
    // case 'dev':
    //   // do something on dev
    //   break;

    // case 'test':
    //   // do something on staging
    //   break;

    case 'prod':
      // do something on prod
      break;
  }
}
else {
    $conf['securepages_enabled'] = 0;
}

Is that the best approach or is there a better, cleaner way? Also, are there negative implications for filling up settings.php with stuff like this?

closed as primarily opinion-based by kiamlaluno Dec 2 '15 at 12:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

2

It's a best practice to create a settings.local.php file which is included at the end of the default settings.php file. Then within that file you can place whatever logic you want per server as you've done, or make the content of settings.local.php be specific per server host you're deploying too (and keep settings.local.php basically outside of version control).

This is a good practice for Drupal 7 development -- so good in fact Drupal 8 ships with such code in settings.php by default, which you can uncomment to make use of:

/** In settings.php for a drupal 8 site */

/**
 * Load local development override configuration, if available.
 *
 * Use settings.local.php to override variables on secondary (staging,
 * development, etc) installations of this site. Typically used to disable
 * caching, JavaScript/CSS compression, re-routing of outgoing emails, and
 * other things that should not happen on development and testing sites.
 *
 * Keep this code block at the end of this file to take full effect.
 */
# if (file_exists(__DIR__ . '/settings.local.php')) {
#   include __DIR__ . '/settings.local.php';
# }
  • But for an environment like Acquia Cloud, Where you are running one code-base without a local settings.php file capability, would this still hold up? – Eric Steinborn Oct 28 '15 at 14:32
  • It's a feature supported by core drupal, I don't care what a 3rd party configuration supports personally. :). If anyone else has a work-around or suggestion for this specific use-case i'm open to suggestions. – tenken Oct 28 '15 at 14:43
-1

It's better to maintain separate site folders if you want different configs depending on the server role. In the simplest set-up, name each folder after the domain. Eg:

sites/
      dev.example.com/
          settings.php
      www.example.com/
          settings.php

If you need a more flexible mapping, you should use sites.php to hold the code used to determine which folder should apply.

  • Ops question had nothing todo with various sub-sites, but rather how to deal with Development, Staging and Production server settings configuration ... – tenken Oct 27 '15 at 15:54
  • You can use multiple sites for exactly this purpose, hence my answer. – Alfred Armstrong Oct 27 '15 at 15:58
  • oh i see what you're saying ...... ewww. This approach adds alot of folder noise to a drupal installation, there's only 1 site not a million requiring sites.php or drupal's multi-site configuration (which btw Drupal8 had rumors of removing -- but didn't for legacy reasons). – tenken Oct 27 '15 at 16:04
  • Matter of taste, I think :) I really do not like conditional logic in config files, it encourages kludges. Greatly prefer to keep them separate. – Alfred Armstrong Oct 27 '15 at 16:44

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