Important
Configuration is tightly related to the service container.
To fully =
understand the following content, you need to be familiar with Symfony's service container and its configuration.<=
/p>
Basic configuration handling in eZ Platform is similar to what is common= ly possible with Symfony. Regarding this, you can define key/value pairs in= your configuration files, under the main paramete= rs key (like in parameters.yml).
Internally and by convention, keys follow a dot syntax&= nbsp;where the different segments follow your configuration hierarchy. Keys= are usually prefixed by a namespace corresponding to yo= ur application. Values can be anything, including arrays and deep h= ashes.
For configuration that is meant to be exposed to an end-user (or end-dev= eloper), it's usually a good idea to also implement semantic configuration.
Note that it is also possible to implement SiteAccess awa= re semantic configuration.
parameters:
myapp.parameter.name: someValue
myapp.boolean.param: true
myapp.some.hash:
foo: bar
an_array: [apple, banana, pear]=20
// Inside a controller $myParameter =3D $this->container->getParameter( 'myapp.parameter.nam= e' );=20
In eZ Platform it is fairly common to have different settings depending = on the current siteaccess (e.g. languages, view provider configuration).
Dynamic configuration can be resolved depending on a scope.
Available scopes are (in order of precedence) :
It gives the opportunity to define settings for a given siteaccess, for = instance, like in the legacy INI override system.
This mechanism is not limited to eZ Platform internal settings (aka = ;ezsettings namespace) and is applicable for= specific needs (bundle-related, project-related, etc.).
Always prefer semantic configuration especially for internal eZ settings=
.
Manually editing internal eZ settings is possible, but at your own ris=
k, as unexpected behavior can occur.
Dynamic configuration is handled by a config resolver. =
It consists in a service object mainly exposing hasParameter() and getParameter() methods. The idea is to check th=
e different scopes available for a given namespace t=
o find the appropriate parameter.
In order to work with the config resolver, your dynamic settings must co=
mply internally with the following name format: <namespace>.<=
;scope>.parameter.name.
parameters:
# Some internal configuration
ezsettings.default.content.default_ttl: 60
ezsettings.ezdemo_site.content.default_ttl: 3600
# Here "myapp" is the namespace, followed by the siteaccess name as the=
parameter scope
# Parameter "foo" will have a different value in ezdemo_site and ezdemo=
_site_admin
myapp.ezdemo_site.foo: bar
myapp.ezdemo_site_admin.foo: another value
# Defining a default value, for other siteaccesses
myapp.default.foo: Default value
# Defining a global setting, used for all siteaccesses
#myapp.global.some.setting: This is a global value=20
// Inside a controller, assuming siteaccess being "ezdemo_site" /** @var $configResolver \eZ\Publish\Core\MVC\ConfigResolverInterface **/ $configResolver =3D $this->getConfigResolver(); // ezsettings is the default namespace, so no need to specify it // The following will resolve ezsettings.<siteaccessName>.content.def= ault_ttl // In the case of ezdemo_site, will return 3600. // Otherwise it will return the value for ezsettings.default.content.defaul= t_ttl (60) $locationViewSetting =3D $configResolver->getParameter( 'content.default= _ttl' ); $fooSetting =3D $configResolver->getParameter( 'foo', 'myapp' ); // $fooSetting's value will be 'bar' // Force scope $fooSettingAdmin =3D $configResolver->getParameter( 'foo', 'myapp', 'ezd= emo_site_admin' ); // $fooSetting's value will be 'another value' // Note that the same applies for hasParameter()=20
Both getParameter() and hasParameter()=
can take 3 different arguments:
$paramName (i.e. the name of the parameter you need)<=
/li>
$namespace (i.e. your application namespace, $scope (i.e. a siteaccess name. If null, the current =
siteaccess will be used)Instead of injecting the whole ConfigResolver service, you may directly = inject your SiteAccess-aware settings (aka dynamic settings) int= o your own services.
You can use the ConfigResolver in your own services whe=
never needed. To do this, just inject the ezpublish.config.re=
solver service:
parameters:
my_service.class: My\Cool\Service
services:
my_service:
class: %my_service.class%
arguments: [@ezpublish.config.resolver]=20
<?php
namespace My\Cool;
use eZ\Publish\Core\MVC\ConfigResolverInterface;
class Service
{
/**
* @var \eZ\Publish\Core\MVC\ConfigResolverInterface
*/
private $configResolver;
public function __construct( ConfigResolverInterface $configResolver )
{
$this->configResolver =3D $configResolver;
$myParam =3D $this->configResolver->getParameter( 'foo', 'mya=
pp' );
}
// ...
}=20
If you need to use a custom locale they can also be configurable in
ezpublish:
# Locale conversion map between eZ Publish format (i.e. fre-FR) to POSI=
X (i.e. fr_FR).
# The key is the eZ Publish locale. Check locale.yml in EzPublishCoreBu=
ndle to see natively supported locales.
locale_conversion:
eng-DE: en_DE=20
A locale conversion map example can be found=
in the core bundle, on locale.yml.