Navigation
• eZ Documentation Center
 

This is outdated documentation made for eZ Publish Platform 5.1. It is being moved into the eZ Publish 5.x documentation, so please go there for most up-to-date documentation.

Skip to end of metadata
Go to start of metadata

As eZ Publish legacy is part of eZ Publish 5, you might want to access its settings (i.e. not migrated extension). Regarding this, a LegacyConfigResolver has been implemented, allowing the access to the legacy settings.

LegacyConfigResolver

The LegacyConfigResolver works in the same way the main ConfigResolver presented in the configuration documentation. However, it has its own specification.

  • Parameter name must be the combination of the INI block and parameter name (<iniGroupName>.<paramName>, e.g. DebugSettings.DebugOutput).
  • Namespace is the INI file name, without .ini suffix (e.g. image for image.ini).
  • Scope can still be a specific siteaccess to look into (still defaults to current siteaccess)

Example

Best practices for migration

It might happen that your eZ Publish application still relies on legacy extensions (yours or from the community) that have not been migrated yet to eZ Publish 5. In this case the LegacyConfigResolver can be useful, but the problem is that once the extension is migrated you will then need to change your code to use the main config resolver, which can be a bit tedious on large applications.

Actually, the main config resolver is set in such a way that it chains the different available resolvers (i.e. the main one and the legacy one). The ChainConfigResolver always checks the main ConfigResolver first, and if no parameter is found, it fallbacks to the LegacyConfigResolver.

So the example described above could be done in the following way:

The main difference is that we don't explicitly call the LegacyConfigResolver. The benefit is that once the settings are migrated to work with eZ Publish 5 (and assuming that these settings are named in the same way), there will be absolutely no change to do in your code! The ChainConfigResolver will seamlessly use the new configuration files.

Note for extension developers

Considering what was explained above, the best practice for extension migration regarding configuration is to keep a compatible format.

Example for SQLIImport

Legacy INI settings:

sqliimport.ini for ezdemo_site siteaccess

Would become:

Usage in a controller:

 

 

  • No labels