settings.php — настройки окружения сайта

settings.php — файл с настройками для конкретного сайта. Данный файл содержит специфичные настройки для конкретного сайта.

В данном файле настраиваются такие параметры как подключение к базе данных, пути до конфигураций, соль и т.д. Он может быть использован сторонними модулями для управления собственным поведением, для этого присутствует соответствующий API.

Настройки, в отличие от конфигураций, предназначены только для хранения read-only значений, которые необходимы на очень ранних этапах запуска ядра. Иными словами, это настройки, которые определяют значения для текущего окружения.

Файл является read-only и Drupal регулярно проверяет что данный файл защищён от записи. Прежде чем вносить правки в данный файл на действующем сайте, убедитесь что у вашего пользователя есть права на его запись.

¶Создание файла

Данный файл необходим для работы Drupal и обязательно должен присутствовать. Вы можете воспользоваться двумя вариантами создания данного файла:

• Ручной режим. Вы можете скопировать файл настроек по умолчанию default.settings.php и переименовать его в settings.php, а затем указать и изменить все необходимые для вас настройки.
• Автоматический режим. Данный файл будет автоматически создан и настроен для корректной работы сайта в процессе установки Drupal. Данные, такие как подключение к БД, будут запрошены у вас в ходе установки, а затем, они будут должны образом записаны в settings.php.

Если у вас уже создан settings.php, то при попытке установки нового сайта, он и будет использован для автозаполнения настроек.

¶Где находится settings.php?

Чаще всего вы можете обнаружить данный сайт по пути /sites/default, но это зависит от того, как произведена настройка Drupal и какой подход в разработке был использован.

По умолчанию проверяется только /sites/default, но если вы настроите мультисайтинг (присутствует /sites/sites.php), то поиск будет происходить по различным директориям.

Рассмотрим на примере. Если Drupal установлен по пути https://www.drupal.org:8080/mysite/test/ то файл settings.php будет искаться в следующих директориях, в порядке приоритета:

• sites/8080.www.drupal.org.mysite.test
• sites/www.drupal.org.mysite.test
• sites/drupal.org.mysite.test
• sites/org.mysite.test
• sites/8080.www.drupal.org.mysite
• sites/www.drupal.org.mysite
• sites/drupal.org.mysite
• sites/org.mysite
• sites/8080.www.drupal.org
• sites/www.drupal.org
• sites/drupal.org
• sites/org
• sites/default

¶Программное получение настроек

В Drupal присутствует специальный утилитарный объект \Drupal\Core\Site\Settings. При помощи данного объекта вы можете получать актуальные настройки которые используются для текущего запроса.

¶get()

Возвращает значение конкретной настройки, принимает два аргумента:

• $name: Название настройки значение которой необходимо получить.
• $default = NULL: (опционально) Значение по умолчанию, если оно не найдено в файле.

Данный метод вызовет ошибку если вы захотите получить значение для install_profile. Если вы хотите получить название инсталяционного профиля используйте сервис install_profile.

Пример:

$batch_size = Settings::get('entity_update_batch_size', 50);

¶getAll()

Возвращает все настройки и предназначен только для тестирования.

$settings = Settings::getAll();

¶getHashSalt()

Возвращает значение настройки hash_salt. Если данной настройки нет или она является пустой, то вызывается исключение.

$salt = Settings::getHashSalt();

¶Структура settings.php

¶$databases

В переменной $databases задаются настройки соединения с базами данных. Drupal имеет возможность работать в пределах одного запроса сразу с несколькими базами данных, в том числе разных типов.

Простой пример настройки подключения к БД:

$databases['default']['default'] = [
  'database' => 'databasename',
  'username' => 'sqlusername',
  'password' => 'sqlpassword',
  'host' => 'localhost',
  'port' => '3306',
  'driver' => 'mysql',
  'prefix' => '',
  'collation' => 'utf8mb4_general_ci',
];

Многие значения данного массива могут быть изменены под конкретные нужды проекта или системы.

Свойство driver отвечает какой драйвер соединения с БД должен использовать Drupal. Как правило, оно равно названию типа базы данных, например mysql или sqlite, но не всегда. Прочие свойства будут сильно зависеть от выбранного вами драйвера. Для SQLite вы должны указать файл баз данных в который Drupal может производить запись. Для большинства других драйверов вы должны указать username, password, host и database свойства.

Поддержка транзакций включена по умолчанию для всех драйверов что поддерживают данную возможность, включая MySQL. Для отключения данной возможности задайте свойству transactions значение FALSE.

Для каждой базы данных, опционально вы можете указать несколько «целей» БД. Целевая БД позволит Drupal пробовать отправлять некоторые запросы в другую БД, а если это не выйдет, будет использована БД по умолчанию. Это полезная особенность для репликаций БД. Drupal может подключаться к серверу с репликой когда это необходимо и если она недоступна, переключаться на основной сервер (термины основной сервер и реплика обычно обозначаются как master/slave в документациях БД).

Общий формат для массива $database следует структуре:

$databases['default']['default'] = $info_array;
$databases['default']['replica'][] = $info_array;
$databases['default']['replica'][] = $info_array;
$databases['extra']['default'] = $info_array;

В примере выше, $info_array — массив с настройками подключения БД описанные выше. Первая строка задаёт настройки для набора «default», которая имеет настройки подключения к БД по умолчанию «default» (второй ключ). Вторая и третья строки задают настройки для потенциальных реплик БД. Drupal выберет одно из значений случайным образом в пределах запроса. В четвёртой строке создаётся новая БД с именем «extra».

Опционально вы можете задать префикс для таблиц используя свойство prefix. Если префикс указан, название таблицы будет получать данный префикс перед основным названием. Убедитесь что вы указали допустимые символы и значения для БД, обычно это латинские буквы, цифры и нижнее подчёркивание. Если префиксов не требуется или не нужны, используется пустая строка ''.

Для того чтобы все таблицы были с префиксом, задайте необходимое значение в prefix:

'prefix' => 'main_',

Продвинутые пользователи могут добавлять или переопределять первичные команды, которые выполняются перед подключением к серверу баз данных, а также настройки подключения PDO.

Например, для включения возможности MySQL SELECT превышать системное значение max_join_size и уменьшить таймаут подключения к БД до 5 секунд, используется следующая конфигурация:

$databases['default']['default'] = [
  'init_commands' => [
    'big_selects' => 'SET SQL_BIG_SELECTS=1',
  ],
  'pdo' => [
    PDO::ATTR_TIMEOUT => 5,
  ],
];

Пример настройки подключения к PostgreSQL (pgsql):

$databases['default']['default'] = [
  'driver' => 'pgsql',
  'database' => 'databasename',
  'username' => 'sqlusername',
  'password' => 'sqlpassword',
  'host' => 'localhost',
  'prefix' => '',
];

Пример настройки подключения к SQLite (sqlite):

$databases['default']['default'] = [
  'driver' => 'sqlite',
  'database' => '/path/to/databasefilename',
];

¶$config_directories

Массив $config_directories задаёт пути в файловой систему до путей где необходимо хранить конфигурации. В процессе установки Drupal создаётся директория sync, которая используется для импортирования конфигураций. Также может быть указана active директория для хранения актуальных конфигураций. По умолчанию active не задаётся, так как эта информация хранится в БД.

Данная настройка автоматически задаётся и добавляется в конец файла в процессе установки.

Пример:

$config_directories = [
  CONFIG_SYNC_DIRECTORY => '/directory/outside/webroot',
];

¶$settings

В массиве $settings указываются настройки для Drupal которые могут корректировать его поведение.

¶Соль

Соль используемая для генерации одноразовых ссылок, токенов форм, ссылок отписки и т.д.

Значение для данной переменной задаётся случайной генерацией в процессе установки. Если вы поменяете это значение на рабочем сайте, то все ссылки одноразового входа будут инвалидированы.

Для более продвинутой защиты вы можете вынести значение соли за пределы Drupal и запрашивать его из файла или иных мест. Вы также должны убедиться что данный файл не попадает в бэкапы сайта и не хранится в БД.

Пример:

$settings['hash_salt'] = file_get_contents('/home/example/salt.txt');

¶Идентификатор деплоя

Контейнер Drupal для Dependency Injection автоматически инвалидируется и перестраивается при изменении версии ядра. Когда обновляете контриб или кастом модули которые меняют контейнер, изменение данного идентификатора также инвалидирует и перестроит контейнер как только код будет задеплоен.

Пример:

$settings['deployment_identifier'] = Drupal::VERSION;

¶Контроль доступа для update.php

Когда вы обновляете Drupal при помощи /update.php производится проверка на наличие прав доступа «Управление обновлениями» (administer software updates) у пользователя. Если у пользователя нету данных прав, то обновление не будет запущено.

Благодаря этой настройке вы можете временно отключить данную проверку, если по каким-то причинам у вас нет возможности авторизоваться под соответствующим пользователем или пользователя с такими правами не существует.

Значение TRUE — пропускает проверку прав, FALSE (по умолчанию) — будет проверять права доступа.

Пример:

$settings['update_free_access'] = FALSE;

¶Прокси

Если сайту необходимо обращаться во внешний интернет через прокси, вы можете указать соответствующие настройки.

Для различных запросов может использоваться различный прокси. Для этого имеется три настройки:

• $settings['http_client_config']['proxy']['http'] — для проксирования запросов с HTTP.
• $settings['http_client_config']['proxy']['https'] — для проксирования запросов с HTTPS.
• $settings['http_client_config']['proxy']['no'] — массив из доверенных хостов, запросы к которым будут идти напрямую, без использования прокси.

Пример:

$settings['http_client_config']['proxy']['http'] = 'http://proxy_user:proxy_pass@example.com:8080';
$settings['http_client_config']['proxy']['https'] = 'http://proxy_user:proxy_pass@example.com:8080';
$settings['http_client_config']['proxy']['no'] = ['127.0.0.1', 'localhost'];

¶Обратный прокси

Обратные прокси часто используются для улучшения производительности высоконагруженных сайтов и также могут предоставить новые способы кеширования, безопасности и шифрования. В окружении где Drupal находится за обратным прокси, должен быть получен реальный IP адрес клиента для корректной работы различных подсистем, таких как логирование, статистика и управление доступом. В самом простом сценарии прокси сервер добавляет заголовок X-Forwarded-For в запрос, который содержит IP адрес клиента. Тем не менее HTTP заголовки уязвимы к спуфингу, что позволяет получить доступ к заголовку X-Forwarded-For. Следовательно, Drupal требует указывать адреса всех удалённых прокси для корректной работы.

Включение данной настройки позволяет корректно определять IP адрес клиента. Если ваш сайт работает на шаред хостинге или не имеет обратного прокси, данные настройки должны быть закомментированы (по умолчанию).

Для того чтобы данная настройка работала вы должны указать все возможные IP адреса обратных прокси в reverse_proxy_addresses. Если полный список адресов не доступен в вашем окружении (например, вы используете CDN) вы можете указать $_SERVER['REMOTE_ADDR'] прямо в настройках. Но будьте аккуратны, это открывает возможности для спуфинга если вы не предпримите дополнительных мер предосторожности.

Вы также можете настроить доверенные HTTP заголовки для обратного прокси. Общие значения:

• \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL
• \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED

Имейте в виду что значение по умолчанию \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL | \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED небезопасно. Вы должны указать только те заголовки, которые используются обратным прокси.

Например \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL будет считать доверенными следующие заголовки: X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Port.

Пример:

use Symfony\Component\HttpFoundation\Request;$settings['reverse_proxy_trusted_headers'] = Request::HEADER_X_FORWARDED_ALL | Request::HEADER_FORWARDED;

¶Vary: Cookie

По умолчанию Drupal отправляет HTTP заголовок «Vary: Cookie» для всех анонимных пользователей. Это говорит HTTP прокси что он может возвращать результат страницы из своего локального кеша без обращения к веб-серверу если пользователь обращается с тем же заголовком Cookie как оригинальный запрос.

Без использования «Vary: Cookie», авторизованные пользователи также будут получать результат из анонимного кеша. Если сайт по большей части статичен и предназначен для анонимных пользователей, за исключением заранее известных редакторов и администраторов, то данный заголовок можно опустить.

Данное поведение позволяет организовать более продвинутое кеширование на стороне прокси и обратного прокси. Например, если пользователи будут слать разные куки файлы, они все равно будут получать содержимое из кеша. Тем не менее, авторизованные пользователи должны обращаться к сайту напрямую (в обход прокси и обратного прокси) для того чтобы не получать результаты страниц из кеша прокси.

Пример:

$settings['omit_vary_cookie'] = TRUE;

¶TTL кеша для ответов 4xx

Элементы кеша которые хранятся на основе URL приводят к увеличению общего числа кеш элементов. Данное поведение может стать проблемой на 404 страницах, которых может быть очень много. Для данных страницы вы можете задать свой собственный TTL (Time To Live) в секундах. По умолчанию это значение равняется одному часу (3600 секунд). Для того чтобы отключить кеширование 4хх ответов, нужно задать значение 0.

Пример:

$settings['cache_ttl_4xx'] = 3600;

¶Время жизни кеша форм

Form API Drupal хранит часть информации форм в кеше. По умолчанию время жизни данного кеша 6 часов (21600 секунд). Устаревшие данные удаляются при первом запуске cron.

При помощи данной настройки вы можете задать своё собственное время жизни кеша форм.

Пример:

$settings['form_cache_expiration'] = 21600;

¶Загрузчик классов

Если для PHP включено расширение APC, то для увеличения производительности используется загрузчик классов Symfony APC. Данное поведение можно отключить при помощи данной опции.

Пример:

$settings['class_loader_auto_detect'] = FALSE;

Если APC расширение не найдено, или оно отключено, то будет использован автозагрузчик Composer, который хорошо подходит для разработки, так как не сломается если код был перемещён в файловой системе. Вы также можете задекорировать базовый загрузчик с любым другим решением, а не только Symfony APC, так как все продакшен сайты должны иметь кеш для загрузчика в том или ином виде.

Для того чтобы задекорировать автозагрузчик, нужно переопределить переменную $class_loader.

Пример использования Symfony APC без автоматического обнаружения:

if ($settings['hash_salt']) {
  $prefix = 'drupal.' . hash('sha256', 'drupal.' . $settings['hash_salt']);
  $apc_loader = new ApcClassLoader($prefix, $class_loader);
  unset($prefix);
  $class_loader->unregister();
  $apc_loader->register();
  $class_loader = $apc_loader;
}

¶Разрешение авторизованных операций

Менеджер обновлений (модуль update) предоставляет администраторам сайта механизм безопасной установки обновлений для сайта напрямую через веб-интерфейс. На серверах с дополнительной защитой менеджер обновлений потребует предоставить доступы для SSH или FTP прежде чем операция будет выполнена. Это позволяет обновлять файлы сайта от лица пользователя который владеет ими, вместо того чтобы обновлять их под пользователем веб-сервера. На серверах где пользователь веб-сервера также является и владельцем файлов сайта запрос на доступ будет пропущен. Обычно такое поведение применимо для шаред хостингов, где пользователь веб-сервера и владельца сайта находятся в одной группе, что не очень безопасно.

Благодаря данной настройке вы можете отключить это поведение и обновление сайта будет доступно только по SSH и FTP.

Пример:

$settings['allow_authorize_operations'] = FALSE;

¶Права доступа файлов

При помощи настроек file_chmod_directory и file_chmod_file вы можете задать права по умолчанию для папки с файлами и непосредственно файлов. Значение должны быть задано в соответствии с Linux chmod в восьмеричном виде (с ведущим нулём).

Пример:

$settings['file_chmod_directory'] = 0775;
$settings['file_chmod_file'] = 0664;

¶Основной URL публичных файлов

В настройке file_public_base_url вы можете указать альтернативный основной URL который будет использован для публичных файлов.

Значение отличное от основного домена Drupal сайта будет использовано для доступа к публичным файлам. Эта настройка может быть использована как простая интеграция с CDN или для улучшения безопасности путём обслуживания загруженных пользователями файлов с другого домена или поддомена но ведущие на тот же сервер.

Например, если указать в настройке http://downloads.example.com/files то все пути типа /sites/default/files/js/js_tzTgUlQwCuDqAJy4wyzIGJDhQU5AS7XxLzo_MCisroE.js будут заменены на http://downloads.example.com/files/js/js_tzTgUlQwCuDqAJy4wyzIGJDhQU5AS7XxLzo_MCisroE.js.

Пример:

$settings['file_public_base_url'] = 'http://downloads.example.com/files';

¶Путь до публичных файлов

В настройке file_public_path вы можете поменять стандартный путь (sites/default/files) до папки где должны храниться публичные файлы. Указанная директория должна существовать и Drupal (веб-сервер) должен иметь права на запись в неё. Путь до директории должны быть относительно установки Drupal (index.php) и доступен из сети.

Пример:

$settings['file_public_path'] = 'sites/default/files';

¶Путь до приватных файлов

В настройке file_private_path вы можете указать путь до директории где будут храниться приватные файлы. Данная директория должна находиться за пределами установки Drupal (index.php) и не быть доступна из сети.

Пример:

$settings['file_private_path'] = '../private';

¶Интервал записи сессии

В настройке session_write_interval вы можете указать минимальный интервал в секундах, который должен пройти для записи данных сессии в БД после предыдущей записи. В целях производительности по умолчанию задано значение 180.

$settings['session_write_interval'] = 180;

¶Переопределение строк локали

Для того чтобы переопределить некоторые строки на вашем сайте без включения модуля Locale, вы можете добавить их записи в данную настройку. Данный функционал позволяет вам менять небольшие порции текста из интерфейса на необходимые вам.

Настройка задаётся с ключом locale_custom_strings_[langcode] — где [langcode] вы должны заменить на кодовое обозначение языка, в котором вы хотите производить замену. Например для русского языка будет locale_custom_strings_ru.

Пример:

$settings['locale_custom_strings_en'][''] = [
  'forum' => 'Discussion board',
  '@count min' => '@count minutes',
];

¶Тема оформления для режима обслуживания

В настройке maintenance_theme вы можете указать машинное имя темы оформления, которая должна использоваться для страниц, когда сайт находится в режиме обслуживания.

Данная настройки применятся только тогда, когда сайт явно находится на обслуживании. Не забудьте переопределить шаблон maintenance-page.html.twig на необходимый вам.

Пример:

$settings['maintenance_theme'] = 'bartik';

¶Хранилище активных конфигураций

По умолчанию, активные конфигурации хранятся в таблице {config} базы данных. Для того чтобы использовать отличное хранилище вы можете сделать следующие действия перед установкой Drupal:

• Создать «active» директорию и указать её в $config_directories. Для безопасности, эта папка должна находиться за пределами инсталяции Drupal.
• Переопределить значение для bootstrap_config_storage. В качестве значения должен быть объект который реализует \Drupal\Core\Config\StorageInterface.
• Переопределить сервис config.storage.active. Для этого новое определение должно быть помещено в services.yml файл рядом с settings.php файлом.

Пример:

$settings['bootstrap_config_storage'] = ['Drupal\Core\Config\BootstrapConfigStorageFactory', 'getFileStorage'];

¶Сервисы

В настройке container_yamls вы можете указывать дополнительные файлы сервисов который будут загружены. Пути должны быть относительно установки Drupal (index.php).

По умолчанию данная конфигурация загружает стандартный services.yml.

Пример:

$settings['container_yamls'][] = $app_root . '/' . $site_path . '/services.yml';

¶Класс Dependency Injection контейнера

В настройке container_base_class вы можете указать класс, который будет использован в качестве контейнера для Dependency Injection. Это может быть полезно для сбора информации о производительности и тестирования.

Пример:

$settings['container_base_class'] = '\Drupal\Core\DependencyInjection\Container';

¶Парсер YAML

В настройке yaml_parser_class вы можете указать класс, который будет вызываться для парсинга YAML (.yml) файлов. Например, данная возможность может оказаться полезной если вам нужен альтернативный парсерс. Класс должен реализовывать интерфейс \Drupal\Component\Serialization\SerializationInterface.

Пример:

$settings['yaml_parser_class'] = NULL;

¶Шаблоны доверенных хостов

Drupal может использовать механизм доверенных хостов Symfony для предотвращения спуфинга HTTP Host заголовка.

Для того чтобы включить данный механизм, необходимо указать доверенные хосты в $settings['trusted_host_patterns']. Это должен быть массив с регулярными выражениями, без разделителей, с хостами которым вы доверяете.

Пример:

$settings['trusted_host_patterns'] = [
  '^www\.example\.com$',
];

Данная настройка разрешит работать сайту только с запросами по адресу www.example.com.

Если у вас мультисайтинг или сайт имеет несколько доменных имён, то необходимо указать все доступные значения.

Например, чтобы разрешить сайту работать с запросами example.com и example.org, а также всеми поддоменами нужно задать следующую настройку:

$settings['trusted_host_patterns'] = [
  '^example\.com$',
  '^.+\.example\.com$',
  '^example\.org$',
  '^.+\.example\.org$',
];

¶Чёрный список директорий на сканирование

В настройке file_scan_ignore_directories вы можете задать название директорий которые должен игнорировать File API при сканировании.

По умолчанию запрещено сканирование node_mobules и bower_components для того чтобы избежать проблем при сканировании расширений Drupal (могут оказаться схожие файлы, но не являться расширением Drupal).

Пример:

$settings['file_scan_ignore_directories'] = [
  'node_modules',
  'bower_components',
];

¶Количество обрабатываемых сущностей за раз

В настройке entity_update_batch_size вы можете изменить какое количество сущностей будет обрабатываться за один этап обработки массовых операций в процессе обновлений.

Данная настройка используется ядром в хуках обновлений (hook_update() и hook_post_update()) при обработке больших объёмов сущностей. Это позволяет снизить потребление памяти и увеличить скорость обработки.

Также данная настройки иногда используется модулями как значение по умолчанию, чтобы сохранять требования к массовым операциям при больших объёмах данных.

Пример:

$settings['entity_update_batch_size'] = 50;

¶Резервная копия сущностей при обновлении

В настройке entity_update_backup вы можете включать и отключать создание резервных копий для таблиц сущностей с их данными при обновлении схем и полей.

Данные таблицы остаются в БД и их нужно удалять в ручном режиме. Это позволяет в случае проблем не потерять данные и иметь точку возврата.

Пример:

$settings['entity_update_backup'] = TRUE;

¶Отключение принудительного изменения прав на запись для директории сайта

При помощи настройки skip_permissions_hardening вы можете выключить принудительное удаление прав на запись для папки сайта (/sites/default).

По умолчанию Drupal регулярно сбрасывает права доступа к папке сайта, полностью убирая возможность записи. Это может повлечь за собой проблемы при управлении сайтом при помощи Composer и чаще всего встречается при попытке создания скафолд файлов в соответствующей директории плагином drupal/core-composer-scaffold.

Если вы не работаете с сайтом через FTP и управляете им при помощи Composer, вы можете без последствий отключить данное поведение.

Пример:

$settings['skip_permissions_hardening'] = TRUE;

¶Проверка схемы БД для синонимов

В настройке system.path_alias_schema_check вы можете отключить проверку схему БД при сохранении сущностей синонимов.

В Drupal 8.8.0 синонимы были конвертированы в сущности и их хранение соответственно изменилось. Если вы не применяли соответствующие обновления БД, то при попытке сохранить синонимы используя сущности будет фатальная ошибка. В Drupal 8.9.0 была добавлена проверка что данные обновления применены, и если их нет, мягко выдавать ошибку и продолжать выполнение. При помощи данной настройки вы можете отключить данное поведение.

Пример:

$settings['system.path_alias_schema_check'] = FALSE;

¶Включение классических миграций нод

При помощи настройки migrate_node_migrate_type_classic вы можете активировать старую версию миграций нод, которая предоставлялась ядром до Drupal 8.9.0.

Начиная с Drupal 8.9.0 появились новые миграции, которые мигрируют ноды, со всеми их переводами, ревизиями и переводами ревизий, которые отличаются от тех что были ранее. Если ваш код или миграции основывались на старых миграциях, данная настройка позволит вернуть прежнее поведение.

Пример:

$settings['migrate_node_migrate_type_classic'] = TRUE;

¶$config

При помощи переменной $config вы можете переопределить значения конфигураций на глобальном уровне. Как правило, это не требуется. Эта возможность полезна для переопределения адреса сайта или путей для локального окружения.

Существуют конфигурации которые опасно перезаписывать. Например перезапись списка активных модулей для core.extension лишь сломает сайт, так как изменения не вызовут соответствующие процессы установки и деинсталяции. Другой пример это хранилища полей, которые также повлекут за собой проблемы, так как эти изменения не вызовут изменения схемы БД. Поэтому часть из данных конфигураций не подвержены данным изменениям.

Также учтите, что изменение данных значений через текущий подход — не вызовет никаких событий, и подписчики ничего об этом не узнают.

Пример:

$config['system.file']['path']['temporary'] = '/tmp';
$config['system.site']['name'] = 'My Drupal site';
$config['system.theme']['default'] = 'stark';
$config['user.settings']['anonymous'] = 'Visitor';

¶Быстрые 404 страницы

Drupal может генерировать полноценное оформление для 404 ответов. Тем не менее часть ответов происходит на запросы картинок или прочих файлов, которые не отображаются для пользователя, так как это создаст дополнительную нагрузку и потребление интернет канала.

При помощи изменения некоторых конфигурационных настроек, вы можете настроить быстрые 404 ответы в соответствии с паттернами:

• $config['system.performance']['fast_404']['exclude_paths']: Регулярное выражение для путей которые необходимо исключить. Например, картинки, сгенерированные для стилей изображений или динамически обрезанные картинки. Значение по умолчанию также исключает файлы из приватной файловой системы. Если вы хотите добавить дополнительные пути, вы можете дополнить регулярно выражения при помощи выражения |path.
• $config['system.performance']['fast_404']['paths']: Регулярное выражение для путей 404 ответ для которых нужно отдавать быстро, вместо полностью оформленной страницы. Если вы не используете алиасы с окончаниями htm или html, вы можете добавить выражение |s?html? чтобы для таких путей отдавались быстрые 404 ответы.
• $config['system.performance']['fast_404']['html']: HTML разметка, которую необходимо возвращать в случае активации быстрого ответа 404.

Пример:

$config['system.performance']['fast_404']['exclude_paths'] = '/\/(?:styles)|(?:system\/files)\//';
$config['system.performance']['fast_404']['paths'] = '/\.(?:txt|png|gif|jpe?g|css|js|ico|swf|flv|cgi|bat|pl|dll|exe|asp)$/i';
$config['system.performance']['fast_404']['html'] = '<!DOCTYPE html><html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The requested URL "@path" was not found on this server.</p></body></html>';

¶Настройки PHP

В определённых местах settings.php файла вы можете встретиться с различными примерами настроек для PHP которые могут вам пригодиться.

Для задавания настроек PHP нужно использовать ini_set().

¶Настройка во время выполнения

Если у вас возникают ситуации когда пользователь публикует большой объём текста, а результат обрезается в момент просмотра, при этом, в режиме редактирования текст на месте и может быть отредактирован, это значит что фильтры Drupal не располагают достаточным объёмом памяти для обработки текста. Для того чтобы решить данную проблему, вы можете переопределить настройки во время выполнения.

Пример:

ini_set('pcre.backtrack_limit', 200000);
ini_set('pcre.recursion_limit', 200000);

¶Изменения в релизах

• Drupal 8.2.0 (05.10.2016): Возможность указывать индивидуальные префиксы таблиц помечена устаревшей.
• Drupal 8.7.0 (01.05.2019): Добавлена настройка entity_update_backup.
• Drupal 8.8.0 (04.12.2019): Добавлена настройка system.path_alias_schema_check.
• Drupal 8.8.0 (04.12.2019): Переменная $config_directories помечена устаревшей.
• Drupal 8.9.0 (03.06.2020): Добавлена настройка migrate_node_migrate_type_classic.

¶Смотрите также

• settings.local.php — локальные настройки окружения.