Configuration

The Basics

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.

Basic configuration handling in eZ Platform is similar to what is commonly possible with Symfony. Regarding this, you can define key/value pairs in your configuration files, under the main parameters key (like in parameters.yml).

Internally and by convention, keys follow a dot syntax where the different segments follow your configuration hierarchy. Keys are usually prefixed by a namespace corresponding to your application. Values can be anything, including arrays and deep hashes.

eZ Platform core configuration is prefixed by ezsettings namespace, while internal configuration (not to be used directly) is prefixed by ezpublish namespace.

For configuration that is meant to be exposed to an end-user (or end-developer), it's usually a good idea to also implement semantic configuration.

Note that it is also possible to implement SiteAccess aware semantic configuration.

Example

Configuration

Usage from a controller

Dynamic configuration with the ConfigResolver

In eZ Platform it is fairly common to have different settings depending on the current siteaccess (e.g. languages, view provider configuration).

Scope

Dynamic configuration can be resolved depending on a scope.

Available scopes are (in order of precedence) :

global
SiteAccess
SiteAccess group
default

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 risk, as unexpected behavior can occur.

ConfigResolver Usage

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 the different scopes available for a given namespace to find the appropriate parameter.

In order to work with the config resolver, your dynamic settings must comply internally with the following name format: <namespace>.<scope>.parameter.name.

The following configuration is an example of internal usage inside the code of eZ Platform.

Namespace + scope example

Both getParameter() and hasParameter() can take 3 different arguments:

$paramName (i.e. the name of the parameter you need)
$namespace (i.e. your application namespace, myapp in the previous example. If null, the default namespace will be used, which is ezsettings by default)
$scope (i.e. a siteaccess name. If null, the current siteaccess will be used)

Inject the ConfigResolver in your services

Instead of injecting the whole ConfigResolver service, you may directly inject your SiteAccess-aware settings (aka dynamic settings) into your own services.

You can use the ConfigResolver in your own services whenever needed. To do this, just inject the ezpublish.config.resolver service:

Custom locale configuration

If you need to use a custom locale they can also be configurable in ezplatform.yml, adding them to the conversion map:

ezpublish:
    # Locale conversion map between eZ Publish format (i.e. fre-FR) to POSIX (i.e. fr_FR). 
    # The key is the eZ Publish locale. Check locale.yml in EzPublishCoreBundle to see natively supported locales.
    locale_conversion:
        eng-DE: en_DE

A locale conversion map example can be found in the core bundle, on locale.yml.

General

Please go to the current Technical Documentation