Introduction #

A very common need of websites is to show a list of content abstracts (or even just titles) and link them to a different page (or sometimes a different portlet in the same page).

Within Liferay the two most common strategies to publish the list of content are:

1. Asset Publisher: this is the simplest solution and it's quite powerful (especially since version 6)
2. Web Content Display to publish a dummy web content that uses an XSL or Velocity template to query the content from a database: This solution requires more work and knowledge of XSL or Velocity but has the benefit of providing full control of the generated HTML and also the URL of the link to go to the full content view.

With the first solution, Asset Publisher, automatically implements support for linking to and showing the full content view, this view is always shown within the same portlet that published the list of abstracts/titles.

The second solution, using a velocity/XSL template and a Web Content display provides more flexibility and allows site administrators to link to a different page or a different portlet if desired. This is possible because the template author will have knowledge of the specific pages that have been created and the portlets within them so she can use this information to create the link.

The problem with this second solution is that it requires a bit of knowledge and many Liferay users don't even know that it exists. Because of this we would like to explore ways to improve Asset Publisher to be able to support linking to a full content view in a different page.

The goal of this page is to propose a solution for this problem.

Requirements #

• It should be possible to link articles shown in an Asset Publisher instance to other instances of the portlet in the same page or in other pages.
• It should be possible to specify different target pages for different web content based on their topic.
• For example, a web content about soccer would be displayed in the page about sports, while a web content in the same list about physics would link to the page about science.
• Each web content should have a single canonical URL, to achieve better SEO.
• It should be relatively easy for a site administrator to edit all the web content that are linked to a given page and link them to a different one.
• It must be possible for a given page to specify which Asset Publisher instance will be responsible for displaying a web content when linked from a different page.

An additional non-functional requirement is that the building of canonical URLs of web content should be very fast, since a single page may contain many of them.

Proposed solution #

Associating web content and pages #

The main idea behind this proposal is to have a closer association between web content and pages (layouts). This would be achieved by allowing the author of a page to select the default display page. This means that whenever that web content is shown in full view it will be shown within that page (unless specify otherwise through some other means).

In order to allow selection of the default display page there will be a new field in the web content form. This field will allow opening an overlay that will show the hierarchy of pages and will let the user select the one desired for target. Only those pages that have at least one Asset Publisher portlet (or one of its variations) will be selected as default display pages.

Whenever a web content is created from a given page (for example by using the "Add" menu in Asset publisher, as opposed to creating it from the control panel), that page will be automatically preselected as the default display page.

Canonical URLs per web content #

Each web content will have a unique associated URL of the form:

/group/friendly/url/_/friendly-url-of-the-web-content

For example a web content titled "Rafa Nadal wins yet another Grand Slam" in the public pages of the Sports community will have the following unique URL:

/web/sports/_/rafa-nadal-wins-yet-another-grand-slam

Or if Virtual Hosts are being used:

/_/rafa-nadal-wins-yet-another-grand-slam

The benefit of not including the page in the URL is that even if the associated page for the article changes, the URL of the web content will remain the same. This has benefits for SEO, bookmarkability and linkability.

Whenever the full view of the web content is shown in any other page of the portal, it will automatically add <meta> tags in the page to let search engines know about the canonical URL of the content.

Note that an underscore has been used so that the portal can identify that this is a canonical web content URL and give it the special behavior needed. Instead of an underscore a different URL prefix can be used. That prefix though, must be unusual enough to not be used as the name of any page and as the prefix for any portlet friendly URL.

Default web content publisher #

When a web content canonical URL is accessed, the portal will retrieve the web content from the database and determine what's the default display page for the content and will display it showing the web content in the asset publisher portlet that is configured to be the default web content publisher.

There will be an option to add to a page an asset publisher that is preconfigured to be the default web content publisher. Also the page administrator will be able to change which asset publisher portlet is the default web content publisher at any time through the configuration screen. If the instance currently selected is removed, the portal will automatically select other asset publisher instance as the target.

Building of links in lists of web content #

Whenever the Asset Publisher portlet is set up to show full web content in context (currently shown in the UI as the value "View in specific portlet" for the option "Asset Link Behavior"), the link to the full view of each web content will be its canonical URL.

If the web content does not have any default display page, it will be shown in the default web content publisher of the current page.

Note: since the "Asset Link Behavior" is very important for the usability of the feature being discussed, the following changes should also be made to it:

1. Rename the field to "Show full content in..."
2. The available options should be renamed as "This page" and "Specific page" (or "Associated page").

Batch changes of default display pages #

The web content administration portlet should be expanded to allow selecting several web content in order to associate a default display page to all of them.

Also, from each page, it should be possible for the page administrator to retrieve a list of all web content that point to that page and edit all of them in one step to set a different default display page. This operation will be executed automatically also whenever the page is deleted.

Improvement of navigation and sitemap portlets #

The navigation and sitemap portlets can also be improved by leveraging this feature.

Both portlets will be able to show each web content associated to a page as if it was a subpage. This behavior will be configurable since this might not be desired for sites with many web content.

Remaining challenges #

Sharing of content #

What would happen when an asset publisher shows content from the global scope? How do you define a default display page for web content in the global scope if there aren't any pages in that scope?

One of the features under consideration in the Liferay Roadmap is to expand the Content Sharing capabilities to allow a given site to publish content from other sites. How would this affect the solution described in this page?

One simple solution is that the canonical URL would be used which means that the full view of the content would be shown in the source site. This seems to be perfect, but what if the user doesn't have permission to access those pages? or what if the source site doesn't have any pages at all?

Staging and exporting/importing #

How does this affect staging as well as exporting/importing operations?

The main issue is how to store the association with the default display page. One solution could be to store the UUID of the page. Whenever the import process is done, if the target UUID page does not exist it may be a good idea to remove the reference. But this should be evaluated carefully just in case it's possible to apply other solution.

Default display pages without an asset publisher #

A site administrator could potentially remove all asset publisher instances from a page that has been selected as the default display page of one or more web content. What would happen in this case when the canonical URL of the web content is used?

In this case, the portal will dynamically add to the page an asset publisher portlet instance (only for the current request) and show it maximized (using the add-default-resource technique).

References #

• This topic has been discussed in Liferay's forum in http://www.liferay.com/community/forums/-/message_boards/message/6924933 where several community members shared their ideas and suggestions and helped reach the solution described in this page. Special kudos to Szymon, Mauro, Ahmed and Ray for their collaboration to define the solution described in this page.
• This feature is currently being implemented. You can follow the progress here: http://issues.liferay.com/browse/LPS-15035