Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Display Page Templates
I fiddled a bit with Liferay 7.3 and Display Page Templates.
The feature is now hidden pretty well. Had I not known that it exists, I would not have found it. I am not sure if that is intentional or how this could be improved, but since it is a nice and useful feature, it would be nice to make it more visible. Maybe the UI is fine, but a training video in Liferay University or somewhere could show how to use that stuff.
Adding a structure, adding a template, setting a display page works pretty well.
Now the things that could be improved:
1) When a field is mapped, you don't see it. I mean, you still see the default fragment text there and you have to click on each editable to check the mapping. It would be far better if the field could show that it was mapped to a content. Ideally it would show something like a mapping symbol + the field/template name. I found this one really annoying.
2) Default Template: The last template created for a structure is always the default template. That's kinda bad. That behavior is there like forever, it is nothing new and it was ok-ish before. But now, since templates can be mapped to fields, it makes a lot of sense to create multiple templates for a structure. So, a "This is the default template" menu option would be nice.
3) Generic templates: It would be very nice if I could create "field templates". e.g. for date or document. Otherwise I would have to create a "RenderDate" template for each structure. RenderDateNews, RenderDateEvents, RenderDateDocumentList, ... While I can do that, it is a bit meh.
4) Grouping/Filtering of templates: On the Webcontent/Templates page: It would be nice if I could see which template belongs to which structure. Or to filter on structure. As long as there is just one template per structure, it isn't a big deal, but it would be nice.
5) Untitled Webcontent: About each and every webcontent I have created was untitled. I always forget to set the title. Really always. Maybe this could be a mandatory field again? It isn't a big deal, but it really happened to me all the time.
6) In the structure editor: Please, please allow me to set at least a style class for the field and ideally also for the whole edit box. This would enable me to do something to the fields. The webcontent editor has improved, but it is still very inconvenient if you have a lot of fields and repeatable/nested fields. There is a lot I could do, if I could control the editor there. True, some things could be done by you too, e.g. for repeatable fields, allow to "collapse/expand" the list. Or if you could add an "expand/collapse" panel that would only show in the editor (purely cosmetic)
7) Search and Assetpublisher: While this isn't related to content pages, it is still weird for my customers. If they want an article to be not found in search, they are stumped by the fact that they can't use it in Asset publisher anymore. I am not sure what the best behavior here is, maybe other customers already rely on this behavior.
The feature is now hidden pretty well. Had I not known that it exists, I would not have found it. I am not sure if that is intentional or how this could be improved, but since it is a nice and useful feature, it would be nice to make it more visible. Maybe the UI is fine, but a training video in Liferay University or somewhere could show how to use that stuff.
Adding a structure, adding a template, setting a display page works pretty well.
Now the things that could be improved:
1) When a field is mapped, you don't see it. I mean, you still see the default fragment text there and you have to click on each editable to check the mapping. It would be far better if the field could show that it was mapped to a content. Ideally it would show something like a mapping symbol + the field/template name. I found this one really annoying.
2) Default Template: The last template created for a structure is always the default template. That's kinda bad. That behavior is there like forever, it is nothing new and it was ok-ish before. But now, since templates can be mapped to fields, it makes a lot of sense to create multiple templates for a structure. So, a "This is the default template" menu option would be nice.
3) Generic templates: It would be very nice if I could create "field templates". e.g. for date or document. Otherwise I would have to create a "RenderDate" template for each structure. RenderDateNews, RenderDateEvents, RenderDateDocumentList, ... While I can do that, it is a bit meh.
4) Grouping/Filtering of templates: On the Webcontent/Templates page: It would be nice if I could see which template belongs to which structure. Or to filter on structure. As long as there is just one template per structure, it isn't a big deal, but it would be nice.
5) Untitled Webcontent: About each and every webcontent I have created was untitled. I always forget to set the title. Really always. Maybe this could be a mandatory field again? It isn't a big deal, but it really happened to me all the time.
6) In the structure editor: Please, please allow me to set at least a style class for the field and ideally also for the whole edit box. This would enable me to do something to the fields. The webcontent editor has improved, but it is still very inconvenient if you have a lot of fields and repeatable/nested fields. There is a lot I could do, if I could control the editor there. True, some things could be done by you too, e.g. for repeatable fields, allow to "collapse/expand" the list. Or if you could add an "expand/collapse" panel that would only show in the editor (purely cosmetic)
7) Search and Assetpublisher: While this isn't related to content pages, it is still weird for my customers. If they want an article to be not found in search, they are stumped by the fact that they can't use it in Asset publisher anymore. I am not sure what the best behavior here is, maybe other customers already rely on this behavior.
Thanks for the feedback Christoph.
On a first read most, if not all, makes a lot of sense. I've asked my colleague Tarik to take a deeper look at each suggestion and answer you with more detail.
On a first read most, if not all, makes a lot of sense. I've asked my colleague Tarik to take a deeper look at each suggestion and answer you with more detail.
Hi Christoph
First, I would like to thank you for this complete feedback. We appreciate that you took the time to comment to give us your impression and constructive suggestions to improve our products.
Here some element of answer for your bullet points.
1: (Tested in 7.3 GA2) When a field is mapped to a content the container becomes pink. That shows that the field is mapped. If it is not mapped then the container appears in its original blue color. For display page template it works the same way. However with your feedback we realize we could/should make it even more visible. Thanks for bringing this up !
2: This is part of a general discussion we are currently having. Would you have a particular context in which you would like to use multiple templates for the same content, that we could use as a use case? Please note that in the case of Display Page Templates you can select “mark as default”, in the case of “freemarker” templates you can also do that by using “edit default values”. We could improve that setting set up indeed.
3: There are certain types of fields such as dates that can have multiple ways to be displayed. Right now you can create a template associated with each structure for each way of displaying it, but it must be repeated for each structure indeed. That might require data maintaining duplicated items, correct?.
4: If you switch view from card to table you can find out which structure the template is using. But it makes sense to be able to group the structure or filter them by type. Thanks for the feedback.
5: We did that in the direction of implementing auto-save function (which has not yet been done). This is why google docs & co work like this. Based on the several customers and community feedback we changed our opinion, we will reassess the situation if we decide to implement auto-save.
6: Thanks for the improvement suggestions we will work to improve that.
7: This was not the case before indeed, and we will fix that side effect.
First, I would like to thank you for this complete feedback. We appreciate that you took the time to comment to give us your impression and constructive suggestions to improve our products.
Here some element of answer for your bullet points.
1: (Tested in 7.3 GA2) When a field is mapped to a content the container becomes pink. That shows that the field is mapped. If it is not mapped then the container appears in its original blue color. For display page template it works the same way. However with your feedback we realize we could/should make it even more visible. Thanks for bringing this up !
2: This is part of a general discussion we are currently having. Would you have a particular context in which you would like to use multiple templates for the same content, that we could use as a use case? Please note that in the case of Display Page Templates you can select “mark as default”, in the case of “freemarker” templates you can also do that by using “edit default values”. We could improve that setting set up indeed.
3: There are certain types of fields such as dates that can have multiple ways to be displayed. Right now you can create a template associated with each structure for each way of displaying it, but it must be repeated for each structure indeed. That might require data maintaining duplicated items, correct?.
4: If you switch view from card to table you can find out which structure the template is using. But it makes sense to be able to group the structure or filter them by type. Thanks for the feedback.
5: We did that in the direction of implementing auto-save function (which has not yet been done). This is why google docs & co work like this. Based on the several customers and community feedback we changed our opinion, we will reassess the situation if we decide to implement auto-save.
6: Thanks for the improvement suggestions we will work to improve that.
7: This was not the case before indeed, and we will fix that side effect.
I have to add a little preamble before answering:
Most of my usecases are based on 7.0, just to give an example from one of our customers, here's a list of just the journal article templates:
AccountManager, FunctionalBlocks, PromotionBox, ErrorContent, Iframe, SensorCard, SearchBox, JobDetails, SimpleCardContent, ApplicationDiagram, KeyFacts, Slider, Awards, MiddleSmallCard, StandardArticle, Banner, MyCart, SubmitResume, BigCardContent, News, Support, CenteredContent, NewsletterInfo, TextAnchor, DocumentList, PricelistInfo-Banner, TwoColumnContent, Event, ProductCard, Form, ProductTable
I expect that several, maybe even most of them, can be replaced by fragments. So, maybe templates will become more rare in the future and several of my concerns won't be such a big deal.
About 2:
We use that feature in general for news and events.
Let me start with 7.0:
News are usually displayed on various pages as: List items, Cards and Full Content. Instead of parsing the xml in asset publisher, we iterate through the entries and display each entry with the "ListItem", "CardItem" or when you click on the content in the Full Content template. So, for us, it is quite normal to have multiple templates for each item. We have written our own "convenience" displayhelper to print the content with the correct template.
It was not a big deal for us in 7.0, since for the rare cases we needed to add another template later on, we just used the api to set the default template again.
But we struggle for 7.0 with some usecases. One of our customers has "normal" events and "important" events. Normal events are just displayed using the standard display page. Special events are tricky, because each custom event page is a landing page with "something" else. One of them e.g. has a 3D View of the booth, another one contains a bunch of videos, ...
But in 7.3 I can suddenly leverage the display pages and things change. Of course, I can still render the whole Event in one template, all fields at once, but that would kinda defeat the whole purpose of the display pages. Then I could simply continue to use an Asset Publisher.
So, to gain some flexibility, like being able to move something left/right/top/botton, I need to create multiple templates to render my fields. So, to display the start & enddate for an event, I need to create an "EventStartDate" and an EventEndDate template? That's actually weird. Speakerlist? Another template. OptionalSideImage? Another template. And so on.
So, to have maximal flexibility I would have to create one template per field. And the last one would always be the default template.
About 3
As I just wrote, I would need one template per field, which is just nuts.
A date practically always should have the same format (granted, it might have to take locale into account), but a user should always see the same date format on a page. So it would be convenient to have just one template for date and use it for all structures. Date is the most prominent example, but we have various fields that need some preprocessing.
Images URLs should not be normal urls but optimized. So, a Small/Middle/Large/FullImage template creating a link to a 300/600/900px/fullsize wide image would be convenient.
Videos: In China youtube cannot be used. So, for China use chinaVideoLink, for rest of the world youtubeVideo
...
Most of my usecases are based on 7.0, just to give an example from one of our customers, here's a list of just the journal article templates:
AccountManager, FunctionalBlocks, PromotionBox, ErrorContent, Iframe, SensorCard, SearchBox, JobDetails, SimpleCardContent, ApplicationDiagram, KeyFacts, Slider, Awards, MiddleSmallCard, StandardArticle, Banner, MyCart, SubmitResume, BigCardContent, News, Support, CenteredContent, NewsletterInfo, TextAnchor, DocumentList, PricelistInfo-Banner, TwoColumnContent, Event, ProductCard, Form, ProductTable
I expect that several, maybe even most of them, can be replaced by fragments. So, maybe templates will become more rare in the future and several of my concerns won't be such a big deal.
About 2:
We use that feature in general for news and events.
Let me start with 7.0:
News are usually displayed on various pages as: List items, Cards and Full Content. Instead of parsing the xml in asset publisher, we iterate through the entries and display each entry with the "ListItem", "CardItem" or when you click on the content in the Full Content template. So, for us, it is quite normal to have multiple templates for each item. We have written our own "convenience" displayhelper to print the content with the correct template.
It was not a big deal for us in 7.0, since for the rare cases we needed to add another template later on, we just used the api to set the default template again.
But we struggle for 7.0 with some usecases. One of our customers has "normal" events and "important" events. Normal events are just displayed using the standard display page. Special events are tricky, because each custom event page is a landing page with "something" else. One of them e.g. has a 3D View of the booth, another one contains a bunch of videos, ...
But in 7.3 I can suddenly leverage the display pages and things change. Of course, I can still render the whole Event in one template, all fields at once, but that would kinda defeat the whole purpose of the display pages. Then I could simply continue to use an Asset Publisher.
So, to gain some flexibility, like being able to move something left/right/top/botton, I need to create multiple templates to render my fields. So, to display the start & enddate for an event, I need to create an "EventStartDate" and an EventEndDate template? That's actually weird. Speakerlist? Another template. OptionalSideImage? Another template. And so on.
So, to have maximal flexibility I would have to create one template per field. And the last one would always be the default template.
About 3
As I just wrote, I would need one template per field, which is just nuts.
A date practically always should have the same format (granted, it might have to take locale into account), but a user should always see the same date format on a page. So it would be convenient to have just one template for date and use it for all structures. Date is the most prominent example, but we have various fields that need some preprocessing.
Images URLs should not be normal urls but optimized. So, a Small/Middle/Large/FullImage template creating a link to a 300/600/900px/fullsize wide image would be convenient.
Videos: In China youtube cannot be used. So, for China use chinaVideoLink, for rest of the world youtubeVideo
...
Hey Christoph,
Regarding #3, this is something that we've been thinking about for a while. In fact you and I may have talked about it before, but now it's more obvious.As you say, for certain field types more than one formatting option will be necessary. And that will be common across structures. Furthermore, I believe that they would be common across the whole system. Because of that, the solution that I had in mind would be to not implement this as a template that would need to be created through the UI, but rather as a Java interface called something like FieldTypeFormatter. We would provide out of the box several formatters for date and other field types where we identify the need. And it would be possible for any other developer to provide additional ones.
What do you think of this solution?
Regarding #3, based on your description of the last post. Would this solution also solve your need or would you need something else?
Regarding #3, this is something that we've been thinking about for a while. In fact you and I may have talked about it before, but now it's more obvious.As you say, for certain field types more than one formatting option will be necessary. And that will be common across structures. Furthermore, I believe that they would be common across the whole system. Because of that, the solution that I had in mind would be to not implement this as a template that would need to be created through the UI, but rather as a Java interface called something like FieldTypeFormatter. We would provide out of the box several formatters for date and other field types where we identify the need. And it would be possible for any other developer to provide additional ones.
What do you think of this solution?
Regarding #3, based on your description of the last post. Would this solution also solve your need or would you need something else?
It would solve quite a bunch of scenarios. While I need my own formatter for date, I usually even need only one per customer. Dates should always be in the same format. I probably need the user (timezone) and locale/language in the interface. In general, more context is always better. Maybe I can get the themedisplay?
In the best case scenario an the editor can chose the formatter from a list when creating the content page template, but for starters, one formatter would be helpful.
I still would need templates for some usecases, though. e.g. for repeatable fields. Or optional fields or fields with logic. Or for optional images, I would need to skip writing the whole image tag. Images are actually a pretty complicated example. What happens if I map an optional image field to an editable image. I didn't try it, but I probably get a broken image link. How can I fix this?
I would need some check around the field and skip the whole image tag. Hmm.
After some thinking, I see two cases:
a) Simple fields, everything can be mapped field -> editable. All fine
b) Repeatable fields, Optional images (what happens in other languages?), complicated behavior, ...
I believe, in that case I need to create multiple render templates "Header section", "Document List", "Image Gallery", "..." to render my complicated content. Maybe the approach here should be to treat those templates as fragments. Instead of mapping fields, those templates "appear" in the sidebar and can be dragged and dropped on the page in the same way as fragments. (Or maybe fragments could be connected to structures, it would have the same effect)
Just thinking.
In the best case scenario an the editor can chose the formatter from a list when creating the content page template, but for starters, one formatter would be helpful.
I still would need templates for some usecases, though. e.g. for repeatable fields. Or optional fields or fields with logic. Or for optional images, I would need to skip writing the whole image tag. Images are actually a pretty complicated example. What happens if I map an optional image field to an editable image. I didn't try it, but I probably get a broken image link. How can I fix this?
I would need some check around the field and skip the whole image tag. Hmm.
After some thinking, I see two cases:
a) Simple fields, everything can be mapped field -> editable. All fine
b) Repeatable fields, Optional images (what happens in other languages?), complicated behavior, ...
I believe, in that case I need to create multiple render templates "Header section", "Document List", "Image Gallery", "..." to render my complicated content. Maybe the approach here should be to treat those templates as fragments. Instead of mapping fields, those templates "appear" in the sidebar and can be dragged and dropped on the page in the same way as fragments. (Or maybe fragments could be connected to structures, it would have the same effect)
Just thinking.
Hi Christoph,
Thanks a lot for the clarifications !
Thanks a lot for the clarifications !
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™