Window into Liferay Publishing Black Box

This article provides a guide to building a “hook” to show the list of “Web contents” when using Liferay publishing.

Introduction

Liferay CMS is a critical part of most of the Portals and Websites built on Liferay platform. In most enterprise scenarios there are multiple content authors who work on adding and editing site content (pages, web content, documents and other assets). For various reasons while publishing it is important for the content publishers to know and verify what content is being published from a content staging environment to the live site.

Current User Interface provided by Liferay does not show what is being published in a particular publishing cycle. It does give a count of various assets (web contents, documents, media, categories etc) but beyond that, content authors have to wait until publishing is complete to see whether their content additions/changes made it or did not make it to the live environment.

In general, there are three key customizations that content managers/publishers ask for in many of our Liferay implementations –

A. A window/view into Liferay publishing process so that Content Managers/Publisher can validate content being published.

B. When assets (documents and media) are being deleted but if they are being used in some other assets like web content, wouldn’t it be nice if we content authors get to know such dependency/relationship upfront so that they can take conscious decision and or resolve dependencies so that the stage and live environment remain in sync.

C. Another problem with current publishing UI is a need for selecting various options before publishing. Content publishers want to make sure they make the right selection and admin user wants to make sure content publishers do not select/select some of the options on the UI. Wouldn’t it be nice to provide default or fewer options to regular content authors and all options only for the admin user?

This article discusses the solution for ask “A” above. At the end of this article at “Enhancing the hook”, I have provided pointers to address ask “B” and ask “C” above.

Lets understand main API calls in Liferay publishing

Before we provide a window or view into Liferay publishing processes, it’s very important to understand high-level technical flow and API calls the publishing process makes

1. Create a Publishing Context with all the request options.
2. Create request and submit to the message bus.
3. Create and export Lar file with publishing request.
4. Import Lar into the target environment.
5. Display Results.

Given the flexible and customizable architecture of Liferay we can create hook/ext plugin at any of the above stages to display a “window” into that step of the publishing. Additionally based on the use case, we can always use “Dynamic” query to request the information about content being published.

Fetching and showing list of “web content” being published using Dynamic Query

This section provides steps and code logic required to create a “JSP Hook” to list and show “web content” being published using a “dynamic query”.

1. Create a JSP hook

Using Liferay IDE or command line create a “JSP Hook”. The Liferay-hook.xml should look like this



2. JSP files to change

Add following files into the /META_INF/custom_jsps folder

a. Publish_layouts.jsp

The Publish_layouts.jsp is the main jsp which renders publishing UI and its various options. On this JSP there is logic to gather list of “Layouts” that user selects for publishing.

b. Publish_layouts_portlets_data.jspf

The “Publish_layouts_portlets_data.jspf” is the main jspf file where information about the publishable portlets is collected. This is the main jsp where we will write our “customization” code

c. publish_layouts_processes.jsp

The “publish_layouts_processes.jsp” lists the status of each publishing process and we can provide the list of “web content” being published on this view as well.

3. Understanding “PortletDataHandler” for portlets, “StagedModelDataHandler” , “ExportableStatuses” Objects

It’s hard to explain the role of each and every object in the publishing process but it’s important to understand some of critical objects that allow us to get reference to “the asset” being published.

When staging is enabled on the control panel, admin user decides which type of portlets are going to be part of staging. See below



For all the selected type of portlets liferay has a “dataHandler“, which provides the handle/reference to each type of “publishable” portlet. Web content portlet is the most common type of portlet that is used as part of any publishing process and this article will explain the purpose and use of its “dataHandler”

The “StagedModelDataHandler” interface provides the handle to staged data of a particular class type. You take a reference of the same using following line.

StagedModelDataHandler stagedModelDataHandler = StagedModelDataHandlerRegistryUtil.getStagedModelDataHandler(JournalArticle.class.getName());

The “StagedModelDataHandler” for “web content” asset gives list of “exportable status” using “stagedModelDataHandler.getExportableStatuses()” call. (full code snippet is provided in the following section)

4. Building a list

We are building a list using a “Dynamic” Query”. This dynamic query is going to get a list of “Journal Article” Models which are modified between a given range whose “status” is one of the “Exportable” statuses

This section provides the main code logic for building the list

//on the publish_layouts.jsp the call below gives list of all the type of portlets which are selected during staging configuration step on the control panel



//loop through all the portlet handlers and get the export and get the handle of portletDataHandler and get the class name and the portlet title



//get exportModel and deleteModel Count



//if exportModelCount is greater than 0 and if the className is “Journal Article” for a dynamic query for “journal Article” class with “groupId”, “companyId” and “modifiedDate” as daterange



//Then add the criteria for “exportable status”



//Defines fields that you need to be returned from the query based on the information that you want to display



.//Execute the query and get the list



//Iterate through the list to create a arrayList objects for each asset record returned



5. Building UI to show the list

The screenshot below is a simplest UI that can be built using objects (titles, articleids, modifiedBys) collected above

Based on your requirement you can fetch more information about publishing assets and display or report as per your requirements




Enhancing the “Hook”

As mentioned at the start of this article, once you understand main steps/API call blocks of the publishing process, it is possible to create “hook”/”ext” plugin to expose more information about the current or previous publishing processes.

Also using Liferay’s role we can show/hide, set defaults or remove options on the publishing UI so that business users do not get overwhelmed by various options and the UI is simple for use. Admin users can still see all the options.

Additional Reading

You can refer to the working “hook” plugin “Web Content Publish List” in the Liferay Marketplace https://web.liferay.com/marketplace/-/mp/application/74882994. This article is first in the series of articles about Liferay publishing. In the next article, I will discuss how to provide a list of “Document and Media” files that are dependent on a “web content” article, which is being deleted. This will help content authors to either not “delete” the “web content” or first delete/de-reference the “document and media” files and then delete the “web content”.