;;
;;  DO NOT EDIT THIS FILE, it is just a TEMPLATE with documentation included!
;;
;;  This is a platform level INI file template which can be used to modify
;;  default BOA system behaviour for all sites hosted on this platform.
;;
;;  Copy this file as boa_platform_control.ini into sites/all/modules directory,
;;  then uncomment lines for any settings you want to modify, to make it active.
;;  All settings are initially listed with system defaults, for reference.
;;
;;  Note that it takes ~60 seconds to see any modification results in action
;;  due to opcode caching enabled in PHP-FPM for all non-dev sites.
;;
;;  BOA-2.3.5
;;


[session_control]
;;
;;  You can control session cookies expiration (TTL) per site and per platform.
;;  The value (in seconds) of the session_cookie_ttl variable is used as
;;  session.cookie_lifetime value.
;;
;;  BOA default defined in the system level global.inc file is 86400 == 24h.
;;
;;  We also recommend that you enable and configure built-in session_expire
;;  module, which allows you to keep the sessions DB table tidy. Make sure that
;;  TTL set via session_cookie_ttl variable below is *lower* than TTL configured
;;  in the session_expire module, because the module does not care about PHP
;;  settings and simply deletes old entries from the sessions table on cron run.
;;
;session_cookie_ttl = 86400

;;
;;  You can control session garbage collector (EOL) per site and per platform.
;;  The value (in seconds) of the session_gc_eol variable is used as
;;  session.gc_maxlifetime value and specifies the number of seconds after which
;;  data will be seen as 'garbage' and potentially cleaned up, resulting with
;;  $_SESSION variable discarded and affected authenticated users logged out.
;;
;;  BOA default defined in the system level global.inc file is 86400 == 24h.
;;
;session_gc_eol = 86400


[cache_control]
;;
;;  The modern version of Redis integration module is now enabled by default.
;;  You can switch it back to legacy version by uncommenting the line below
;;  and changing it to FALSE. But legacy version has serious limitations and
;;  known issues which have been fixed in the modern version.
;;
;;  Besides advanced flush modes configurable per cache bin, this new version
;;  comes with fast lock implementation, fully supporting both D7 and D6 sites,
;;  with multisite-aware capabilities. Note that redis_use_modern set to TRUE
;;  below is required if you want to use also redis_lock_enable and optionally
;;  redis_flush_forced_mode further below.
;;
;redis_use_modern = TRUE

;;
;;  The blazing fast Redis lock implementation is also enabled by default.
;;  Note that this setting depends on redis_use_modern set to TRUE above,
;;  and otherwise is ignored.
;;
;redis_lock_enable = TRUE

;;
;;  The more aggressive cache flush mode is now enabled by default, but you can
;;  still disable it with FALSE below, if you wish, after some testing, since
;;  it will further improve your site's performance.
;;
;;  Remember to uncomment the line below if you want to modify default setting
;;  which depends on redis_use_modern set to TRUE (default) above.
;;
;;  When enabled, it will automatically set more aggressive cache flush mode
;;  in general and very aggressive for selected cache bins, as listed below,
;;  along with redis integration module defaults, active when this option
;;  is explicitly set to FALSE.
;;
;;    $conf['redis_flush_mode']             = 1; // Redis default is 0
;;    $conf['redis_flush_mode_cache_page']  = 2; // Redis default is 1
;;    $conf['redis_flush_mode_cache_block'] = 2; // Redis default is 1
;;    $conf['redis_flush_mode_cache_menu']  = 2; // Redis default is 0
;;
;;  Note that even with this option enabled, you can easily override these
;;  values or configure completely custom modes, both for the wildcard option
;;  redis_flush_mode and per cache bin, in the local.settings.php file.
;;
;;  Please refer to the module README for more information on all available
;;  advanced flush modes: http://bit.ly/1drmi35
;;
;redis_flush_forced_mode = TRUE

;;
;;  Sometimes you may want to exclude some problematic cache bins from Redis
;;  so they will use default SQL engine, at least until related issue will be
;;  fixed either in your contrib code or in the Redis integration module.
;;
;;  Normally you had to edit the local.settings.php file which is both tedious
;;  and dangerous because of extra steps: https://omega8.cc/node/230 to add
;;  a line, for example: $conf['cache_class_cache_foo'] = 'DrupalDatabaseCache';
;;  Plus, it had to be done for every site separately.
;;
;;  Now you can simply list the cache bins to exclude below, comma separated,
;;  either in the site or platform level active INI file.
;;
;;  Example: redis_exclude_bins = "cache_views,cache_foo,cache_bar"
;;
;redis_exclude_bins = FALSE

;;
;;  Normally you should never disable Redis, unless for debugging rare issues.
;;  If you are sure you need to disable Redis for all sites on this platform,
;;  uncomment the line below and set the value to TRUE.
;;
;redis_cache_disable = FALSE

;;
;;  Speed Booster uses Nginx microcaching mode by default, with just 10 seconds
;;  both for anonymous visitors and logged in users. All known robots/crawlers
;;  and search engines spiders are forced to accept up to 24 hours cache TTL.
;;  Below you can modify the (10 seconds) default for human, anonymous visitors.
;;  Uncomment the line below and set any numeric value you prefer (in seconds)
;;  to override system default (10 seconds). You may want to enable Purge and
;;  Expire modules in all sites on this platform, so any new or modified node,
;;  comment added etc will selectively auto-purge related cache entries to avoid
;;  serving stale content for extended time (depending on the TTL configured).
;;  Note that the value must be higher than 10 or it will be ignored.
;;
;speed_booster_anon_cache_ttl = 10

;;
;;  With default Speed Booster TTL set to just 10 seconds to achieve the
;;  microcaching mode, disabling Drupal own page cache will significantly
;;  degrade your site's performance on every request not served via Speed
;;  Booster front-end cache, because Drupal will have to build the page from
;;  scratch every 10 seconds, making your site SLOW for every visitor not lucky
;;  enough to visit already cached page. This is why BOA enables Drupal own
;;  page cache by default, even if Boost, if used, will complain about it.
;;  It allows Drupal to keep its internal full-page cache in the super-fast
;;  Redis backend, to make also those every-10-seconds non-cached in Speed
;;  Booster requests blazingly fast.
;;
;;  If for some reason this default BOA configuration breaks something
;;  important in your site, like some page which should display not cached
;;  in a full-page cache results for anonymous visitors, even if they don't
;;  have a cookie set in the browser, didn't submit any form etc, so no other
;;  method to make the displayed page dynamic on the fly could be triggered,
;;  you could (very carefully) consider changing this variable to TRUE.
;;
;;  But please think twice before using this variable. While Redis will still
;;  improve performance for all other cache bins, the cache_page bin will
;;  not be used, and this will make your site much slower, randomly, even if
;;  you will increase the tiny speed_booster_anon_cache_ttl value above.
;;
;;  If you really have to disable this on some problematic URI, to guarantee
;;  that the page will be as dynamic as possible also for anonymous visitors,
;;  you may want to use more granular method, like adding in your site's
;;  local.settings.php file exception for the affected URI:
;;
;;    if (preg_match("^/(?:foo|bar)/", $_SERVER['REQUEST_URI'])) {
;;      header('X-Accel-Expires: 1'); // This disables Speed Booster
;;      $conf['cache'] = 0; // This disables page caching on the fly
;;    }
;;
;disable_drupal_page_cache = FALSE


[access_control]
;;
;;  When set to TRUE allows anonymous users to add content. Best practice and
;;  the default is FALSE which results with redirect to the site's homepage.
;;  Note that this option opens also an access to the node edit.
;;
;allow_anon_node_add = FALSE

;;
;;  When set to TRUE allows anonymous visitors to access the /admin* URL, even
;;  if only to see the 403 Access Denied message. Best practice and the default
;;  is FALSE which results with redirect to the site's homepage. This allows
;;  you to protect the site from DoS attempts, since the /admin* requests are
;;  never cached and always hit Drupal directly. Some sites may experience
;;  issues when your browser has expired session/cookie which redirects you
;;  to the homepage even if you were logged in. If something like this happens,
;;  you may want to disable this protection by changing it to TRUE below.
;;  Remember to uncomment the line below if you want to use this feature.
;;
;disable_admin_dos_protection = FALSE


[config_control]
;;
;;  When set to TRUE allows to use private files mode, so it is useful only
;;  for commerce sites which sell files for download or for intranet sites
;;  where you need to enforce strict access control. All other sites should
;;  never ever use private files mode for obvious performance reasons.
;;
;allow_private_file_downloads = FALSE

;;
;;  When set to TRUE, it forces the cookie_domain to always use main domain,
;;  also when the site is accessed via any domain alias. For example use case
;;  please read: https://gist.github.com/omega8cc/5724528
;;
;server_name_cookie_domain = FALSE

;;
;;  When set to TRUE allows to enable auto-detection and auto-include for
;;  the Drupal for Facebook (fb) module. Supported locations, in the order
;;  of precedence:
;;
;;    sites/all/modules/fb/
;;    sites/all/modules/contrib/fb/
;;    profiles/foo/modules/fb/
;;    profiles/foo/modules/contrib/fb/
;;
;;  IMPORTANT!
;;
;;  This setting on the platform level will be automatically set to TRUE
;;  (but not on the site level) during daily maintenance procedure
;;  if the module will be detected, however it will be completely ignored if
;;  there is boa_site_control.ini file present in the sites/foo.com/modules
;;  directory and this setting is set to FALSE there to improve performance,
;;  if the module is not used in that site even if it exists in the platform.
;;  Remember to uncomment the line below if you want to use this feature.
;;
;auto_detect_facebook_integration = FALSE

;;
;;  When set to TRUE allows to enable auto-detection and auto-include for
;;  the Domain Access module. Supported locations, in the order of precedence:
;;
;;    sites/all/modules/domain/
;;    sites/all/modules/contrib/domain/
;;    profiles/foo/modules/domain/
;;    profiles/foo/modules/contrib/domain/
;;
;;  IMPORTANT!
;;
;;  This setting on the platform level will be automatically set to TRUE
;;  (but not on the site level) during daily maintenance procedure
;;  if the module will be detected, however it will be completely ignored if
;;  there is boa_site_control.ini file present in the sites/foo.com/modules
;;  directory and this setting is set to FALSE there to improve performance,
;;  if the module is not used in that site even if it exists in the platform.
;;  Remember to uncomment the line below if you want to use this feature.
;;
;auto_detect_domain_access_integration = FALSE


[system_control]
;;
;;  This option allows to activate DB tables conversion for all sites hosted
;;  on this platform, unless the site has its own custom setting for variable
;;  sql_conversion_mode in the site level boa_site_control.ini file, located
;;  in the sites/foo.com/modules directory.
;;
;;  It can be also set (and forced) automatically for all sites on all platforms
;;  if there is special _SQL_CONVERT variable defined for this Octopus instance
;;  in its .USER.octopus.cnf config file, but it may require submitting support
;;  request if you are using hosted Aegir BOA service without root access.
;;
;;  Supported values are: innodb and myisam (lowercase only!)
;;
;;  Note that this conversion, if enabled, will run daily even if all tables
;;  have been already converted, so it will run OPTIMIZE task on all tables,
;;  effectively.
;;
;;  This setting affects only the running daily maintenance system behaviour.
;;
;;  This option is available only in BOA-2.1.3 or newer.
;;
;sql_conversion_mode = NO

;;
;;  When set to TRUE allows to force protection on all sites globally, unless
;;  the site has its own custom setting for disable_user_register_protection
;;  variable in the site level boa_site_control.ini file, located in the
;;  sites/foo.com/modules directory.
;;
;;  It can be set to TRUE automatically on all platforms if there is an empty
;;  control file: ~/static/control/enable_user_register_protection.info
;;
;;  Note that this setting affects only the maintenance system behaviour.
;;  It doesn't affect the site behaviour directly in a live mode, so you can
;;  modify related settings in the site admin, and they can be overridden,
;;  depending on the value defined below, when the maintenance system runs
;;  again, which happens each morning (in the server time zone).
;;
;enable_user_register_protection = FALSE

;;
;;  When set to TRUE allows to avoid having the entitycache module, which is
;;  included by default, auto-enabled during daily maintenance.
;;
;;  Note that this setting affects only the maintenance system behaviour.
;;  It doesn't affect the site behaviour directly in a live mode, so you can
;;  modify related settings in the site admin, and they can be overridden,
;;  depending on the value defined below, when the maintenance system runs
;;  again, which happens each morning (in the server time zone).
;;
;;  This setting is available only on the platform level, because if the distro
;;  or custom installation profile conflicts with entitycache, you don't want
;;  to have it re-enabled on any site on such platform, even if it is a great
;;  performance improvement for any Drupal 7 based site, and thus is highly
;;  recommended. Maybe you could fix your platform to make it compatible?
;;
;entitycache_dont_enable = FALSE

;;
;;  When set to TRUE allows to avoid having the views_cache_bully module,
;;  which is included by default, auto-enabled during daily maintenance,
;;  but only if there is special, global, non-default control file present:
;;
;;  ~/static/control/enable_views_cache_bully.info
;;
;;  If you didn't create this file to auto-enable views_cache_bully in all
;;  your sites, the variable views_cache_bully_dont_enable below will be
;;  completely ignored and the module will not be enabled. This feature
;;  is available since Since BOA-2.1.1, because BOA-2.1.0 forced this module
;;  to be enabled by default.
;;
;;  But even if you will create the special, global control file, you can still
;;  stop the system from enabling the module per platform, by changing the
;;  value of views_cache_bully_dont_enable to TRUE and activating the line.
;;
;;  This useful module automatically enables some default caching in all your
;;  views with no caching enabled yet, which is handy for busy webmasters.
;;
;;  Since BOA-2.1.1 this module is no longer enabled by default because
;;  it may affect commerce based sites, resulting with broken checkout.
;;  Because of those possible issues this module is automatically disabled
;;  if the maintenance agent discovers that commerce module is enabled.
;;
;;  You can still force views_cache_bully to be enabled if you have the special
;;  aforementioned control file in place and views_cache_bully_dont_enable
;;  variable below is set to FALSE or left commented out.
;;
;;  Note that this setting affects only the maintenance system behaviour.
;;  It doesn't affect the site behaviour directly in a live mode, so you can
;;  modify related settings in the site admin, and they can be overridden,
;;  depending on the value defined below, when the maintenance system runs
;;  again, which happens each morning (in the server time zone).
;;
;;  This setting is available only on the platform level, because if the distro
;;  or custom installation profile conflicts with this module, you don't want
;;  to have it re-enabled on any site on such platform, even if it is a great
;;  performance improvement for any Drupal 6/7 site, and thus is highly
;;  recommended. Maybe you could fix your platform to make it compatible?
;;  If not, then make sure to configure caching in all your views manually.
;;  You will make your sites visitors and users more happy!
;;
;views_cache_bully_dont_enable = FALSE


;;
;;  When set to TRUE allows to avoid having the views_content_cache module,
;;  which is included by default, auto-enabled during daily maintenance,
;;  but only if there is special, global, non-default control file present:
;;
;;  ~/static/control/enable_views_content_cache.info
;;
;;  If you didn't create this file to auto-enable views_content_cache in all
;;  your sites, the variable views_content_cache_dont_enable below will be
;;  completely ignored and the module will not be enabled. This feature
;;  is available since Since BOA-2.1.1, because BOA-2.1.0 forced this module
;;  to be enabled by default.
;;
;;  But even if you will create the special, global control file, you can still
;;  stop the system from enabling the module per platform, by changing the
;;  value of views_content_cache_dont_enable to TRUE and activating the line.
;;
;;  This handy module allows you to configure caching for views and views
;;  based blocks very precisely, which is great if you need to better control
;;  the cache per view and per content type.
;;
;;  Note that this module require that Chaos tools (ctools) module is already
;;  enabled. Otherwise views_content_cache will not be enabled.
;;
;;  Note that this setting affects only the maintenance system behaviour.
;;  It doesn't affect the site behaviour directly in a live mode, so you can
;;  modify related settings in the site admin, and they can be overridden,
;;  depending on the value defined below, when the maintenance system runs
;;  again, which happens each morning (in the server time zone).
;;
;;  This setting is available only on the platform level, because if the distro
;;  or custom installation profile conflicts with this module, you don't want
;;  to have it re-enabled on any site on such platform, even if it is a great
;;  performance improvement for any Drupal 6/7 site, and thus is highly
;;  recommended. Maybe you could fix your platform to make it compatible?
;;  You will make your sites visitors and users even more happy!
;;
;views_content_cache_dont_enable = FALSE


;;
;;  When set to FALSE allows to skip standard files permissions fix on all sites
;;  on this platform, even if the global option in the system level config
;;  file .barracuda.cnf is set to _PERMISSIONS_FIX=YES (default is NO, though).
;;
;;  This feature can be useful when you prefer to manage custom platform in
;;  a monolithic codebase mode in Git, so forcing permissions could conflict
;;  with your workflow or development tools. Otherwise you should never disable
;;  this to avoid issues with Aegir tasks related to sites on this platform.
;;
;;  This setting affects only the running daily maintenance system behaviour.
;;
;;  This option is available only in BOA-2.2.0 or newer.
;;
;fix_files_permissions_daily = TRUE
