we have a portal (6.2 CE GA3) where people are creating Web Contents.
When a new Web Content is created, it´s visibility is automatically set to "Site-Members". This requires the editors to change this for each individual Web Content:
Is there any way to set this to "Guest Role" as the new standard ?
Do you happen to have only private pages, or are you creating the web content from a private page? This might lead to the default being chosen this way.
I am positively aware of some defaults for the Document Library. It might be that there's a default for Web Content as well that says: If you're coming from the Control Panel and you have private pages, Liferay is better safe than sorry and defaults to site member visibility. If you only have public pages, Liferay will default to public web content in any case.
As you state in the comment below, I'm confident that this is the case. The conditions for the defaults:
If content is added from a public page: Default is public
If content is added from a private page: Default is member only
If content is added from Control Panel / Site Administration and you have any private pages in this site: Default to member only ("better safe than sorry")
If content is added from Control Panel / Site Administration and no private pages exist in this site: Default to public
Follow Tobias' suggestion in the comments and upgrade if you need to get rid of the private page.
Related
we´re starting our very first liferay 7 project and I am having troubles creating private user pages. We have 7 Pages that we want the user to have and those pages need to be private because we want to use the private messaging portlet.
I created a site template and I assigned it to my new user´s dashboard.
So the pages get created and the user has access to them (I verified by entering the URLs manually).
But how can the user navigate ? I haven´t found any way to show the available pages to the user. The Menu only allows the user to click on "My Dashboard" and that´s it ...
Any help is welcome.
Best regards,
Daniel
You need to give friendly url first to your site
You can give in site by changing the friendly url.
You can also provide different urls for private as well as public pages.
For public pages liferay appends web /your-friendly-url
and for private pages it appends group /your-friendly-url
Then give the url under Control Panel-->Configuration-->Instance Settings
and set the Default Landing Page property to /group/your-friendly-url.
They have mentioned it clearly as stated below:
Enter the friendly URL that is used by both public and private pages. The friendly URL is appended to http://ip/web for public pages and http://ip/group for private pages.
I'm retrofitting a V9 site with a new 'sub site' This site will have it's own navigation system and IA. My plan, maybe, is to create a new folder in the content tree named 'New Site' and then created all my pages and items within there.
For the domain, i would then create a domain alias, and set the 'Default Alias path' to the 'New Site' folder.
This so far seems clear. Is it possible to have cross site contamination? Ideally, the old and new sites wouldn't mix under a single URL. I'm worried about navigation on the old site ('css list menu') picking up pages from the new site.
Had i know this was the plan, i would have created folders for each site to isolate, but moving to that structure may cause a lot of problems.
Based on the answers you posted, what I've done in the past is to:
create a new page type called Divisions or whatever you'd like.
Then create a new page template which doesn't inherit anything from the master page and flag it as a master page. Add the webparts you need on there, specifically a Head HTML webpart with your stylesheets, js, etc. Because it won't inherit from the main master page. But if you have a stylesheet assigned in to the site in the Sites application, that will be inherited unless you specify otherwise on the General tab of each new sub site.
Back on the page type you just created set the default page template to be the master page you just setup.
Add a new sub site/page to the content tree
Add new pages under the sub site in the content tree. Set your navigation path to be /{0}/% so it always selects the sub site as the root.
In your other master page you shouldn't need to worry about the other pages, because the parent page won't be visible in the navigation so the children won't show.
I will sum the logic through 4 easy questions:
Can/should private pages have public child pages? (it seems private pages are using other site or context for any group/user)
Can/should public pages have private child pages?
Can/should hidden pages have non-hidden child pages?
Can/should a page which certain user is not allowed to VIEW have a child page which certain user is allowed to see?
Does some of the previous scenarios change parent page's behavior? I mean maybe allowing you rights to a child page makes you automatically authorized to see parent page.
Furthermore, what is the difference between hidden and *non-hidde*n pages? I can browse both through links!
In answer to your questions (for Liferay 6.1, may differ for earlier versions):
Private pages can only have private child pages
Public pages can only have public child pages but the children can
be hidden (so they don't appear in the navigation but can be
accessed directly by the URL)
They can, but they also won't appear in the navigation unless
you've changed your theme so that they do
Yes it can, and again it's up to you and whether you want to
theme to have that restriction or not
Parent page behaviour is not affected by child page settings.
Hidden page: Pages that are hidden from the navigation but can be accessed directly via links or typing in their URL
Non-Hidden pages: Can be seen in the navigation, and can accessed in the same way as hidden pages.
Private pages: Can only be accessed by authenticated members of the community that they belong to. They are effectively gated pages so hidden from public viewing without having to set the page permissions for Guest users.
I hope this answers all your questions.
~~ EDIT ~~
As Julien Lafont as mentioned below: Hidden pages are visible in the search portlet. If you want to hide them from a particular group of users, use permissions. Thanks Julien.
I want to create a link in a portlet so that I can navigate to a different page in the liferay portal. I order to do that I am looking for an API (can be liferay specific) that given a page name, would return it's url (it can be the friendlyURL as well).
Portal pages in Liferay are indeed called Layouts in APIs and DB tables. They're identified by plid field, can be obtained using LayoutLocalServiceUtil and related APIs, and also from some other calls like themeDisplay.getLayout().
However in order to build String containing URL to a page you'll have to concatenate friendly URL of portal, group and layout itself (i.e. /web/guest/home - web is portal URL for public pages, guest is friendly URL of guest group by default and home is friendly URL of home page/layout by default). This can be tricky, as you have to check whether this is a public or private page, etc.
And once you start using virtual hosts with friendly URLs for groups, things change. So this is not a good way.
To avoid manually creating URLs and have URLs that are guaranteed to be correct you should use com.liferay.portal.util.PortalUtil.getLayoutFriendlyURL(Layout layout, ThemeDisplay themeDisplay) a static method of PortalUtil - it'll do all the necessary work for you. Though you also need to provide ThemeDisplay and not only Layout.
The API to access pages in Liferay is the LayoutService. However, page names are not unique in Liferay and furthermore they are internationalized. So you need some unique property for a page to retrieve its url, besides its name.
If you really only have the page name, you can use LayoutLocalServiceUtil.getLayouts(...) to loop over all Layouts and check for some property (in this case its name).
At least in Liferay 6.1.20 one can use 'Link Portlet URLs to Page' to make links proceed to antoher page in your portal. It is under ´look and feel´ menu item of your portlet. For me this works fine.
cheers
try this one for current url
${themeDisplay.getURLCurrent()}
try this one for portal url
${themeDisplay.getPortalURL()}
So I've setup a site collection using the Publishing Portal template and stubbed out a prototype site structure including three tiers. At the second tier I've created a Publishing site and developed a custom master page for the site and its third tier children. The problem is that the banner graphic on a few pages should be modified to be inconsistent. Then I add two new ContentPlaceHolder controls to my master page in SharePoint Designer and use the SharePoint interface to create my new publishing pages. Finally, I verify in SharePoint Developer that they have the correct master page, add my asp:content controls to the pages and insert the page-specific banner graphic. The only problem is that the master page default content continues to be rendered in all page instances. If I create a new page from the master page in SharePoint designer, I get a different base class in the Page declaration than those created within the Publishing site. Do publishing sites ignore any non-SharePoint contentPlaceHolders?
There is nothing like SharePoint ContentPlaceHolders & non-SharePoint ContentPlaceHolders. When you add a Default content to the Master Page ContentPlaceholder and if you dont override it in the Content Page then it will be visible in all the Pages that use that Master Page. Only way to get rid of it is to Override those Content Place Holder with empty content in the Content Pages. As overriding contentPlaceHolder in all the Pages is not an good Aproach. What I recommend is not to place conent in the ContentPlaceHolder of the Master Page but instead , put the content in the Content Control page of the Pages, so that Content doesn't come in all page but only the page that needs it. Yes it not a good to put the exact same content in multiple page. but in your case that is only the Option. May be you try to wrap the content in to a User Control so that the code can be updated only one place