Message-ID: <1084342103.3472.1485853329547.JavaMail.confluence@ip-10-127-227-164> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3471_1968069506.1485853329547" ------=_Part_3471_1968069506.1485853329547 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
As eZ Publish legacy is part of eZ Publish 5, you might want to access i= ts settings (i.e. not migrated extension). Regarding this, a Legacy= ConfigResolver has been implemented, allowing the access to the le= gacy settings.
The LegacyConfigResolver
works in the same way the main
<iniGroupName>.<paramName><=
/code>
, e.g. DebugSettings.DebugOutput
).
// Inside a controller $legacyResolver =3D $this->get( 'ezpublish_legacy.config.resolver' ); // Get [DebugSettings].DebugOutput from site.ini $debugOutput =3D $legacyResolver->getParameter( 'DebugSettings.DebugOutp= ut' ); // Get [ImageMagick].ExecutablePath from image.ini $imageMagickPath =3D $legacyResolver->getParameter( 'ImageMagick.Executa= blePath', 'image' ); // Get [DatabaseSettings].Database from site.ini, for ezdemo_site_admin sit= eaccess $databaseName =3D $legacyResolver->getParameter( 'DatabaseSettings.Datab= ase', 'site', 'ezdemo_site_admin' ); // Note that the examples above are also applicable for hasParameter().=20
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 b= e useful, but the problem is that once the extension is migrated you will t= hen 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 o=
ne and the legacy one). The ChainConfigResolver always che=
cks the main ConfigResolver
first, and if no parameter is foun=
d, it fallbacks to the LegacyConfigResolver
.
So the example described above could be done in the following way:
// Inside a controller // Get the (chain) ConfigResolver $configResolver =3D $this->getConfigResolver(); // Get [DebugSettings].DebugOutput from site.ini $debugOutput =3D $configResolver->getParameter( 'DebugSettings.DebugOutp= ut' ); // Get [ImageMagick].ExecutablePath from image.ini $imageMagickPath =3D $configResolver->getParameter( 'ImageMagick.Executa= blePath', 'image' ); // Get [DatabaseSettings].Database from site.ini, for ezdemo_site_admin sit= eaccess $databaseName =3D $configResolver->getParameter( 'DatabaseSettings.Datab= ase', 'site', 'ezdemo_site_admin' );=20
The main difference is that we don't explicitly call the LegacyC=
onfigResolver. The benefit is that once the settings are migrated =
to work with eZ Publish 5 (and assuming that these settings are named in th=
e same way), there will be absolutely no change to do in your code! The
Considering what was explained above, the best practice for extension mi= gration regarding configuration is to keep a compatible format.
Legacy INI settings:
[ImportSettings] # User ID of the XML Import Robot # If none provided, site.ini [UserSettings]/AnonymousUserID will be used RobotUserID=3D14 # Max time to wait for each Stream (in seconds) StreamTimeout=3D50=20
Would become:
parameters: # Namespace is sqliimport (formerly sqliimport.ini), scope is defined t= o ezdemo_site siteaccess sqliimport.ezdemo_site.ImportSettings.RobotUserID: 14 sqliimport.ezdemo_site.ImportSettings.StreamTimeout: 50=20
Usage in a controller:
// Assuming that current siteaccess is ezdemo_site // The following code will work regardless using the legacy extension or th= e migrated one. $resolver =3D $this->getConfigResolver(); $robotUserId =3D $resolver->getParameter( 'ImportSettings.RobotUserID', = 'sqliimport' ); $streamTimeout =3D $resolver->getParameter( 'ImportSettings.StreamTimeou= t', 'sqliimport' );=20