Настройка
Каждый фреймворк использует файлы конфигурации для определения многочисленных параметров и начальных настроек. Файлы конфигурации CodeIgniter определяют простые классы, где необходимые настройки являются открытыми свойствами.
В отличие от многих других фреймворков, настраиваемые элементы CodeIgniter не содержатся в одном файле. Вместо этого каждый класс, которому требуются настраиваемые элементы, будет иметь файл конфигурации с тем же именем, что и класс, который его использует. Вы найдете файлы конфигурации приложения в папке /app/Config.
- Работа с файлами конфигурации
- Создание файлов конфигурации
- Переменные среды
- Переменные среды и CodeIgniter
- Вложенные переменные
- Именованные переменные
- Классы конфигурации и переменные среды
- Переменные среды как замены данных
- Обращение с переменными среды как с массивами
- Обработка различных сред
- Регистраторы
Работа с файлами конфигурации
Вы можете получить доступ к файлам конфигурации для своих классов несколькими способами.
-
Используя ключевое слово
newдля создания экземпляра:// Creating new configuration object by hand $config = new \Config\Pager();
-
Используя функцию
config():// Get shared instance with config function $config = config('Pager'); // Access config class with namespace $config = config( 'Config\\Pager' ); // Creating a new object with config function $config = config('Pager', false);
Все свойства объекта конфигурации являются общедоступными, поэтому вы можете получить доступ к настройкам, как к любому другому свойству:
$config = config('Pager');
// Access settings as object properties
$pageSize = $config->perPage;
Если пространство имен не указано, оно будет искать файл во всех определенных пространствах имен, а также в /app/Config/.
Все файлы конфигурации, поставляемые с CodeIgniter, имеют пространство имен Config. Использование этого пространства имен в вашем приложении обеспечит наилучшую производительность, так как оно точно знает, где найти файлы.
Вы можете поместить файлы конфигурации в любую папку, которую хотите, используя другое пространство имен. Это позволяет разместить файлы конфигурации на сервере в папку, которая недоступна через веб, сохраняя ее в /app для простого доступа во время разработки.
Создание файлов конфигурации
Когда вам нужен новый файл конфигурации, сначала создайте новый файл в нужном месте. Рекомендуемое местоположение (для большинства случаев) — /app/Config. Класс должен использовать соответствующее пространство имен и должен расширять CodeIgniter\Config\BaseConfig для обеспечения возможности получения настроек, специфичных для среды.
Определите класс и заполните его общедоступными свойствами, которые представляют ваши настройки.:
<?php
namespace Config;
use CodeIgniter\Config\BaseConfig;
class CustomClass extends BaseConfig
{
public $siteName = 'My Great Site';
public $siteEmail = 'webmaster@example.com';
}
Переменные среды
Одним из лучших современных методов настройки приложения является использование переменных среды. Одна из причин в том, что переменные среды легко изменять между развертываниями, не изменяя код. Конфигурация может сильно меняться между развертываниями, но код — нет. Например, нескольким средам, таким как локальная машина разработчика и сервер производства, обычно требуются разные значения конфигурации для каждой конкретной настройки.
Переменные среды также должны использоваться для всего конфиденциального, такого как пароли, ключи API или другие конфиденциальные данные.
Переменные среды и CodeIgniter
CodeIgniter упрощает и безболезненно устанавливает переменные среды, используя файл «dotenv». Это название происходит от имени файла, который начинается с точки перед текстом «env».
CodeIgniter ожидает, что файл .env будет находиться в корне вашего проекта рядом с каталогами system и app. В CodeIgniter поставляется шаблонный файл, расположенный в корне проекта под названием env (Обратите внимание, что в начале нет точки (.)). В нем есть большой набор переменных, которые может использовать ваше приложение, которым присвоены пустые, подставленные или значения по умолчанию. Вы можете использовать этот файл в качестве отправной точки для вашего приложения, переименовав шаблон в .env или скопировав его, назвав .env.
Важно
Убедитесь, что файл .env НЕ отслеживается вашей системой управления версиями. Для git это означает добавление его в .gitignore. Если этого не сделать, конфиденциальные данные могут быть опубликованы.
Настройки хранятся в файлах .env как простой набор пар «имя/значение», разделенных знаком равенства.
S3_BUCKET = dotenv SECRET_KEY = super_secret_key CI_ENVIRONMENT = development
Когда ваше приложение выполняется, .env загружается автоматически, а переменные помещаются в среду. Если переменная уже существует в среде, она НЕ будет перезаписана. К загруженным переменным среды можно получить доступ, используя любое из следующих: getenv(), $_SERVER, или $_ENV.
$s3_bucket = getenv('S3_BUCKET');
$s3_bucket = $_ENV['S3_BUCKET'];
$s3_bucket = $_SERVER['S3_BUCKET'];
Важно
Обратите внимание, что ваши настройки из файла .env добавляются в переменные среды. Как следствие, если ваше приложение CodeIgniter (например) генерирует var_dump($_ENV) или phpinfo() (для отладки или по другим законным причинам), ваши защищенные учетные данные будут опубликованы.
Вложенные переменные
Чтобы сэкономить на наборе текста, вы можете повторно использовать переменные, которые вы уже указали в файле, заключив имя переменной в ${...}
BASE_DIR="/var/webroot/project-root"
CACHE_DIR="${BASE_DIR}/cache"
TMP_DIR="${BASE_DIR}/tmp"
Именованные переменные
Бывают случаи, когда у вас есть несколько переменных с одним именем. Система должна как-то определять, какое значение должно использоваться. Эта проблема решается с помощью «пространства имен» переменных.
Именованные переменные используют обозначение точек, чтобы квалифицировать имена переменных, чтобы они были уникальными при внедрении в среду. Это делается с помощью отличительного префикса, за которым следует точка (.), а затем само имя переменной.
// not namespaced variables name = "George" db=my_db // namespaced variables address.city = "Berlin" address.country = "Germany" frontend.db = sales backend.db = admin BackEnd.db = admin
Классы конфигурации и переменные среды
При создании экземпляра класса конфигурации все переменные среды с именами, относящимися к пространству имен, рассматриваются для объединения в свойства объекта конфигурации.
Если префикс именованной переменной точно соответствует пространству имен класса конфигурации, то хвостовая часть настройки (после точки) обрабатывается как свойство конфигурации. Если она соответствует существующему свойству конфигурации, значение переменной среды заменит соответствующее значение из файла конфигурации. Если совпадений нет, свойства класса конфигурации остаются неизменными. В этом случае префикс должен быть полным (чувствительным к регистру) именем пространства имен класса.
Config\App.forceGlobalSecureRequests = true Config\App.CSPEnabled = true
Примечание
И префикс пространства имен, и имя свойства чувствительны к регистру. Они должны точно совпадать с полными именами пространства имен и свойств, определенными в файле класса конфигурации.
То же самое относится к короткому префиксу, который является пространством имен, использующим только строчную версию имени класса конфигурации. Если короткий префикс соответствует имени класса, значение из .env заменит значение из файла конфигурации.
app.forceGlobalSecureRequests = true app.CSPEnabled = true
Примечание
При использовании короткого префикса имена свойств по-прежнему должны точно соответствовать определенному в классе имени.
В некоторых средах имена переменных с точками недопустимы. В этом случае вы также можете использовать _ в качестве разделителя.
app_forceGlobalSecureRequests = true app_CSPEnabled = true
Переменные среды как замены данных
Очень важно всегда помнить, что переменные среды, содержащиеся в .env, являются только заменами существующих данных. Это означает, что вы не можете ожидать заполнить .env всеми заменами ваших конфигураций, но не иметь ничего, чтобы получить эти замены в соответствующем(их) файле(ах) конфигурации.
.env служит только для заполнения или замены значений в ваших файлах конфигурации. Сказанное выше означает, что ваши файлы конфигурации должны иметь контейнер или свойство-приемник для этих замен. Добавление так много переменных в .env без ничего, чтобы их получить, бесполезно.
Проще говоря, вы не можете просто поместить app.myNewConfig = foo в .env и ожидать, что ваш Config\App волшебным образом получит это свойство и значение во время выполнения.
Обращение с переменными среды как с массивами
Именованная переменная среды может быть далее обработана как массив. Если префикс соответствует классу конфигурации, то остальная часть имени переменной среды обрабатывается как ссылка на массив, если она также содержит точку.
// regular namespaced variable Config\SimpleConfig.name = George // array namespaced variables Config\SimpleConfig.address.city = "Berlin" Config\SimpleConfig.address.country = "Germany"
Если это относилось к объекту конфигурации SimpleConfig, приведенный выше пример обрабатывался бы как:
$address['city'] = "Berlin"; $address['country'] = "Germany";
Любые другие элементы свойства $address оставались бы неизменными.
Вы также можете использовать имя свойства массива как префикс. Если в файле среды была следующая информация, результат был бы таким же, как выше.
// array namespaced variables Config\SimpleConfig.address.city = "Berlin" address.country = "Germany"
Обработка различных сред
Настройка нескольких сред легко выполняется с помощью отдельных файлов .env со значениями, измененными для соответствия потребностям данной среды.
Файл не должен содержать всех возможных настроек для каждого класса конфигурации, используемого приложением. На самом деле, он должен включать только те элементы, которые специфичны для среды или являются конфиденциальными данными, такими как пароли и ключи API, и другую информацию, которая не должна быть раскрыта. Но все, что меняется между развертываниями, приемлемо.
В каждой среде разместите файл .env в корневой папке проекта. В большинстве случаев он будет на одном уровне с каталогами system и app.
Не отслеживайте файлы .env с помощью системы управления версиями. Если вы это сделаете, и репозиторий станет общедоступным, вы разместите конфиденциальную информацию, доступную всем.
END_OF_DOCUMENT_MARKERРегистраторы
«Регистраторы» — это любые другие классы, которые могут предоставлять дополнительные свойства конфигурации. Регистраторы обеспечивают возможность изменения конфигурации во время выполнения в разных именованных пространствах и файлах. Существует два способа реализации регистратора: неявный и явный.
Примечание
Значения из .env всегда имеют приоритет над регистраторами.
Неявные регистраторы
Любое именованное пространство может определять регистраторы, используя файл Config/Registrar.php, если обнаружение включено в Модули. Эти файлы являются классами, методы которых имеют имена каждой конфигурационной части, которую вы хотите расширить. Например, сторонний модуль может захотеть предоставить дополнительный шаблон для Pager , не перезаписывая то, что уже сконфигурировал разработчик. В src/Config/Registrar.php будет класс Registrar с единственным методом Pager() (обратите внимание на чувствительность к регистру):
class Registrar
{
public static function Pager(): array
{
return [
'templates' => [
'module_pager' => 'MyModule\Views\Pager',
],
];
}
}
Методы регистратора всегда должны возвращать массив, ключи которого соответствуют свойствам целевого файла конфигурации. Существующие значения объединяются, а свойства регистратора имеют приоритет при перезаписи.
Явные регистраторы
Файл конфигурации также может явно указать любое количество регистраторов. Это делается путем добавления свойства $registrars в ваш файл конфигурации, содержащего массив имен кандидатных регистраторов.:
public static $registrars = [
SupportingPackageRegistrar::class
];
Чтобы выступать в роли «регистратора», идентифицированные классы должны иметь статическую функцию с тем же именем, что и конфигурационный класс, и она должна возвращать ассоциативный массив настроек свойств.
При создании объекта конфигурации он будет перебирать указанные классы в $registrars. Для каждого из этих классов он вызовет метод с именем конфигурационного класса и включит любые возвращенные свойства.
Пример конфигурации для этого:
<?php
namespace App\Config;
use CodeIgniter\Config\BaseConfig;
class MySalesConfig extends BaseConfig
{
public $target = 100;
public $campaign = "Winter Wonderland";
public static $registrars = [
'\App\Models\RegionalSales'
];
}
… и связанная региональная модель продаж может выглядеть так:
<?php
namespace App\Models;
class RegionalSales
{
public static function MySalesConfig()
{
return [
'target' => 45,
'actual' => 72,
];
}
}
В приведенном выше примере, когда MySalesConfig будет создан, он получит два объявленных свойства, но значение свойства $target будет переопределено, рассматривая RegionalSales как «регистратора». Результирующие свойства конфигурации:
$target = 45; $campaign = "Winter Wonderland";
© 2014–2020 British Columbia Institute of Technology
Licensed under the MIT License.
https://codeigniter.com/user_guide/general/configuration.html