Resources importer mixes public and private pages?

[Geert van der Ploeg, geändert vor 7 Jahren.]

Hi,

I'm using the resources importer plugin to create hierarchies of both public and private pages.
The sitemap.json syntax example from the documentation appears to allow to do so, having both a 'publicPages' and a 'privatePages' element.

{
"layoutTemplateId": "2_columns_ii",
"privatePages": [
    {
        "friendlyURL": "/private-page",
    "name": "Private Page",
    "title": "Private Page"
    }
],
"publicPages": [
        {
            "friendlyURL": "/home",
            "nameMap": {
                "en_US": "Welcome",
                "fr_FR": "Bienvenue"
            },
            "title": "Welcome"
        },
        {......

However, on the page where you create a new site (having chosen the site template from the theme with the resource importer), there is a radio button choice called 'Copy as', which suggests that you can only choose between public and private.
The end result indeed looks like this; all pages end up being public, even the ones from the 'privatePages' section in sitemap.json.

So my question is:
Should the resources importer be able to create site templates with both private and public pages at the same time? If so, what's the use of the 'Copy as' option in the site creation wizard?

By the way: I'm running Portal EE SP 15.

[Olaf Kock, geändert vor 7 Jahren.]

Looks like you found a nice contradiction: The JSON format suggests that there's an option to declare both. The best practice documentation suggests to only import to a Site Template - which has neiter public nor private pages - it's used to template one of these...

Based on this, I'd (almost) expect that you can't have public AND private pages in a resource-importer, contrary to the documented JSON. The UI screenshot that you post suggests that any setting in JSON is always explicitly overridden. Have you commented on the documentation? (I just did, asking for a clarification - check the "Do you have a suggestion" link at the bottom, this then gets to the attention of the documentation team)

[Geert van der Ploeg, geändert vor 7 Jahren.]

Thanks Olaf for confirming the confusion.

Now I had some more time to look into this, I found out:

* There has been an official feature request for importing both public and private pages (LPS-35910, fixed in 6.2.0 CE M6, closed)
* The relevant part in FileSystemImporter.java (part of the resources-importer-web plugin) appears from the looks of it to make proper distinction between public pages and private ones.

So, to conclude for now: It _should_ be possible to include both public and private pages, but deeper down in the resources-importer-web plugin apparently something is not right?

[Geert van der Ploeg, geändert vor 7 Jahren.]

Having a bright moment...
Although as you say, Olaf, that importing into a site template is best practice, it's also possible to directly import into an (existing) site.
That would probably be the way to import public and private pages at the same time.
Will test that (and report here)...

[Geert van der Ploeg, geändert vor 7 Jahren.]

Yup, this clarifies it all.

The documentation states:

If you’d like to import your theme’s resources directly into a site, instead of into a site template, you can specify the following in your liferay-plugin-package.properties file:

resources-importer-target-class-name=com.liferay.portal.model.Group
resources-importer-target-value=[site-name]

If you do so, with a sitemap.json like in my original post, the particular site will be created with both public and private pages, each with their expected pages.

So, to wrap up: having 'publicPages' and 'privatePages' in your sitemap.json, but not having specified the properties above in liferay-plugin-package.properties, will effectively import the resources into a site template and, like Olaf said, a site template can have only one set of pages (not private nor public) which will only materialize into private OR public pages when you apply the site template to a newly created site.

[Olaf Kock, geändert vor 7 Jahren.]

\o/ Thanks for reporting back.

This clarifies a lot of confusion - hope that the docs team is able to roll this into the documentation to make it more explicit for the next one bumping into the issue.

[Michael Williams, geändert vor 7 Jahren.]

Good catch. We will update the docs to reflect this. Sorry for the confusion. Thanks!