I would like your support in order to get some help in customizing the search component in Liferay DXP 7.0 Enterprise.
I have reviewed all the available documentation but although I have found many articles about the issue, the step by step is not so clear for me.
I need to customize the native search component:
Change the input component to give suggestions while the user is typing the search terms
Change the search result page look and feel.
Anyone ever implemented anything like this?
I know this is an old thread, but StackOverflow keeps showing it as the first open question when I am navigation this particular tag...So here are some pointers, as this is a pretty broad topic...
The search is really confusing for adding customization. Mainly you have to provide some of them as contributors, using the asset framework. following the regular steps to build an asset for the asset publisher you will hit the best place to find documentation about the search contributors.
About the search page, best is to create a new page, besides the default one for extra freedom. As long you use the friendly URL /search it will a basic replacement. In this page you can add everything you need, except for translations for the friendly URL - not great. Another option is to keep the default page (which will not be visible in the build area 7.1.x, but you can edit after you search something and fall inside it).
Related
I've never used Drupal before (development or managing content). I was asked to extend the admin content page to have a filter and simply don't know enough to get moving quickly.
Can anyone tell me if adding a search by text filter in the admin content area requires code or is there a CMS feature like adding a node for this task.
If code is required, is there something like a hook for this area? Not sure where to start. I will be investigating on my own but pointers to get me oriented to Drupal would help.
By default Drupal provides search mechanism ready to use. But there are also additional module which can improve search experience. You don't need any coding to use that search. You already have search form block ready to use.
Go to Structure -> Blocks and find block called "Search form". Now all you have to do is to put that block in some region and it will appear on front-end. Of course if it's not already styled by your theme it may be needed to put some extra CSS to make it look nice. There are also some template files which you can override and put some your HTML if you need.
There's also template file for search results page (which of course will work out of box also).
You may also need to create new block region if you want to place your form at some specific place, not covered by any existing region defined by your theme (easy thing to do!).
See https://drupal.stackexchange.com/q/30633/101329, the "Admin Views" module lets you configure the search form as you like.
I have this requirement:
We have a journalarticle and we wish to have sections which have content for internal and external users for the application.
We are able to hide the content from rendering by implementing custom template on web content display and using a simple custom-field for a user which helps us to classify it.
Having said that when we search something as an external user, the search portlet is able to fetch an article where the search text is a part of internal user content, and due to the above mentioned template the content is not visible.
In short, from the user's perspective the resultant article does not match the searched term.
I wish to seek some pointer to check whether there is a mechanism to ensure that when an external user searches something then we only search the dynamic-element of the doc which matches the user type?
We have thousands of such articles and create multiple copy of the same article does not seems viable solution.. so any pointers would be a great help.
Liferay version : 6.2 GA4 CE
Thanks!
AJ
First of all: Not finding a search term in a document can be a sign of good working synonym resolution in the search engine. It's questionable if this behaviour is always wrong or only in this particular case. Remember google bombs?
That being said, I believe that this architecture of half-visible documents is flawed from the beginning. Ideally I'd suggest to change it, for example by splitting the information to two articles, so that you can use the standard permissions to resolve. If you link both, you can determine how/which article or template to use. It's not an ideal solution, but might be a workaround.
Another workaround might be to change Liferay's indexer component and index two different versions of the article, with two different permissions. Of course, you'll have to change the search side as well, so that you'll find each article at most once, even if it's now twice in the search engine.
Again - not ideal, but might be the quickest fix that you can get right now without changing the underlying architecture. However, to change the underlying architecture is my actual recommendation.
We are using Liferay as a classic CMS meaning that we compose pages using web content articles. There is an issue with Liferay's internal search I could not yet find a proper answer for:
Because web content articles are pretty much only building blocks for pages we don't want the search to show them as distinct items. The user should only get a list of pages that contain their search keywords, including all the articles put onto this page.
At the moment we can see two different approaches and both come with certain problems we could not solve yet:
Idea 1
We modify the journal indexer and try to obtain all URLs of the pages (how?) where the article has been placed on. Then we add them to the document to be indexed. In the search result we then can access the URLs and collect them. In the end we make sure every URL is only shown once.
Idea 2
At some point Liferay renders the entire page before sending it to the browser. If we somehow could put an indexer there, we could index the entire page. We then could limit the search to the special "page documents". Getting the fully rendered page would be the main issue here, because either we would have to run a crawler to frequently trigger this indexing or we would need to find a way to trigger page rendering from within an indexer or something like that.
I have been carrying this problem around for quite a while now and still could not find an idea good enough to spend time trying it out. If anyone of you has some input on those two ideas or maybe an entirely different approach, I would be extremely grateful.
I'll just answer myself, because by now we found a suitable solution to solve our problem:
In addition to the default search portlet there is also a "Web Content Search Portlet" shipped with Liferay. It seems to have been part of Liferay for quite a while now, but it's somewhat hard to find, because there is hardly any documentation for it (I only found the Liferay wiki page, which isn't really anything at all). It searches only within web content articles and shows links to the pages rather than just a link an isolated view of the article. It has much less configuration options than the default search portlet, however. Pretty much all it allows to change is whether articles actually have to be placed on at least one page to show up in the results.
So there is no need for any kind of custom indexer or any other "hack"...all we need to do is use the correct portlet. We will only need to write a hook that changes the appearance of the result page.
What you ask is interesting but your ideas are on the wrong direction.
Specially idea 2 it's particulary wrong because you cannot do indexing work meanwhile a page is rendered. Think about performace only.
In Liferay pages and assets are not directly linked: pages have portlets and portlets display assets (web content and more).
Liferay indexing refers and scans assets content, not refers the display result of the assets. Think about permission: the same page can display different contents depends on the user who looks.
bye
You know, the publishing suite offers other content than forum. for example blogs and also some custom content
i know how to add articles/widgets to the page itself, but how do i add such a thing into a forum secion?
for example, on the left column i would have forums and on the right column i would have some news reader widget
could someone help?
Maybe it is enough for you to enable the "forum sidebar" in the admincp.
admincp->Settings->Options->Forum Sidebar and Block Options->Enable Forum Sidebar=YES.
Now you can add custom blocks with HTML and PHP.
For vBulletin 3.x, the solution is to edit the appropriate templates (FORUMDISPLAY, SHOWTHREAD, etc). I can't be much more specific than that, I'm afraid, since the exact details will vary depending on what kind of modifications you've already made to your templates and the exact details of the widgets you wish to insert.
A client is asking to incorporate commenting on their news articles. They're using the Sharepoint news site template for their news publishing, etc. They want a simple commenting system, much like what is available on most blog engines, only they want it at the bottom of each news article.
I just thought I would ask around about an out of the box solution before I go quoting a custom dev solution. Thanks in advance!
I struggled with this a while back and the solution we found was to use a discussion borad list (out of the box) and we created a custom web part that we added to the page layout for news.
We had to do som trickery to add support for anonymous comments, but on the whole it works good and wasen't to much code.
The Community Kit for SharePoint does the whole commenting thing for blogs.
you may have to cut out the commenting part of it to get it to work with your news section however.
The commenting section of the Enhanced Blog Edition of CKS does to approval of comments and spam checking.
I had the same request. I didn't find an existing solution, so I did it by copying from the standard Blog site template, plus custom coding.
From the template: Copy the definition for the blog comments list. Remove the lookup fields, and use a feature to create the list on all publishing sites.
Custom code: Add a feature receiver to the comments feature, and use it to add the lookup fields for page id and title, (using the pages list as destination). This needs to be done in code because you can't configure the destination list for lookup fields in XML, (or at least I don't know how).
Write controls for querying the comments list and adding to it, and place on the page layout.
Simpler approach: Don't use the standard blog comments list, just create your own, where the page reference is just a number and not a lookup field. Pro: Less work. Con: You miss out on the views that come with the standard list.