Assets remote publishing enhancement in Liferay portal

The portal provides remote staging and publishing capability through which the users can select subsets of pages and data, and transfer them to the live site of the remote portal instance. By this feature, we can export the selected data to the group of a remote portal instance or to another group in the same portal instance. The LAR export and import features are used for remote staging and publishing. These features are implemented in the PortletDataHandler API. As mentioned earlier, the intent of this API is to import and export application content to and from the portal in a database agnostic fashion for the portal core assets and custom assets.

The following diagram depicts an overview of remote staging and remote publishing. The Staging has a set of portal core assets, custom assets and groups of users. First, the portal will export related portal core assets and custom assets based on current user’s permission as a LAR zip file. And then the portal transfers this LAR zip file to the Live through tunnel-web http or https call. The Live will import related portal core assets and custom assets, as a LAR zip file, based on same user’s permission.

Abstracted from the Liferay development cookbook: Liferay Portal Systems Development (for liferay portal 6.1 or above version)

The staging and publishing are based on a page (a set of portlets).  Portlets that are check-marked will be Staged called staged portlets. This means that their data is published automatically whenever a page containing them is published.  The following is a list of staged portlets:

• Blogs (*)
• Bookmarks (*)
• Calendar (*)
• Documents and Media (*)
• Documents and Media Display
• Dynamic Data Mapping (*)
• Knowledge Base (Admin) (*) - or any custom plugins which have LAR import and export configuration.
• Message Boards (*)
• OpenSocial Gadget Publisher
• Page Comments
• Page Ratings
• Polls (*)
• Polls Display
• RSS
• WSRP (*)
• Web Content (*)
• Web Content Display (*)
• Wiki
• Wiki Display 

These portlets which are disabled and check-marked are always automatically exported even if they aren’t on the page. These which are disabled and not check-marked are never automatically published. Note that Collaboration portlets, such as Blogs, Message Boards and Wiki are excluded from being Staged by default as their data typically originates in Live.

As you can see, the staging and publishing capabilities are portlet-based. If the staged portlet contains one asset, that asset will get published. For example, the portlet Web Content Display portlet can display web content a time.  If the staged portlet contain many assets, these assets will get published, filtered by the the range (like All, From Last Publish Date, Date Range, Last, etc).. But in real cases, it would be nice to have a feature to remotely publish assets directly in asset-level.

This article will address following remote publishing enhancement.

• Add asset-level remote-publishing capability  (LPS-17235)
• keep the category UID same AS IS when importing or remote publishing (LPS-22092)
• Keep asset UID same AS IS when importing or remote publishing (LPS-17550)

Asset-level remote-publishing

Currently remote publishing feature is page-based. It would be nice to have a feature to remotely publish assets directly in asset-level. In fact, it would be cool that remote-publishing feature would support both layout-level and asset-level scheduling and publishing.

Use case

• create a web content articles A1, A2 and A3 by user A and / or User B
• schedule to publish A1 immediately by user A
• chedule to publish A2 in 10 min by user A
• schedule to publish A1 in 30 min by user B
• schedule to publish A3 in 60 min by user B

This feature could be implemented by a plugin – called asset-remote-publish-portlet.

List screenshots of the plugin implementation

Assets creation, using web content as an example

Assets selection

Remote publishing settings - reuse default portal settings

Publish selected assets - from the Stage to the Live

As you can see, you can publish one or many assets one time based on selection.

Keeping the category UID same AS IS

This feature (keeping the category UID same AS IS when importing or remote publishing) should be available for vocabularies, categories and tags.

Use case:

• There are two environments - the stage and the remote Live.
• In the stage, create Journal Article A1 (C11) and B1 (with categories C22). And C11 and C22 are same level categories (siblings) of the vocabulary V1.
• Push the article A1 and B1 to the remote Live. The remote Live should have V1, C11 and C22. Both C11 and C22 belong to the Vocabulary V1, and C11 and C22 are siblings.
• In the Stage, update C11 and C22, let C22 becomes child category of the C11.
• Push the article A1 and B1 to the remote Live. The remote Live should have V1, C11 and C22. Both C11 and C22 belong to the Vocabulary V1, and C22 should be the child of C11. No new categories related to C11 and C22 should be created, and relationship of C11 and C22 should be updated automatically.

Implementation:

when exporting / importing categories, keep the category UID (and vocabulary UID) same AS IS.

Keeping asset UID same AS IS

This feature (keeping asset UID same AS IS when importing or remote publishing) should be available for any asset (core asset like Document and Media Library document, Web Content artcile, or custom asset like Knowledge Base article) which has UID field.

Scenario I:

• There are two environments – the stage and the Live.
• In the stage, create Journal Article A1 and B1, and B1 is associated to A1 - Apply className-classPK pattern to JournalArticle.
• publish A1 and B1 from the Stage to the Live
  • A1 UID and B1 UID should be maintained same in the Live as that of the Stage
  • Association of A1 and B1 should be maintained same in the Live as that of the Stage

Scenario II:

• An editorial prepares release article with friendly URL http://${stage.domain.name}/release/${uid}/${article.title} in the Stage
• Before remote-publishing the release, he / she sends the release with expected friendly URL http://${live.domain.name}/release/${uid}/${article.title} to the mail-list
• Once remote-published the release, everyone should get the same URL for the release: http://${live.domain.name}/release/${uid}/${article.title}, for example, /feature/626347/2011-Year-in-Review-Collaboration; /feature/626323/2011-Year-in-Review-Core-Networks

Implementation:

When exporting / importing assets, keep the asset UID same AS IS.

More expected staging and publishing features

• WCM Staging: Synchronize Comments with production (LPS-11213)
• WCM Staging - UX Check boxes remain checked when publishing to Live after subsequent visits (LPS-12392)
• WCM Publishing - Option to disable approval process for articles (LPS-10456)
• WCM Video Publishing - Embedding on Asset Creation and Linking (LPS-13683)
• WCM Staging - Version/Reversions Publishing and Point in Time Previews (LPS-13562)
• Ability to remotely publish assets based on versions (LPS-17395)

Download URLs

6.0.12

6.1 CE
 

[Corné Aussems]

The download link is having to strict permissions set.
http://www.liferay.com/documents/31578/d33ac938-5e34-4b40-b546-eec204f5bd95

[Jonas Yuan]

Hi Corné,

Thanks for update. Do you meet download issue?

[Corné Aussems]

Yes i do

Forbidden

You do not have permission to access the requested resource.
http://www.liferay.com/documents/31578/d33ac938-5e34-4b40-b546-eec204f5bd95

[Jonas Yuan]

Yes, the permission VIEW on the root folder is missing.

Now you should be able to download the WAR.

Thanks

Jonas