Staging Best Practices for Liferay Portal

This article documents some recommendations that administrators should be mindful of when they prepare to use Staging on their Sites, or when they are managing their already existing Staging infrastructure.

Local Staging vs. Remote Staging

When planning to use Staging, one of the first decisions that needs to be made is whether to enable Local Live or Remote Live Staging.

In order to help you make this decision, please consider the following information:

Local Staging:

  • Both your Staging Site and your Live Site are hosted on the same server. When enabled, the Liferay platform creates an identical hidden Site within the portal by publishing the pages and the selected portlet data. The cloned Site becomes the Staging environment and the original Site becomes the Live environment.
  • Local Live staging allows you to publish Site changes quicker because there is no network traffic involved. However, your server needs to have more resources, since the staged content is stored in the same database as the production content.
  • If your Site already has a lot of data when you enable Local Stating, creating a clone of it can take a while, and it can be a resource intensive operation. Your data is also not as well backed up as with Remote Live Staging.

Remote Staging:

  • Your Live Site is located on an entirely different Liferay instance/server. When enabled, the Liferay platform establishes a connection between the two Sites over the network. The Site on the remote server becomes the Live environment, and the current Site becomes the Staging environment.
  • With Remote Live Staging the data is more separated, so it is easier to distinguish and manage your assets. It also lets you deploy new versions of apps and content to your Staging environment without worrying about interfering with your Live environment, since they are located on a different server. However, publishing is slower with Remote Live than with Local Live since data needs to be transferred over a network.
  • Of course, you also need more hardware to run a separate staging server.

Publishing Custom Themes

  • When publishing pages that have custom themes, it is important that the Theme Settings checkbox is checked or the Live page will have the default Liferay theme.
  • This is because: When selected on export, the theme and color scheme chosen for the site are included in the resulting LAR files. When selected on import, the theme and color scheme settings are imported and all the pages are configured to use them.
  • Otherwise, the THEMEID and COLORSCHEMEID are shown that they have been deleted. This is a known issue where the THEMEID and COLORSCHEMEID are deleted on subsequent publications. See LPS-92943 for more information.

Optimize Your Hardware

You should think about your hardware before you start using Staging.

Network Speed:

  • In a Remote Staging environment the network will be a serious factor that you should consider. If you are planning to publish huge amount of data, lots of images, big videos, you should be aware that it needs to be pushed through the network. Because of this, placing the remote server outside of your subnetwork may affect the publication speed negatively.

Document Read/Write Speed:

  • For example if you use lots of images, you should make sure that Liferay can read and write them in a very fast way. This is true for your local filesystem as well, but especially for external repositories where you access your documents remotely.

CPU Speed:

  • In case you are publishing huge amounts of Web Content, it is not a disk or network intensive operation, but you need to make sure that your CPU is up for the task, because in this use case the Articles' actual string data will be processed and updated on the fly. For example all the links and references to their embedded data will need to be changed according to their location on the Live environment.

In order to come up with the hardware and Staging configuration that best fits your needs, it is highly recommended to do a lot of testing with different scenarios.

Decide Which Portlets You Want to Stage Before Turning on Staging

When you enable Staging, you need to select what content types you would like to stage.

  • Please note that this is an important decision since turning Staging on and off for individual portlet data can cause data inconsistencies between the Staging and the Live Site.
  • For this reason, in recent Liferay versions, it is no longer possible to modify the individual portlet configuration once you enable Staging. In case you need adjustments later on, you will need to turn off Staging altogether and re-enable it with your new configuration.

Publish Early, Publish Often, Publish Small

A very common mistake when someone starts using Staging is that they create all the content first, and then turn on Staging as the last step. However, regardless of the type of Staging you use, it is best to enable it on your Site before any data is added, or relatively early.

  • If you turn Staging on in a very early phase of the Site creation process, you can have smaller publications, you can publish incremental data, you don't need to wait for a long time for a publication to finish, and you can uncover possible issues early on.
  • You can publish smaller amounts of data by restricting your data set. You can do this based on content type and date range. For example, it is possible to publish only the recently created Web Content Articles without their version history (if you only need the latest version) or their referenced content (if you already published those separately, you don't need to do it again).

You can find more information about the publication options in the Staging Publication Form Options article.

Using Staging Efficiently

In order to help you avoid some issues that can happen when Staging is not used properly, we created a list of best practices for the most common use cases of Staging. Please check the Getting Started with Staging article for this.

How to Debug Staging

The majority of Staging issues happen during data validation because of the inconsistencies the process finds. Because of this, the most important step during troubleshooting is to locate the problematic entries. There are some general ways that you can use to do this:

  • Break the publication into components.

  • Try to publish your Web Content Articles only. Then Documents and Media only, etc. Until you have isolated the issue.

  • Increase the log level of multiple Staging related classes to DEBUG in order to get more information from the stacktrace. This way you can see which entry was processed before the issue happened.

    • Go to Control Panel > Server Administration > Log Levels and set the following Categories to DEBUG:

      com.liferay.portal.lar

      com.liferay.portal.kernel.lar

      com.liferay.portal.staging

      com.liferay.portlet.documentlibrary.lar

      com.liferay.portlet.journal.lar

  • You can configure the Liferay platform to keep the generated LAR file in the temp folder of the Live environment's Application Server after a successful or failed Staging publication. This can be very useful if you want to analyze exactly what data was processed by the Liferay platform. To do this, you can set the following properties in your portal-ext.properties file:

    #

    # Set this property to false to avoid deleting the temporary LAR during a

    # a failed staging publication process.

    #

    staging.delete.temp.lar.on.failure=false

    
    #

    # Set this property to false to avoid deleting the temporary LAR during a

    # a successful staging publication process.

    #

    staging.delete.temp.lar.on.success=false

Please check Before Opening a LAR/Staging Ticket for more information.

How to Turn Off Staging Properly

Depending whether you use Local or Remote Live Staging, you will need to be aware of a couple of things if you are ever planning to eventually disable Staging on your Site:

In case of Local Staging:

  • A duplicate Site is created to hold all Staging content when you enable it. This means that the original "real" Site is the Live one, which will only contain the created data if you publish it from Staging. Because of this, when Staging is disabled, all content that was not published will be lost.

In case of Remote Staging:

  • Special restrictions will be applied to the Remote Live Site when you enable it.

  • On the Live Site, administrators are not able to create new entries or edit existing ones for the Staged content. Because of this, when Staging is disabled, the Staging server will need to communicate with the Live server through the network to revoke these restrictions. If the Live server is not accessible (removed, or has different address), you will not be able to disable Staging on your Site.

Workaround

  • Make the Live server accessible again. Even if you removed the Live Site already, you will be able to disable Staging.
  • Use the export/import functionality to move the data to a different Site and remove the original Staging Site.
  • Contact Liferay Support and inquire about any additional solution after describing your exact scenario.

Additional Information

Was this article helpful?
0 out of 0 found this helpful