I am using liferay search container to display list of information, but in that liferay search container by default display number of records like "Showing 2 results". But in my case i don't want to display this. How can I remove this? Also attached the image of search container.
Suggestions are welcome.
You can do this with Javascript as suggested by Felix Christy:
Here are the quick steps :
Go to "Manage Page" section of the desired page (page on which you
dont want to show this text)
Go to javascript section add the following, its Alloy UI javascript framework which comes bundled with liferay:
AUI().ready(
function(customA) {
customA.all('.taglib-page-iterator').hide(); // this would hide **all** the elements which have the class "taglib-page-iterator"
}
);
The above javascript code can be included in the custom portlet's JSP itself (note the method and selector which I have changed), like:
<aui:script>
AUI().ready(
function(customA) {
customA.one('#my-portletID .taglib-page-iterator').hide(); // this would hide only **one** element (the first it finds) which has the css class "taglib-page-iterator" under an element with id="my-portletID".
}
);
</aui:script>
Another possible solution through Hook:
You can create a hook as mentioned by Sandeep Nair to hide the results-text but you can put a condition to check to hide only if the URL of the page is for which you want to hide this or can have a condition to check for the particular portlet you want to hide this result-text.
So it will work normally for other pages and portlet, but will hide for your page and certain portlets which you define. This is an idea and have not tried it yet, but I think it would work. You can use the themeDisplay object which is available on JSP pages to retrieve the portlet-id.
Hope this helps.
Thanks to Felix Christy for suggesting the solution through Javascript.
I thought of converting my comments to an answer for better visibility to other members of this wonderful community.
It is because you are using page-iterator in your search container. When the records exceeds the default delta the message above will be replaced by showing-x-of-y-results alongside page numbers and controls for navigating to next pages.
If you dont want this then you have to modify the jsp page using hook. The name of the jsp is showing_x_results.jspf and following snippet is what you are looking for to modify in that.
<c:otherwise>
<c:choose>
<c:when test="<%= total != 1 %>">
<%= LanguageUtil.format(pageContext, "showing-x-results", numberFormat.format(total)) %>
</c:when>
<c:otherwise>
<%= LanguageUtil.format(pageContext, "showing-x-result", numberFormat.format(total)) %>
</c:otherwise>
</c:choose>
</c:otherwise>
In order to remove that String for some specific page, please put a jQuery/javascript on the page, which will hide that particular div/span which is showing that text.
In this case, it will not be shown on that page, but it will be available and will be rendered elsewhere.
Here are the quick steps :
Go to "Manage Page" section of the desired page (page on which you dont want to show this text)
Go to javascript section add this $('.taglib-page-iterator').hide();
This will only work, if you have included jquery.js in your theme. So please do it.
At present, hook (or ext if you want an extreme solution) is the only way you can do it.
Override the showing_x_results.jspf Fragment and comment/remove what's unnecessary.
The only "properties" that are configurable through the portal-ext.properties are these (LR 6.0.5)
#
# Set the available values for the number of entries to display per page. An
# empty value, or commenting out the value, will disable delta resizing.
# The default of 20 will apply in all cases.
#
# Always include 20, since it is the default page size when no delta is
# specified. The absolute maximum allowed delta is 200.
#
search.container.page.delta.values=5,10,20,30,50,75
#
# Set the maximum number of pages available above and below the currently
# displayed page.
#
search.container.page.iterator.max.pages=25
#
# Set this to false to remove the pagination controls above or below
# results.
#
search.container.show.pagination.top=true
search.container.show.pagination.bottom=true
You can find the latest (LR 6.1GA) Search Container properties explained here: http://www.liferay.com/es/documentation/liferay-portal/6.1/user-guide/-/ai/search-container
I wouldn't recommend hiding it from the client end as it will most likely break if you decide to upgrade your Liferay Installation. Hook is a safe way out.
Related
I need to create a footer in a Liferay-project, that can be modified from the instance. I've been trying various things in my footer-code and instance, but haven't figured out how to do it.
Any content inside the footer can't be touched and in page edit mode, Liferay says "This area is defined by the theme. You can change the theme settings by clicking more in the Page Design Options panel on the sidebar". I didn't get any help from Page Design Options either. Is there a way to do this?
I found the answer after hours of work and searching and want to share it with everyone here. The working solution was found here, in one of the comments.
You need to write some code (I use Freemarker/ftl) and then configure the site pages a bit, but here's how it works:
Put a new setting inside liferay-look-and-feel.xml:
<settings>
<setting key="footer-article-id" value="" configurable="true" type="text"/>
</settings>
This will create a new configurable option in page options, allowing you to input the ID of the web content.
NOTE: <theme> might get underlined red "The content of element type "theme" must match". This still prints everything correctly, but the tags are given in a wrong order. Inside my <theme>, I have <template-extension>, <settings> and <portlet-decorator> in that order, which removes the error.
Assign a variable in init_custom.ftl (cleans up the footer-code):
<#assign footer_article_id = getterUtil.getString(themeDisplay.getThemeSetting("footer-article-id"))/>
And then add this to the footer-code, to create the spot, where the content is visible:
<#liferay_journal["journal-article"]
articleId=footer_article_id
groupId=page_group.groupId
/>
After this, everything should be ready code-wise.
Create a Web Content for your footer. In the creation screen, there's an ID on the panel on the right. Publish your content and grab the ID.
Finally, go to Site Builder --> Pages and click on configuration from the top bar (behind three dots). You should see the input field like in the first picture: That's where you add the ID.
Save the settings and your web content should now be in the footer.
Hope this helps!
We're using Liferay 7.3 (CE) and are trying to embrace the relatively new feature of "Content Pages" with "Page Fragments". We're able to develop page fragments that already include portlets (named "widgets" in the context of content pages), using the <lfr-widget-WIDGETALIAS> tag. So far, that works.
Now we're trying to prepare page fragments that embed portlets with special portlet configuration applied. For example, we want to prepare a page fragment that just shows an asset publisher portlet configured to list WebContent articles from a pre-defined category. The user should be able to just put that fragment onto the page without having to care about the configuration of the asset publisher portlet.
We did not find any direct way to achieve that -- our first guess that the configuration could be written as attributes or content of the <lfr-widget-...> tag was deterred by a hint in the liferay docs that there are no valid attributes or content to attach to that tag.
Does anybody have an inkling of an idea on how to achieve embedding portlets in page fragments with pre-defined portlet configuration applied? (including out-of-the-box Liferay portlets?)
I figured it out myself.
That one thing that the Fragment Editor does not tell you is that the HTML part of a fragment actually is interpreted as a Freemarker template, with the caveat that only Freemarkers alternative syntax is allowed.
That, in turn, means that Liferays taglibs are available, which means we can use the tag <liferay-portlet:runtime> (ported to freemarker alternative syntax, of course), which does accept a defaultPreferences attribute. Now we can just configure the portlet once, find its portletPreferences XML data in the DB (see table PortletPreferences), remove values we do not want to preconfigure and then just use the resulting preferences XML as a value for the defaultPreferences attribute of the <liferay-portlet:runtime> tag.
Care has to be taken for any IDs (e.g. if you want to preconfigure an AssetCategory filter). Better fetch the corresponding object from the corresponding service and get the ID from that object.
This example provides the HTML part for a page fragment that places an AssetPublisher onto the page, preconfigured to show 12 items (instead of the default 20). (CSS, JS and Configuration of the fragment is the default as given by the Page Fragment editor.)
<div class="fragment-12345">
[#assign assetPublisherPortletPreferences="<portlet-preferences>
<preference>
<name>delta</name>
<value>12</value>
</preference>
</portlet-preferences>" /]
[#liferay_portlet["runtime"]
instanceId="${fragmentEntryLinkNamespace}assets"
portletName="com_liferay_asset_publisher_web_portlet_AssetPublisherPortlet"
defaultPreferences="${assetPublisherPortletPreferences}"
/]
</div>
Thank you for this, #orithena. You saved me a lot of trouble.
Another option, to achieve the same result but with simpler syntax, is to use the built-in freeMarkerPortletPreferences:
[#assign assetPublisherPortletPreferences=freeMarkerPortletPreferences.getPreferences({
"delta": "12",
} /]
In Liferay 6.1, we created a hook to hide the sign out link in the dockbar. However, when I look at the code for 6.2, I see the following:
<c:if test="<%= themeDisplay.isShowSignOutIcon() %>">
<aui:nav-item cssClass="sign-out" href="<%= themeDisplay.getURLSignOut() %>" iconCssClass="icon-off" label="sign-out" />
</c:if>
No matter how much I google, I can't find any reference to themeDisplay.isShowSignOutIcon(), aside from the API reference, which does me no good, as it is not commented at all. I did find the page that discusses the native LR theme properties and apparently determining whether to show/hide a sign out linkn is not one of the native theme properties.
Does anyone know if you can set the theme itself to show/hide the sign out link and how you would go about doing it?
I too analyzed ServicePreAction code, and found that all this code does is:
checks if the user is logged in or not
if yes, shows 'sign out' link, not otherwise
You can simply create a hook to override html/portlet/dockbar/view_user_account.jspf to either remove that code snippet from this jsp to hide it for all scenarios OR modify the condition to show/hide as per your requirements.
The only place that I've found where ThemeDisplay.setShowSignOutIcon is called is in ServicePreAction (linking master branch here). That being said, it looks like it's not configurable, but you can easily create another ServicePreAction in a hook. Please see an example in this plugin (referencing portal.properties and liferay-hook.xml, but naturally there's also code that I'm sure you'll find. It's not big)
Another option - if you just want to unconditionally get rid of the link: Use CSS to hide it. Yes, it will still be there, but any way you choose to hide the link, the actopm at /c/portal/logout will still be available...
Excuse me if I'm asking silly or easy question, but I just can't figure it out.
So, I have a theme, I want to render only portlets, skipping any journal articles.
Which is the most appropriate way to do it?
In your theme's resources, there is a portlet.vm template available in the _diffs/template directory. This template allows you to override the default presentation of portlets in general (e.g. change the configuration icons, remove the title bar, ...).
However, inside portlet.vm Liferay injects a predefined variable called $portletDisplay. This is an instance of the com.liferay.portal.theme.PortletDisplay class and represents the portlet that is currently printed.
You can use the $portletDisplay.portletName attribute to check for 56, which is the ID for all Web Content Display portlets. So, in short, encapsulate the parent <div> inside portlet.vm with the following condition:
#if($portletDisplay.portletName == '56')
<div class="portlet" ...>
...
</div>
#end
I am building a website with ExpressionEngine as the CMS. There is a "Work" section that displays all the projects, and a detail view that shows each project individually. It is at this point, on the single-entry view that I would like to have "prev" and "next" pagination. In my tests I have made it work when the URL is "somedomain.com/index.php/work/detail/" but it does not work when the specific entry is part of the URL: "somedomain.com/index.php/work/detail/some_project/"
I've tried putting the pagination code outside of the {exp:weblog:entries} tag as well as within it, but to no avail. This is what my pagination code looks like:
{paginate}
<ul>
{if previous_page}
<li>< previous</li>
{/if}
{if next_page}
<li>next ></li>
{/if}
</ul>
{/paginate}
You are using pagination for lists of entries, what you need is the next / previous entry tags:
http://expressionengine.com/user_guide/modules/channel/entry_linking.html
Hmm. I'm not sure what the issue is here, as I've never used the {pagination} tag in that way. After checking out the docs, I see that the example code for prev/next links inside of the {pagination} tag is wrapped inside of an {exp:comment:entries} loop instead of the normal {exp:channel:entries} loop.
The docs aren't very clear about the scope of this particular feature of the {pagination} tag. You might want to double check that, in your {exp:channel:entries} loop, you haven't included pagination as a value in the disable parameter.
You could also check out the page in EE's user guide about Next/Prev Linking, which details the use of {exp:channel:next_entry} and {exp:channel:prev_entry} tags in place of the {pagination} tag that you've been using. I've used these tags without a hitch, so I definitely recommend trying them if you can't get your method to work.
Best of luck!