'database_name', 'username' => 'database_user', 'password' => 'database_pass', 'unix_socket' => '/Applications/MAMP/tmp/mysql/mysql.sock', 'host' => '127.0.0.1', // localhost is no good! See drupal.org/node/2610858. 'port' => '', 'driver' => 'mysql', 'prefix' => '', ]; /** * Salt for one-time login links, cancel links, form tokens, etc. * * This variable will be set to a random value by the installer. All one-time * login links will be invalidated if the value is changed. Note that if your * site is deployed on a cluster of web servers, you must ensure that this * variable has the same value on each server. * * For enhanced security, you may set this variable to the contents of a file * outside your document root; you should also ensure that this file is not * stored with backups of your database. * * Example: * @code * $settings['hash_salt'] = file_get_contents('/home/example/salt.txt'); * @endcode */ $settings['hash_salt'] = 'LOLWUT'; /** * Configuration overrides. * * To globally override specific configuration values for this site, * set them here. You usually don't need to use this feature. This is * useful in a configuration file for a vhost or directory, rather than * the default settings.php. * * Note that any values you provide in these variable overrides will not be * viewable from the Drupal administration interface. The administration * interface displays the values stored in configuration so that you can stage * changes to other environments that don't have the overrides. * * There are particular configuration values that are risky to override. For * example, overriding the list of installed modules in 'core.extension' is not * supported as module install or uninstall has not occurred. Other examples * include field storage configuration, because it has effects on database * structure, and 'core.menu.static_menu_link_overrides' since this is cached in * a way that is not config override aware. Also, note that changing * configuration values in settings.php will not fire any of the configuration * change events. */ // Logging. $config['system.logging']['error_level'] = 'verbose'; $config['dblog.settings']['row_limit'] = 1000; // Temp files. $config['system.file']['path']['temporary'] = '/tmp'; // Aggregation. $config['system.performance']['css']['preprocess'] = FALSE; $config['system.performance']['js']['preprocess'] = FALSE; $config['system.performance']['css']['gzip'] = FALSE; $config['system.performance']['js']['gzip'] = FALSE; /** * Trusted host configuration. * * Drupal core can use the Symfony trusted host mechanism to prevent HTTP Host * header spoofing. * * To enable the trusted host mechanism, you enable your allowable hosts * in $settings['trusted_host_patterns']. This should be an array of regular * expression patterns, without delimiters, representing the hosts you would * like to allow. * * For example: * @code * $settings['trusted_host_patterns'] = array( * '^www\.example\.com$', * ); * @endcode * will allow the site to only run from www.example.com. * * If you are running multisite, or if you are running your site from * different domain names (eg, you don't redirect http://www.example.com to * http://example.com), you should specify all of the host patterns that are * allowed by your site. * * For example: * @code * $settings['trusted_host_patterns'] = array( * '^example\.com$', * '^.+\.example\.com$', * '^example\.org$', * '^.+\.example\.org$', * ); * @endcode * will allow the site to run off of all variants of example.com and * example.org, with all subdomains included. */ $settings['trusted_host_patterns'] = [ '^dev\.example\.com$', '^vhost\.dev$', ]; /** * Load local development services definition file. */ $settings['container_yamls'][] = DRUPAL_ROOT . '/sites/services.yml'; /** * Disable the render cache (this includes the page cache). * * Note: you should test with the render cache enabled, to ensure the correct * cacheability metadata is present. However, in the early stages of * development, you may want to disable it. * * This setting disables the render cache by using the Null cache back-end * defined by the development.services.yml file above. * * Do not use this setting until after the site is installed. */ $settings['cache']['bins']['render'] = 'cache.backend.null'; /** * Disable Dynamic Page Cache. * * Note: you should test with Dynamic Page Cache enabled, to ensure the correct * cacheability metadata is present (and hence the expected behavior). However, * in the early stages of development, you may want to disable it. */ $settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null'; /** * Disable Discovery Cache * * Contains cached discovery data for things such as plugins, views_data, or * YAML discovered data such as library info. */ $settings['cache']['bins']['discovery'] = 'cache.backend.null'; /** * Additional settings from dawehner */ // Via https://paste.tag1consulting.com/pid7efobs/qj9mtz $settings['cache']['bins']['null'] = 'cache.backend.null'; // Nuclear option from Daniel that might slow things down too much, so be careful. $settings['cache']['bins']['data'] = 'cache.backend.null'; /** * Allow test modules and themes to be installed. * * Drupal ignores test modules and themes by default for performance reasons. * During development it can be useful to install test extensions for debugging * purposes. */ $settings['extension_discovery_scan_tests'] = TRUE; /** * Enable access to rebuild.php. * * This setting can be enabled to allow Drupal's php and database cached * storage to be cleared via the rebuild.php page. Access to this page can also * be gained by generating a query string from rebuild_token_calculator.sh and * using these parameters in a request to rebuild.php. */ $settings['rebuild_access'] = TRUE;