Our contributions to eZ Publish Community Project 2014.11

by Edi Modrić -

eZ Publish Community Project 2014.11 release is just around the corner. v2014.11.0, v2014.11.1, v2014.11.2 and v2014.11.3 tags are already created on GitHub, and distribution release is imminent so now is the perfect time to show you some cool stuff Netgen contributed to the new release. In total, we created seven pull requests which were all merged successfully by the eZ team.

So, let's dive into what we did, in order of creating the pull requests!

Overriding ez_page block view controller

Just as with implementing full view templates for your locations, sometimes it is not enough to use a provided ez_page:viewBlock controller to display your eZ Flow blocks. That's why we proposed a patch that adds the possibility to override the built in controller in block override rules, just like you can override the location view controller.

As of 2014.11 version of eZ Publish Community Project, you can now use the following configuration to override the block controller:

ezpublish:
    system:
        netgen_frontend_group:
            block_view:
                ContentGrid:
                    template: NetgenSiteBundle:block:content_grid.html.twig
                    controller: NetgenSiteBundle:Block:viewContentGridBlock
                    match:
                        Type: ContentGrid

After that, you can implement your own block controller that can enrich the built in block view, for example:

class BlockController extends Controller
{
    public function viewContentGridBlockAction(
        Block $block,
        array $params = array(),
        array $cacheSettings = array()
    )
    {
        return $this->container->get( 'ez_page' )->viewBlock(
            $block,
            $params + array( 'my_variable' => 123 ),
            $cacheSettings
        );
    }
}

The pull request is located here.

No more annoying and incorrect error in logs and profiler

In 2014.07 version of Community Project, there was an error present in error logs that said something like "URL with ID '0' not found." This error was completely incorrect as it was caused by a bug in eZ Publish kernel. What happened was that eZ Publish kernel was trying to load an URL for an empty value of ezurl field type, which should not happen. As this error was annoying and made us constantly look into the profiler toolbar, we decided to get rid of it.

You can see the pull request here.

Checking for existence of legacy templates now works as it should

Consider the following piece of Twig template:

{% include [
       'NetgenSiteBundle:parts:' ~ template ~ '.html.twig',
       'design:parts/' ~ template ~ '.tpl',
       'design:parts/default.tpl'
   ] ignore missing
   with {
       'location': location,
       'node': location
   }
%}

Assuming that the first two templates don't exist, the third template should be rendered. However, eZ Publish showed an empty string instead. What happened was that the legacy template engine did not recognize that the second template was missing and instead returned an empty string to be rendered.

You can see what we did to fix it in this pull request.

Generating an URL to content by its ID with ez_urlalias route

Now, this is a cool one! Sometimes you don't have access to a Location or Content objects in your template, but are left with just the content ID. Typically, you will have this situation when working with Relation and RelationList field types which only have a list of content IDs as their content. In this situation, it was impossible for you to generate a link to your content, as eZ Publish URL alias router accepted only Location objects or location IDs. No more! Now you can generate an URL to your content with a content ID too. You can use the existing ez_urlalias route to do it:

<a href="{{ path( 'ez_urlalias', { 'contentId': 42 } ) }}">My content</a>

As you can see from the discussion in the pull request, this feature will have a followup that will allow you to also use a ContentInfo object directly when generating an URL.

Overriding controllers for content embedded in XmlText field type

Just as with block view, it was not possible to use a custom controller to render the content embedded in XmlText field type. While you can use the custom controller when using the embed view directly in your templates, that did not apply in this case. The best you could do was having two templates for two content views: embed and embed_inner. The first template (matched with the embed view) would then call the subrequest with ez_content:embedContent controller while using the embed_inner view and a second template to actually render what you want.

After the pull request we made, you don't have to do that anymore. The custom controller you specified in your embed content view rules will be used instead of the built in one.

One edge case bug in legacy location search handler is fixed

This bug was discovered and fixed by Ivan Herak, my friend and colleague, while developing a custom sort clause handler. He was trying to join an additional table in the resulting query, and the query was failing with an error that an ambiguous depth column was used in the WHERE part of the query. The problem was that his additional table had a depth column, while at the same time, depth column from ezcontentobject_tree table was not quoted correctly. He created his first pull request ever to fix this bug, so big kudos to Ivan \o/ !

Enhancing the docs on (not) using dynamic settings in semantic configuration

Dynamic settings is a cool new feature present in eZ Publish Community Project 2014.11. However, first time I tried to use the dynamic settings was in my semantic config to set a root location ID for some of my siteaccesses and it didn't work. It turns out that dynamic settings can be used exclusively when defining arguments or properties in service definitions. This was not clear from the docs, so we made a slight improvement to them to clarify that.

Last words

All of these patches were the result of requirements on couple of our real eZ Publish 5 projects and use cases, which would've been tough or nearly impossible to implement if it weren't for these 7 pull requests. We hope that you will find these features and bug fixes useful. And of course, look for more of these in the near future :)

Comments

This site uses cookies. Some of these cookies are essential, while others help us improve your experience by providing insights into how the site is being used.

For more detailed information on the cookies we use, please check our Privacy Policy.

  • Necessary cookies enable core functionality. The website cannot function properly without these cookies, and can only be disabled by changing your browser preferences.