Liferay GSearch is a modular and highly configurable, Google-like search application for Liferay 7.0 and 7.1 CE and DXP bringing many features missing in the standard Liferay search portlet available.
This application gives you full control over queries sent from Liferay to the search engine and makes it possible to consume user contextual information as well as create conditional subqueries, with the help of a rule engine. With this application you can, for example, bring certain result higher on the list based on user's Audience Targeting segments, location or keyword matching.
While this application can be used with Liferay embedded Elasticsearch or any search engine supported by Liferay, it's designed to be used with the provided, custom Elasticsearch adapter which extends the standard query type support.
The application has multiple extension points for customization and you can just choose to use the backend modules and create your own UI implementation.
- (2019-02-06) Core version 6.1 available
- (2019-01-29) New Custom Elasticsearch adapters for 7.0 and 7.1 (CE and DXP) available
- (2019-01-27) Core version 6.0.0 with DXP 7.0 backport and lots of improvements now available
There are basically two options for using this application: with or without the provided custom Elasticsearch 6.1 adapter.
With custom adapter:
- Take use of all the configuration options and extra query types for improving relevancy
- Use extra query types like function score queries to improve relevancy
- Use all the configuration options for Query String query (without, for example per field configurations won't work)
- Take use of improved Elasticsearch index configuration and mappings
- Use keyword suggesters
Without custom adapter
- Limited functionalities but can be used it with any supported search engine, like SOLR
- Works on recent CE 7.0 and 7.1 versions
Download Liferay GSearch binaries for your portal version from binaries folder.
Deploy JARS and check from log and from Gogo shell that everything deployed correctly.
Notice: If you don't plan to use the Audience Targeting or Geolocation integration, don't deploy those modules (check module names).
Deploy the GSearch portlet from Widgets menu to a portal page.
Create a page with friendly URL "/viewasset" on a same site as the search portlet and place an Asset Publisher on it.
Many features are disabled by default. Check configuration options in Control Panel -> System Settings -> GSearch. Defaults with examples are provided.
That's all.
In addition to the steps before:
Install standalone Elasticsearch 6.1 server and configure the portal to use that. See server installation instructions here
Dowload and deploy the custom Elasticsearch adapter binary (or binaries, depending on the portal version) from binaries folder for your portal version (see adapter subfolder).
To avoid any conflicts with the standard Adapter, put the respective module on a module blackist in the System Configuration. Notably on DXP 7.0, you also have to deactivate or uninstall the ES 2.1 adapter (or reboot portal after blacklisting).
Do full reindex to create custom analyzers, mappings and settings.
To enable Audience Targeting integration and support, install Liferay Audience Targeting plugin from Liferay Marketplace.
This is also optional but greatly enchances possibilities to use user contextual information in query boosting by allowing to use integrate Audience Targeting user segments in query conditions as well as automatically boost segmented content.
Check configurations in Control Panel -> System Settings -> GSearch.
Notice that More Like This portlet has a portlet instance configuration.
If you are willing to contribute or have problems or questions, ping me filing a ticket. I'm doing the project almost completely as a hobby, so the installation or configuration instructions are at times minimal. Sorry for that.
-
For keyword suggester to work, you have to update the custom Elasticsearch adapter OSGi bundle. Run "update BUNDLE_ID" in Gogo shell and you're good.
-
There's currently a bug in 7.1 Soy framework generating lots of log data. For now please set a logging level for com.liferay.portal.portlet.bridge.soy.internal.SoyPortlet to "OFF". Issue can be found here: https://issues.liferay.com/browse/LPS-85186
This solution, as it is, relies only on the content specific permissions which are indexed in the Elastisearch index. It doesn't take the role inherited permissions into account.
The standard Liferay search portlet relies on both the indexed permissions and on post permission filtering which happens after search results have been fetched. This approach has historically made features like paging and sorting problematic.
So, is this application secure? Because Liferay permissioning only supports grant and not deny permissions, this application is more restrictive than standard search portlet and doesn't expose anything, users should not be allowed to see. However as it doesn't take the inherited roles and permissions into account, users might not see everything they should see. What this means is, that this application is currently suitable mostly for public websites or for private sites where these restrictions won't matter.
If you want to enhance the provided solution and extend the permissioning support, you can override the default fi.soveltia.liferay.gsearch.core.api.query.filter.PermissionFilterQueryBuilder service implementation with a higher ranking implementation priority. The extension point has a dynamic reference option so that it'd be easily customizable.
This portlet hasn't been thoroughly tested and is provided as is. You can freely develop it further to serve your own purposes. If you have good development ideas, please leave ticket or ping me. Also many thanks in advance for any bug findings.