Introduction

For a long time now Private Pages have been deprecated by Liferay...

From a platform perspective, they are really a pain. A site can be made up of two different kinds of pages, public and private, they [potentially] have different host urls, but generally they are confusing to new Liferay adopters (we often hear questions like "What's the difference between a public and a private page?" and "When should I use a public page without guest view permissions vs a private page?", etc.).

For these and other reasons (including complexity in the internal code having to deal with two different types of pages and page sets), we have really wanted to eliminate private pages...

However, for existing sites and implementations that use private pages, well removal of private pages would have been a hard thing to do without. Many arguments against this are available, from "it will take too much time/effort for us to convert private pages to public pages", "we need the separate site for the private pages", "the tools to ensure a site only has private pages are incomplete or lacking", ...

These counter arguments are finally starting to fall away. Liferay is working on an upgrade process to migrate private pages to public pages (still a work in progress, check the conclusion for how you can help). Separate url for the private pages really just means a new site with that friendly url assigned. And the tools necessary for bulk-managing private pages are now available and ready (I'll review these more below).

So now that Liferay sees the remaining arguments have been dealt with, the days for private pages are truly numbered.

Okay, so how do we prepare for this in advance? How do we learn about the new bulk-managing of private pages? All we need to do is keep reading...

Private Site Alternative

Okay, so the first alternative we have to talk about is the private site...

Often what we would do is have a single private site with both public and private pages. The public pages are visible to guests and authenticated users (typically the content was the same for both), and then the private pages were reserved for the authenticated users. With the private pages, a separate domain name could be assigned so authenticated users could access the private pages directly, although with the /web/ and /group/ URL prefixes, there were alternate paths to access the private pages even when they had the same friendly URLs as public pages (i.e. you can have a public page as /welcome and a private page as /welcome).

With this model, site content (web contents, documents, etc.) could be used in both the public and private pages since it was all a single site.

So what are the alternatives here? One is two sites plus an asset library...

In the asset library, we store all of the site content (those web contents, documents, etc) and share it with the sites. This ensures that we can share content between the public and private sites just like the way content could be used in a single site with public and private pages. However, we will not be able to share design artifacts between the two sites (like fragments, templates, etc.).

If our site has both public and private pages, we now want to separate this into two sites, one for the public pages and one to contain the private pages.

A second alternative is a public site with the private pages moved to a child site. As a child site, it would have access to the content and design artifacts of the parent, public site, but the sharing can only be in one direction and the child site, well the pages there need to have no guest view permissions on their pages (more on how to do this below).

Private Page Management

The big advantage for private page management - any page you put in the private pages section, whether you changed permissions or not, guests were unable to view the pages in that section.

Since you didn't have to think about permissions when putting a page into the private pages, often times we didn't, we just created the page and then started editing it.

When private pages are eliminated, as page creators we will be responsible for verifying and managing that there are no guest view permissions on a page.

Verifying Guest View Permissions

In the latest quarterly release (2024.Q3 for me), you can see some of the changes Liferay has made to help confirm private pages. In the screenshot below, we see the Pages control panel; one page is private in that it has no guest view permission, and we can see that Liferay has decorated this page with a special icon:

This visual marker allows us to easily see pages that guests can view vs the private pages they can't.

Bulk Permission Changes

In the previous image, we note that only one page is marked to indicate it is not guest viewable. But what if we needed to change all pages so they were not guest viewable?

In the past we'd have to go to each page separately, open the permissions dialog, remove the guest view permission, save the dialog, close it, then wash/rinse/repeat for every page separately.

Well also in the 2024.Q3 release we now support the changing of page permissions in bulk.

See all of those checkboxes to the left of the page name? Just click all of the ones that you want to change, and in the toolbar click the Permissions action. Then just remove the guest view permissions and save and close the dialog.

Currently you'll be forced to refresh the page, but when you do you'll see that all of the pages that you've selected all have the same indicator icon that we reviewed in the last section.

Unfortunately at the moment the permissions do not cascade, so you can't for example remove guest view from a parent page and expect that it gets removed from all child pages... But at least with the bulk option, we can update all of the child pages easily through the checkbox mechanism covered here.

Default Permissions

A new feature available in later versions of Liferay but hidden behind a Feature Flag is the new settings for Default Permissions.

If you navigate to the Instance Settings control panel, then pick the Feature Flags item, you can find and enable the Default Permissions feature flag:

Once you enable this feature flag, in the Instance settings as well as in the Site Settings there is a new panel for Default Permissions:

With Default Permissions, you can set the default permissions to be used for all new assets (currently only Pages are supported, new asset types will be added on demand, so if you need this be sure to open a support ticket).

When you change the Instance settings, these will be the default permissions for all sites that do not have explicit settings of their own. When you change the Site settings, these will be the settings used for the selected site only, not for other sites.

Using this mechanism, you can set the Default Permissions for pages so they do not have guest view (basically making them private pages).

You'll still be able to edit the permissions for a given page and add/remove guest view permissions, but the default permissions will ensure that you are only doing this for exceptions instead of having to remember to do them for all pages as you create them.

Call To Action

Rather than the usual Conclusion section that I typically have, this blog is going to close with a Call To Action.

Basically we need to hear from you. We need to know about your use of private pages (whether you use them separately or in addition to public pages). We need to know about the UI enhancements that have been made to make working with and managing pages (just pages now, not public or private pages any longer) to ensure they do or do not have the guest visibility as required.

We need to know about gaps - gaps in our plans for the upgrade process that will remove private pages, gaps in usability, etc.

So this Call To Actions is basically asking you to reach out to us. If you're a DXP client, open a support ticket and start the conversation now (while changes can be made to accommodate your use cases before the change goes live).

If you're a partner, reach out through the typical channels to share your implementation stories with us.

Even if you're using Liferay CE, reach out to us on the Community Slack and let us know what you're thinking.

This change is coming, and it will happen. We're asking for as much feedback as we can get to ensure that when it happens it will be the least impactful way. Now is your opportunity to share that feedback, so I really do encourage you to reach out and make sure that your voices are heard.