This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » eZ Publish 5 Platform » New stack equivalents for full URLs

New stack equivalents for full URLs

New stack equivalents for full URLs

Thursday 02 July 2015 7:00:10 pm - 6 replies

In the legacy stack, you would pass a URL string to ezurl( 'no', 'full' ) or ezroot( 'no', 'full' ) to generate a full (or sometimes called "absolute" ) URL like this: or

In the new stack, there is already an "absolute" option when generating a URL for a location or a content object (see This should work for Symfony route and legacy module views since they go through the same "path" function.

But there are other use cases where we need the option to generate an absolute/full URL on a per-link basis:

  • Generate a URL for an image alias: this is currently configurable only to be absolute/full or relative for ALL image aliases (see This should be togglable; for example to generate an Open Graph image tag, you need it to be absolute but for other images on the site they can usually be relative.
  • Generate a URL to an arbitrary path that is on the same domain but outside Symfony or eZ Publish. Sometimes the CMS is sitting on the same domain as many other applications and you should be able to generate a full URL to '/some/other/application'.
  • Generate a URL from a search result path (where you don't have a location). This could conceivably be solved with the same solution as the point above. (This came up when making a legacy callback to eZ Find.)

It is clear that in the new stack, eZ Publish is very strict about producing URLs only for, in a sense, pre-approved situations.  That's why you pass the location object to the "path" function instead of the URL alias directly.  However, I believe that there should be a generic function built in to the eZ Publish new stack that will format an arbitrary string for the current domain, just like ezurl() or ezroot() did.  On every project we are finding that we are building something like the last example in this post:

What are other people's thoughts on this?

Modified on Thursday 02 July 2015 7:00:36 pm by Peter Keung

Thursday 02 July 2015 8:23:51 pm

My first thought is that there is a nice business opportunity for some third party to build and license an API layer. And then, naturally, a concern that this has every likelihood of creating additional headaches and be distinctly inefficient.

It is easy to imagine that the effort to build eZ 5 is big, but it is concerning how much functionality (from eZ 4) is being left behind. It would be interesting to know if there is a rule of thumb that distinguishes functionality that is not getting migrated forward. That would help us quickly determine that we should not expect to find something in the new stack; it would help eZ determine that a feature should be migrated forward; and it would provide a good guideline for building a shareable API layer.

It is also concerning how eZ 4's ease of development is being traded-off against aesthetic principles. I love beautiful architectures and code, but at the end of the day, the feature that actually wins is efficient delivery of solutions.

Friday 03 July 2015 9:03:53 am

@Doug Plant  "It is also concerning how eZ 4's ease of development is being traded-off against aesthetic principles. I love beautiful architectures and code, but at the end of the day, the feature that actually wins is efficient delivery of solutions."

Maybe our CJWPublishToolsBundle is something for you

This Bundle provides basic templating tools for building Websites with eZ Publish 5 similar to eZ Publish 4.

With this bundle you can use the default ezviewcontroller and use the overridsystem and with our cjw_content_fetch you can do location searches from twig templates (similar to the old content list/tree fetch functions) but you can also use this fetch from your controller. So you do not need to know all the specific api parameters in php.

So it is very simple to make fullviews with children lists and pagenavigators without coding one line of php code.

We also have a formbuilder which automatically creates a infocollector form from contentTypDefinition or a form for editing/creating of content over the the ezp5 api.

A userregister functionality we also have in development.

Shortly with this bundle we can do nearly 90% of daily work with ezpublish templating .... 

- full views / childrenviews / sorting / field filtering

- user register (without php programming)

- kontactform (without php programming)

Our goal is to have a way to build effectively ezp5 webseites - and we found that the old ez4 way with templateing logic was a practical way. So we create the CjwPublishToolsBundle

that we can do the same in ez5 happy.gif Emoticon.

... we will publish a new version of CjwPublishToolsBundle in the nexts weeks, with a lot of improvements and some more documentation ...

Feel free to test the extension and we will happy if we get some feedback.

Modified on Friday 03 July 2015 9:06:10 am by Felix Woldt

Friday 03 July 2015 11:39:47 am

Hi there. Rich discussion !

One thing I believe i must urgently point out: This pull-request is a work-in-progress on the "missing fetch", if I may put it this way.

About content/download, support has been added a couple weeks ago, and it'll be part of 2015.05, to be released very very soon.

I'll process the rest of the discussion later, but feedback on this would be really appreciated.

Modified on Monday 06 July 2015 5:24:37 pm by Bertrand Dunogier

Monday 06 July 2015 9:20:44 am

@Bertrand  The pullrequestlink not working => remove the . at the end!

Your approach is interesting, too. We will see how practical it will be to define the fetch parameters in yml file. ...

... content/download was missing a long time ... so we made our quick implementation blunk.gif Emoticon


We just put our latest cjwPublishToolsBundle to GitHub CjwPublishToolsBundle

And here is a Performance-best-practise-tip: We have a new twig function  'cjw_render_location' which can replace the render controller call for the viewController e.g. used for rendering line views in full views.

 {{ render( controller( "ez_content:viewLocation", {'location': child, 'viewType': 'line'} ) ) }}
{{ cjw_render_location( ( {'location': child, 'viewType': 'line'} ) ) }}


Because we have no subrequest we save a lot of execution time!!!! Between 30 and 100ms!!! If you have a listview with 10 children you save 300 - 1000ms!!!! And only for including a simple lineview!!! The twig function also have performanceimprovement for the matching criteria  ContenTypeIdentifier. So the contentypeidentifier for the location only will fetch onces from stash. This saves a lot of stash calls and if you have a lot of matching rules you will same some ms.



Modified on Monday 06 July 2015 9:22:19 am by Felix Woldt

Monday 06 July 2015 5:40:19 pm


@Bertrand  The pullrequestlink not working => remove the . at the end!

Fixed, thank you !

We will see how practical it will be to define the fetch parameters in yml file. ...

You don't have to define parameters in yml files, unless you're referring to template match parameters ? Queries are defined as PHP classes, and are used from templates, via the query controller actions.

The twig helpers do make sense here. I gotta say I'm not a big fan of the implementation (does too much things of its own, but it's a technical detail). We were actually discussing twig functions in the named queries PR.

If the same twig function (ez_render_location, ez_render_content) can handle both inline rendering (what you do) and controller rendering (like we do) based on "something" (parameters, configuration (e.g. always render the viewType line as inline), it would really increase usability.

I'll ping Jérôme happy.gif Emoticon

Modified on Monday 06 July 2015 5:47:12 pm by Bertrand Dunogier

Monday 06 July 2015 7:23:14 pm

What are people's thoughts on the need to support general full URL formatting?

(Maybe we can fork the equally interesting fetch function discussion into another thread.)


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from