1

Preface: in ez4 i remember there was a tpl function to read ini settings, we used to use this to pass specific locations or id's with which we could then render certain content.

In ezplatform I am now doing the same thing but by using the PreContentViewListener (in the PreContentViewListener read a yml file and pass into the view as params), but this doesn't feel like the correct way as the PreContentViewListener doesn't always get triggered, in custom controllers for example.

Question Is there a native way to read yaml files from within twig templates? After searching the docs and available packagists i cannot find anything :/

3 Answers3

2

If your needs are simple (i.e. reading container parameters), you can also use eZ Publish config resolver component which is available in any Twig template with ezpublish.configResolver.

You can specify a siteaccess aware parameter in format <namespace>.<scope>.<param_name>, like this:

parameters:
    app.default.param.name: 'Default param value'
    app.eng.param.name: 'English param value'
    app.cro.param.name: 'Croatian param value'

where default, eng and cro are different eZ Publish scopes.

You can then use the config resolver to fetch the parameter in current scope with:

{{ ezpublish.configResolver.parameter('param.name', 'app') }}

If you have Legacy Bridge installed, this even falls back to legacy INI settings if no Symfony container parameter exists:

{{ ezpublish.configResolver.parameter('SiteSettings.SiteName', 'site') }}

Disclaimer: Some say that using config resolver is bad practice, but for simpler usecases it is okay, IMO.

Edi Modrić
  • 2,240
  • 1
  • 15
  • 18
  • That is probably the best answer to the question! – Plopix Jul 28 '17 at 14:24
  • Thank you, this is precisely what i was looking for. I could not find it in the documentation. –  Jul 28 '17 at 16:06
  • Yeah, it's not documented that good, apart from a single line that says it's available on the page documenting the global `ezpublish` variable: https://doc.ez.no/display/EZP/Twig+Helper – Edi Modrić Jul 28 '17 at 17:52
1

Have a look to our CjwPublishToolsBundle. https://github.com/cjw-network/CjwPublishToolsBundle https://github.com/cjw-network/CjwPublishToolsBundle/blob/master/Services/TwigConfigFunctionsService.php

Here we have 2 wrapper twig functions

{{cjw_config_resolver_get_parameter ( 'yamlvariablename', 'namespace default ezsettings') }}

=> ezpublish siteaccessmatching

{{cjw_config_get_parameter( 'mailer_transport' )}}

=> core symfony yaml reader without siteaccess

Felix Woldt
  • 21
  • 1
0

You could do a lot of things in eZ 4 and not always really good for your application design. ezini was able to read the configuration from the template but now in eZ Platform and by extension Symfony you need to respect more common patterns. IMO the view should not be that smart.

Then injecting variables to the view from a listener (PreContentViewListener or your own) is not a bad idea.

You can also use the Twig Globals that could allow you to do 2 global things:

  • inject variables (1)
  • inject a service (2)

Look here: https://symfony.com/doc/current/templating/global_variables.html

(2): please don't inject the service container globally it is bad

(1): I don't remember if the Twig Globals are Site Access aware, if not injecting your own service (2) to manage access to the config might be better.

And finally, I think that the use case is not a common one:

we used to use this to pass specific locations or id's with which we could then render certain content.

Most of the time it is a bad idea to pass ids coming from the configuration to render something, it is much better to organize the content structure to let you pull the location you want using the PHP API. (no id in configuration no hassle with dev, stage, preprod and prod architecture)

Plopix
  • 185
  • 1
  • 10
  • Regarding the maintainability I would not suggest injecting a service into a template but use the listener to add the result to the global twig variables. – Catmzero Jul 28 '17 at 09:26
  • Although i agree in principle it is also a compromise on available resource and project budget. If you have a developer who is mainly front-end, then designing the content tree and content types via the admin with the client works great and the same person can then build the tpl overrides and tpls with very little input from a backend dev. I do see your point however, and the headache of changing id's between dev stag and prod is real. –  Jul 28 '17 at 10:58