-
-
Notifications
You must be signed in to change notification settings - Fork 3
Configuration
- Introduction
- Default values
- Secret values
- Environment specific non-secret values
- Setting the right environment
- How configuration values are loaded
- Accessing configuration values
The framework main files are located inside the directory config/
.
The project environment configuration values are inside config/env/
.
All configuration files are loaded in the config/settings.php
file.
The default and non-sensitive config values are inside config/defaults.php
.
This file should contain all keys even the ones that would hold secret values
(set to null
because the file is public) to act as template
that will be overwritten by the other configuration files.
Environment-specific secret values are stored in config/env/env.php
.
This file should be added to the .gitignore
file to not be pushed accidentally.
Development env values are in the file config/env/env.dev.php
.
This file contains
every non-secret configuration on the development machine such as
the error reporting setting and the dev database name.
When testing, this file won't be loaded so everything relevant for testing
that is not in or different from defaults.php
should be defined in
env.test.php
.
The environment values for integration testing (e.g. database name) are stored inside
config/env/env.test.php
.
Production env values are in the file config/env/env.prod.php
. This file contains
every non-secret configuration for the production environment on the remote
server, for instance.
The configuration values for the GitHub Actions CI/CD pipeline are in the file
config/env/env.github.php
.
They load the env.test.php
values with require
(and not require_once
because the values
should be loaded for each test case, not only once) and may contain
additional specific values for the GitHub environment such as other database credentials.
In order for the file settings.php
to load the correct environment-specific
values, the APP_ENV
environment variable has to be set.
For the production config values to be loaded, the following line has to be in
the prod secret env.php
:
$_ENV['APP_ENV'] = 'prod';
The APP_ENV
environment variable for testing is set in the phpunit.xml
file:
<!-- ... -->
<php>
<env name="APP_ENV" value="test"/>
</php>
<!-- ... -->
'dev'
is the default fallback value for APP_ENV
if it is not set.
The dev
value should not be set anywhere because if it were in the env.php
file of the
development machine, it would overwrite the test
value from the phpunit.xml
file when testing.
The APP_ENV
environment variable for the GitHub Actions Build test is set in the workflow file.
File: .github/workflows/build.yml
# ...
jobs:
run:
steps:
- name: Run test suite
run: composer test
env:
APP_ENV: github
PHP_CS_FIXER_IGNORE_ENV: 1
config/settings.php
combines and returns all the relevant configuration
file's values.
They are loaded in this order:
- File
config/defaults.php
- File
config/env/env.php
- Depending on what
APP_ENV
is defined, the environment-specific file is loaded (ifAPP_ENV
is "test", it will loadenv.test.php
, if it is "dev" it'll loadenv.dev.php
and if it's "prod", it'll loadenv.prod.php
etc.).
The 'settings'
key is defined in the
DI container
and can be accessed with
$container->get('settings')
.
File: config/container.php
return [
'settings' => function () {
return require __DIR__ . '/settings.php';
},
LoggerInterface::class => function (ContainerInterface $container) {
$loggerSettings = $container->get('settings')['logger'];
// ...
},
// ...
];
In most files, the $container
instance is not available and the configuration values have to be
accessed with a utility class Settings.php
.
It's not part of the domain logic (the core business logic), but rather supports the domain which is an infrastructure concern.
File: src/Infrastructure/Utility/Settings.php
<?php
namespace App\Infrastructure\Utility;
class Settings
{
private array $settings;
public function __construct(array $settings)
{
$this->settings = $settings;
}
public function get(string $key): mixed
{
return $this->settings[$key] ?? null;
}
}
The Settings
class is instantiated in the container.php
file and added to the DI container.
File: config/container.php
// ...
Settings::class => function (ContainerInterface $container) {
return new Settings($container->get('settings'));
},
// ...
The Settings
class can now be injected into any class that needs to access a configuration value,
and it can use the get()
method to retrieve values from it.
File: src/Domain/Example/ExampleClass.php
<?php
namespace App\Domain\Example;
use App\Infrastructure\Utility\Settings;
class ExampleClass
{
private array $exampleSettings;
public function __construct(Settings $settings)
{
$this->exampleSettings = $settings->get('example_key');
}
}
Slim app basics
- Composer
- Web Server config and Bootstrapping
- Dependency Injection
- Configuration
- Routing
- Middleware
- Architecture
- Single Responsibility Principle
- Action
- Domain
- Repository and Query Builder
Features
- Logging
- Validation
- Session and Flash
- Authentication
- Authorization
- Translations
- Mailing
- Console commands
- Database migrations
- Error handling
- Security
- API endpoint
- GitHub Actions
- Scrutinizer
- Coding standards fixer
- PHPStan static code analysis
Testing
Frontend
Other