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.
Related
I asked this question over on the Kentico devnet but haven't had a definitive answer.
I have a particular requirement for a Kentico 8.2 implementation where in code, given a specific TreeNode, I'd like to find first all the zones on the template being used then, for each zone, get the details of all web parts and widgets used in those zones.
In my case I do not need to worry about template inheritance. None of my pages implement template inheritance.
I found this post on the old Kentico forums which suggested I might be able to do use PageInfoProvider to get a PageInfo object for the relevant TreeNode then use its PageTemplateInfo property to gain access to what I need.
However, I don't see a PageTemplateInfo property of CMS.DocumentEngine.PageInfo. There is DesignPageTemplateInfo and UsedPageTemplateInfo. I thought maybe UsedPageTemplateInfo would be the one, and it does indeed include the correct zones in its WebPartZones collection. But I don't see the web parts (actually, widgets) I'm expecting in the zones' WebParts collections.
I guess what I'm asking is, how can I use API to gain access to the content of the DocumentWebParts column from dbo.CMS_Document as a structured object? I've realised I can get access to the information I need by calling .GetProperty("DocumentWebParts") on TreeNode, but this is unstructured XML. I presume somewhere in the API I can get this information as a structured object.
Does anyone know how I might access the details I need? Thanks.
P.S. My template uses the ASPX+portal model.
As I mentioned in my second answer on the DevNet, you cannot specifically use the cms_document table simply because webparts function within templates and not with a specific page. Widgets on the other hand are specific per page even if the page has the same template as another page. Take a look at the example on the DevNet I provided, it should get you what you're looking for.
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
Suppose I have a huge set of noisy phrases. For each one of them, I want to check if it is defined by some resources by using the google define feature. Once I type "define my_phrase" to the google search box, if the retrieved results contain the definition panel (e.g. https://www.google.com/#q=define+home+cooking), I put it into my phrase pool.
I'm wondering is this possible to do this task in a batch so that I don't have to type each of the phrase manually one by one? It would be great if this could be achieved from a unix terminal but windows is also welcome!
I heard of google-app-engine but I only have a rough idea and not sure if it could help.
Thanks!
as starting point, you may try and play with the Google Custom search following API reference - Xml results
https://developers.google.com/custom-search/docs/xml_results?hl=en&csw=1#XML_Results
Be aware of:
google TOS for this service
quantity courtesy limit
The scenario - I am building a site to house a number of reports - thirty or so subsites under a main web for different report categories, and several libraries in each site, one for each separate report. In total, about 600 reports (libraries) across the thirty report categories (sites). This design has been decided on, and cannot change.
I plan/want to have a single advanced search page to search all the reports, using various custom metadata columns. That bit's easy, I can do that out of the box.
One of the most important search criteria is which report on which to search, of which, as I mentioned, there are many. The dictate is to make the report type added "invisibly" - they will select the report category, then the report type, and THEN get presented with the search page. The search should "know" which report is being searched on.
Scope selection is not a viable option, as there's too many libraries, and more will be added as new reports are created.
Now, I can get the results I want in the results if I add the "u" parameter to the URL as in;
results.aspx?k="RunDate=1/23/13"&U=http://site/report_type/library"
(address left unescaped for clarity)
My challenge is finding a way to feed that parameter TO the advanced search, and get it to tack it on to the end of its generated query.
I'm confident it can be done with only a little fidgeting to the webpart, but I need a bit of a shove in the right direction.
Or, as always, if y'all have a more brillianter idea, I could do that.
Now, I have a second issue where the different reports have their own varying set of metadata columns, and they only want the RIGHT ones to show up for each report, but one crisis at a time.
EDIT - upon further research, it seems I can't extend the advanced search webpart, as it's a sealed type. Has anyone either a way around that, or have a third-party advanced search page that I CAN crack into?
I was able to find a solution to this issue by overriding the JavaScript function NavigateTo(url) which is responsible for the redirect. My solution can be found here
What you are actually asking about is a contextual search box, as the u parameter resembles the contextual search scope.
I'm not sure that the standard search box can be configured the way you want it to, so it always adds the query string u=<current url>. I think you will have to resort to some (even if simple) code.
An example you can find here: Create a SharePoint Contextual Search Box in a Content Editor Web Part.
Of course you could do the same thing with server side code, but as you only want to add a querytring parameter, JavaScript should be enough.
I'm building an iPhone app that, among other things, allows the user to take and store photographs associated with locations. I am currently using the ALAssetLibrary to allow the photographs to be stored in Photos and be accessible outside the app (on a computer for instance via the built-in mechanisms). There is not a lot of technical content out there for working with the ALAssetLibrary but from what there is I have managed to cobble together a working version of this. I have had to resort to storing a dictionary of photo URLS in my app and manually detecting if the photo still exists when displaying lists of them because there does not seem to be a way to add custom metadata to an ALAsset.
What I would really like to do is add two custom metadata fields to each asset to provide it with a title and a custom id value that I can use to filter on when enumerating the asset library.
As a secondary task, I'd like the user to be able to update the title metadata.
Can it be done? At this point, I really don't think it can because the API really doesn't seem to provide the necessary methods to get/set custom metadata. I'm hoping against all odds that there is some other aspect to the AssetLibrary framework that I have not yet discovered.
At a minimum, if someone can authoritatively say "NO" then at least others might find this breadcrumb on their own trail of hope and change tack more quickly!
And, having 0 reputation I can't tag it with AssetLibrary :( wow, this day is just going downhill. FML
I've been looking over the documentation and I dont think it is possible to tack on additional fields to the ALAsset object, well you can create your own object or extend theirs but that wont help you when your pulling back assets because you'll need to init yours and populate it then.
Look I know this falls short of a really good answer but I had to try.
The ALAsset class documentation describes a property - customMetadata. This is documented to be an NSDictionary of whatever custom tags you want. Currently, however, it is not implemented in the class (I've raised a bug on Apple's developer site to bring the issue up).