Global navigation

   Documentation Center
   eZ Studio & eZ Platform
     User Manual
     Technical Manual
     Glossary
   eZ Publish 4.x / legacy

 
eZ Publish (5.x)

eZ Publish 5.x | For eZ Platform & eZ Studio topics see Technical manual and User manual, for eZ Publish 4.x and Legacy topics see eZ Publish legacy

Skip to end of metadata
Go to start of metadata

The configured ViewProvider allows to configure template selection when using the ViewController, either directly from a URL or via a sub-request.

eZ Publish 4.x terminology

In eZ Publish 4.x, it was known as template override system by configuration (override.ini).
However this only reflects old overrides for node/view/*.tpl and content/view/*.tpl.

Principle

The configured ViewProvider takes its configuration from your siteaccess in the location_view/content_view section (most of the time you want to match a location, so we'll focus on location_view configuration). This configuration is a hash built in the following way:

Important note about template matching

Template matching will NOT work if your content contains a field type that is not supported by the repository. It can be the case when you are in the process of a migration from eZ Publish 4.x, where custom datatypes have been developed.
In this case the repository will throw an exception which is caught in the ViewController, causing the fallback to the legacy kernel.

The list of field types supported out of the box is available here.

Tip

You can define your template selection rules in a different configuration file. Read the cookbook recipe to learn more about it.

You can also use your own custom controller to render a content/location.

 

Matchers

To be able to select the right templates against conditions, the view provider uses matcher objects, all implementing eZ\Publish\Core\MVC\Symfony\View\ContentViewProvider\Configured\Matcher interface.

Matcher identifier

The matcher identifier can comply to 3 different formats:

  1. Relative qualified class name (e.g. Identifier\ContentType). This is the most common case and used for native matchers. It will then be relative to eZ\Publish\Core\MVC\Symfony\View\ContentViewProvider\Configured\Matcher.
  2. Full qualified class name (e.g. \Foo\Bar\MyMatcher). This is a way to specify a custom matcher that doesn't need specific dependency injection. Please note that it must start with a \.
  3. Service identifier, as defined in Symfony service container. This is the way to specify a more complex custom matcher that has dependencies.

Injecting the Repository

If your matcher needs the repository, simply make it implement eZ\Publish\Core\MVC\RepositoryAwareInterface or simply extend eZ\Publish\Core\MVC\RepositoryAware abstract class. The repository will then be correctly injected before matching.

Matcher value

The value associated to the matcher is being passed to its setMatchingConfig() method and can be anything supported by the matcher.

In the case of native matchers, they support both scalar values or arrays of scalar values.
Passing an array amounts to applying a logical OR.

Combining matchers

It is possible to combine matchers to add additional constraints for matching a template:

The example above results to say "Match any content which ContentType identifier is small_folder OR folder, AND having frontpage as ParentContentType identifier".

Available matchers

The following table presents all native matchers.

IdentifierDescription
Id\ContentMatches the ID number of the content
Id\ContentTypeMatches the ID number of the content type whose content is an instance of
Id\ContentTypeGroupMatches the ID number of the group of the content type whose content is an instance of belongs to
Id\LocationMatches the ID number of a location.
In the case of a Content, matched against the main location.
Id\ParentContentTypeMatches the ID number of the parent content type.
In the case of a Content, matched against the main location.
Id\ParentLocation

Matches the ID number of the parent location.
In the case of a Content, matched against the main location.

Id\RemoteMatches the remoteId of either content or location, depending on the object matched.
Id\SectionMatches the ID number of the section whose content belongs to
Id\StateNot supported yet.
Identifier\ContentTypeMatches the identifier of the content type whose content is an instance of
Identifier\ParentContentType

Matches the identifier of the parent content type.
In the case of a Content, matched against the main location. 

Identifier\SectionMatches the identifier of the section whose content belongs to
Identifier\StateNot supported yet.
DepthMatches the depth of the location. The depth of a top level location is 1.
UrlAlias

Matches the virtual URL of the location (i.e. /My/Content-Uri).

Important: Matches when the UrlAlias of the location starts with the value passed.
Not supported for Content (aka content_view). 

 

 

6 Comments

  1. Hi guys, great piece of doc!

    Pierre seems to have stumbled upon a non-working 'content_view' View Provider. All details here:

    http://share.ez.no/forums/setup-design/override-a-content-template#comment79595

    Cheers,

  2. content_view seems to work now! I couldn't see a concrete example in the DemoBundle. Here is a rough outline of what I have:

    block/my_author.html.twig Looks like this:

    And the code to render in the main template is like this:

    The my_author attribute is of type ezobjectrelation

    Hope that's clear. Apologies if I've missed anything.

  3. For all hackerz out there: if you want to implement a custom matcher, nothing is easier:

    a) register it as a service (no tags needed)

    b) make sure it implements the good interface (you probably are better of subclassing some of the existing ones)

  4. Thanks Frank, I updated the link.

  5. Could this doc be updated with the loading order of the view provider configuration? Specifically how an app or a bundle can override configuration of another bundle.