PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-44316

[Regression] Staging - Publish to remote always publishes all contents

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Won't Fix
    • Affects Version/s: 6.2.10 EE GA1
    • Fix Version/s: 6.2.10 EE GA1
    • Component/s: WCM Staging
    • Labels:
      None
    • Similar Issues:
      Show 5 results 

      Description

      In previous versions of Liferay, it was possible to publish only contents from desired pages. In 6.2, Liferay always publishes all modified content, even if they are on other pages (not selected for the publication). This regression makes the staging environment useless.

      1) Enable staging environment for a site with 2 pages with a content on each page
      2) Modify both web contents (on each page)
      3) Publish to live but select only one page in the options
      4) Both content have been published to live (both pages have been changed)

        Activity

        Hide
        Mika Koivisto added a comment -

        This functionality is intentional as the way publishing is handled has changed. Here is the full explanation given by engineers involved in staging:

        The reason is that in 6.2 we no longer bind the content to the page that is being staged. When staging in 6.2+ you have to think of the content as belonging to the site and not to any particular page. Thus, if content has been updated, it will be published. The staging options are broken up into about six sections. These are "Date", "Pages", "Application Configuration", "Content", "Permissions", and "Remote Live Connection Settings". Each one of these options is for the site, so in a way, we stage the site each time we publish: the options just say which specific aspects of the site we are staging.
        In 6.1 we bound the content to a particular layout which meant that staging worked in a hierarchical way with pages being at the top, portlets second and specific content third.
        Now we do not use a hierarchical model. This is why the UI looks the way it does. It does not place content underneath pages, but places it in its own section.

        Show
        Mika Koivisto added a comment - This functionality is intentional as the way publishing is handled has changed. Here is the full explanation given by engineers involved in staging: The reason is that in 6.2 we no longer bind the content to the page that is being staged. When staging in 6.2+ you have to think of the content as belonging to the site and not to any particular page. Thus, if content has been updated, it will be published. The staging options are broken up into about six sections. These are "Date", "Pages", "Application Configuration", "Content", "Permissions", and "Remote Live Connection Settings". Each one of these options is for the site, so in a way, we stage the site each time we publish: the options just say which specific aspects of the site we are staging. In 6.1 we bound the content to a particular layout which meant that staging worked in a hierarchical way with pages being at the top, portlets second and specific content third. Now we do not use a hierarchical model. This is why the UI looks the way it does. It does not place content underneath pages, but places it in its own section.

          People

          • Assignee:
            Mika Koivisto
            Reporter:
            Sven Werlen
            Recent user:
            Esther Sanz
            Participants of an Issue:
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 1 day ago

              Development

                Structure Helper Panel