New feature: Indicate which pages a Journal article is displayed on

[Christine Sætre，修改在7 年前。]

Portlet:
Web Content Portlet / Journal article artifact > Edit mode

Issue:
Since journal articles can be reused in multiple pages and multiples sites, editors can unwittingly alter the content of a journal article without realizing the impact of this change. New editors find it nearly impossible to determine whether they are editing an article common to more than one site or page.

Suggestion:
Sites with multiple editors, would greatly benefit from both:

• a visual indication in edit mode, that the article is used in more than one page or site (see screeshot suggestion);
• the option of viewing a list of the pages and/or sites that any journal article is used in, from the edit mode.

Facts about our organization and our use of Liferay:

• 55,000 users
• 500 editors
• 2 separate Liferay installations with 653 sites/page-groups (university departments, groups, degree programs, centers)

[David H Nebinger，修改在7 年前。]

This is actually quite hard to do.

You're looking at OOTB usage of a journal article only, but Liferay allows you to embed journal articles in the theme, embed in your own portlets, etc. After all, all you need to display an article somewhere in Liferay is the article id.

Terms of use is another example, it is in fact just another journal article. You can change the article and it reflects in the terms of use panel used during account login.

And because all you need is the article id in order to display, you can't really trace where that article id is actually used.

[Orin Fink，修改在6 年前。]

I can understand with this request as it is a very common situation to deal with for web editors. And, I agree covering all of the edge cases could be impossible, but is there _something_ that could be done?

Perhaps there would be other ways to help editors understand the situation. One of the areas we have used in the past is to review the Version History for a content item and see that another user either created or edited the document and thereby knowing (we) are not the only ones involved in the article. Perhaps adding more context to the editing event that could be shared in history such as the layout or group where the edit happened would be helpful. Also, any hints on direct usage in web content portlets or manual asset publishers might cover a great number of the common cases too.

Thoughts?

[Christoph Rabel，修改在6 年前。]

Not sure if it is doable, but you could create a service that reads all portlet preferences of web content display and asset publisher type. That should let you find out, which articleIds are references. You should also be able to find out on which page the portlet preferences were created.

With that you should be able to create a usage map for your articles.

Of course, you can't find all references to the article, but I think most of the issues mentioned by David Nebinger can be mitigated by guidelines and conventions.

We have embedded web content in portlets and the theme. But all those contents are placed inside folders with the portlet name or e.g. placed in Theme/Footer. So, these are special and the approach above doesn't work. But it should work for most other content.

[Jorge Ferrer，修改在6 年前。]

Hey Christine, Orin, Christoph,

Thanks a lot for your feedback! We are actually working right now on defining a large set of improvements for Liferay 7.1 and 7.2 and this conversation is very relevant to what we are talking about. We are doing a deep analysis so that we are not limited by the current way of publishing content in Liferay to come up with better ways of doing it (later we'll have to see what's really doable, of course).

For example, we've noticed that often a content is created just to be published as a fragment in one page. In this cases, we've found out that in reality the author sees the whole page as one content not a lot of individual ones. So we want to facilitate this.

Of course the current way of publishing still makes sense for certain types of web content.

One other current limitation we want to solve is the little control there is on how an specific web content (or any other asset type) is displayed, whether it has other specific portlets alongside, etc.

It would be very useful for me if each of you could provide me more information about the types of websites you are building, the type of web content structures and how they are used, etc. That way we can take your cases into consideration while defining the new features

Feel free to post the answer here or email me (my email is my name dot lastname followed by @liferay.com).

[Jani Oksanen，修改在5 年前。]

Hello!

I have samekind of problem with 7.0. OOTB Liferay search portlet shows all web content in result pages even, if that specific content is not displayd on any pages(other wise it is only shown in Content/web-content page). Is there any way to alter search results not to count web-content page without rewriting search portlet code?


Edit:
I tried to find out that is this specific journal article shown in any pages. On this forum I found an old post where someone said that it can be found with:


journalArticle.getLayoutUuid() -> this returns empty string


Thanks in advance!

-Jani

[Andrew Jardine，修改在5 年前。]

I was at the DEVCON (in Amsterdam) a couple of weeks back and I swear this was covered as part of the 7.1 release. Jsut so quick searches though I haven't actually turned up anyone talking about this, so maybe it is ont he road map for 7.2. I'm going to be deep in 7.1 this afternoon and tomorrow, I'll have a closer look and let you know if I see something like this. 

[Jorge Díaz，修改在5 年前。]

Andrew Jardine:

I was at the DEVCON (in Amsterdam) a couple of weeks back and I swear this was covered as part of the 7.1 release. Jsut so quick searches though I haven't actually turned up anyone talking about this, so maybe it is ont he road map for 7.2. I'm going to be deep in 7.1 this afternoon and tomorrow, I'll have a closer look and let you know if I see something like this. 

Hi Andrew,

It is not implemented in 7.1 version yet.

It was announced that is included in the roadmap for future versions.

Regards,

Jorge Díaz

[Andrew Jardine，修改在5 年前。]

Damn. I mean I haven't really ever had a use for it personally, but I have come across a few clients in the past, like those here, who have asked about it. Well, at least there's something to look forward to in 7.2! :)

[Jorge Ferrer，修改在5 年前。]

Yeah, this is planned for 7.2.

 

In fact, Juan Antón, the Web Experience team designer just finished a few mockups related to the changes to content authoring which include being able to check where the content is being used and preview it before publication. You can check them in LPS-87314.

Looking forward for your feedback.

[Christoph Rabel，修改在5 年前。]

Great feature and very much anticipated!

 

But I'd like to add another feature request on top. :-) I think it is quite related to the draft/preview feature.

Liferay already has a little known(?) and IMHO very confusing feature with the publish date of an article. Add a new article version with a later publish date and it will only become visible at that later date. Till then, an older version is shown. My customers found this feature very confusing, because you have no clear timeline when which version is shown and sometimes when multiple people edit articles, weird things happen ...

(Btw.: In my opionion the date handling of Liferay articles is very unclean, technical dates and logical dates are mixed and there is no straight logic to them. But that's another story)

These "yet unpublished versions" should be also previewable. I'd like to see in the "backend" which articles have draft and unpublished versions. Editors should be instantly aware that there are yet unpublished versions and those versions should be previewable.

[Jorge Ferrer，修改在5 年前。]

Yup. That makes a lot of sense Christoph. I'll add it to the roadmap and will try to have it done by 7.2.

 

Could you create a Feature Request to keep track of it?

[Christoph Rabel，修改在5 年前。]

I have added one:

https://issues.liferay.com/browse/LPS-87823