自定义Plone中针对特定内容类型的搜索portlet [英] Customize the search portlet in Plone for specific content types

问题描述

我在网站的某些区域中使用搜索portlet，但我希望将结果限制为仅搜索特定的内容类型:例如，仅搜索新闻项，或仅显示教职员工目录"配置文件.

I'm using the search portlet in certain areas of my website, but I'd like to restrict the results to only search for a specific content type: for example only search the news items, or only show Faculty Staff Directory profiles.

我知道您可以通过该过滤器"列表进入@@search表单后执行此操作，但是有一种方法可以从启用过滤器开始，以便实时搜索"结果仅显示相关结果(即仅新闻项或仅个人资料).

I know you can do this after you get to the @@search form through that "filter" list, but is there a way to start with the filter on, so that the "Live Search" results only show the relevant results (i.e. only news items or only profiles).

推荐答案

我怀疑您已经知道了，但是请确保:您可以全局定义应允许在导航设置的搜索结果中显示哪些类型.控制面板，然后将相关零件导出并将其包括到产品的GS-profile- propertiestool.xml中.

I suspect you know it already, but just to be sure: You can globally define which types should be allowed to show up in searchresults in the navigations-settings of the controlpanel, and then export and include the relevant parts to your product's GS-profile-propertiestool.xml.

但是，如果您希望只在某些部分中排除某些类型，则可以自定义已经过滤类型的Products.CMFPlone/skins/plone_scripts/livesearch_reply，使其仅在第38行(版本4.3.1)周围显示"friendly_types"，并添加一个这种情况:

However, if you would like to have some types excluded only in certain sections, you can customize Products.CMFPlone/skins/plone_scripts/livesearch_reply, which already filters the types, to only show "friendly_types" around line 38 (version 4.3.1) and add a condition like this:

修改: 我删除了检查上下文的absolute_url的解决方案，因为在这种情况下上下文实际上是livesearch_reply，而不是当前的节位置.相反，该语句现在检查引用者是否是我们的部分:

I removed the solution to check for the absolute_url of the context, because the context is actually the livesearch_reply in this case, not the current section-location. Instead the statement checks now, if the referer is our section:

REQUEST = context.REQUEST
current_location = REQUEST['HTTP_REFERER']
location_to_filter = '/fullpath/relative/to/siteroot/sectionId'
url_to_filter = str(portal_url) + location_to_filter
types_to_filter = ['Event', 'News Item']

if current_location.find(url_to_filter) != -1 or current_location.endswith(url_to_filter):
    friendly_types = types_to_filter
else:
    friendly_types = ploneUtils.getUserFriendlyTypes()

但是，如果用户按下Return键或Enter键或高级搜索..."链接，则进入情况与进行调查的结果页不同.

Yet, this leaves the case open, if the user hits the Return- or Enter-key or the 'Advanced search...'-link, landing on a different result-page than the liveresults have.

更新: 将过滤应用于@@ search-template的机会可以是注册具有以下内容的Javascript:

Update: An opportunity to apply the filtering to the @@search-template can be to register a Javascript with the following content:

(function($) {
    $(document).ready(function() {
        // Let's see, if we are coming from our special section:
        if (document.referrer.indexOf('/fullpath/relative/to/siteroot/sectionId') != -1) {
            // Yes, we have the button to toggle portal_type-filter:
            if ($('#pt_toggle').length>0) {
                // If it's checked we uncheck it:
                if ($('#pt_toggle').is(':checked')) {
                    $('#pt_toggle').click();
                }
                // If for any reason it's not checked, we check and uncheck it,
                // which results in NO types to filter, for now:
                else {
                    $('#pt_toggle').click();
                    $('#pt_toggle').click();
                }
                // Then we check types we want to filter:
                $("input[value='Event']").click();
                $("input[value='News Item']").click();
            }
        }
    })
})(jQuery);

此外，不同的用户操作会导致不同的，不一致的行为:

Also, the different user-actions result in different, inconsistent behaviours:

• Livesearch接受不锋利的术语，而@@search -view仅接受锋利的术语或要求用户知道，您可以为错误的结果添加星号.

• Livesearch accepts terms which are not sharp, whereas the @@search-view only accepts sharp terms or requires the user to know, that you can append an asterix for unsharp results.

在实时搜索输入中按Enter/Return键时，搜索词将传输到登录页面的(@@search)输入元素，而在单击高级搜索..."时搜索字词迷路了.

When hitting the Enter/Return-key in the livesearch-input, the searchterm will be transmitted to the landing-page's (@@search) input-element, whilst when clicking on 'Advanced search...' the searchterm gets lost.

更新: 为了克服尖锐的结果，您可以在if语句之后将其添加到JS中:

Update: To overcome the sharp results, you can add this to the JS right after the if-statement:

// Get search-term and add an asterix for blurry results:
var searchterm = decodeURI(window.location.search.replace(new RegExp("^(?:.*[&\\?]" + encodeURI('SearchableText').replace(/[\.\+\*]/g, "\\$&") + "(?:\\=([^&]*))?)?.*$", "i"), "$1")) + '*';
// Insert new searchterm in input-text-field:
$('input[name=SearchableText]').val(searchterm);

Update2: 在此相关任务中，Eric Brehault提供了一个更好的解决方案，用于在提交过程中传递星号:自定义克隆搜索

Update2: In this related quest, Eric Brehault provides a better solution for passing the asterix during submit: Customize Plone search

当然，您也可以分别在livesearch_reply中的@@ search JS中自定义advanced-search-link的目标，但是此链接在UI方面是多余的，恕我直言.

Of course you can also customize the target of advanced-search-link in livesearch_reply, respectively in the JS for @@search, yet this link is rather superfluous UI-wise, imho.

此外，如果您仍然使用原型，并且根据上下文有更多用于预过滤搜索结果的用例，我建议您看一下罗斯·帕特森表示敬意！只需通过更改其视图将一个收藏集(旧样式)转换为搜索表单，它也可以显示为收藏集portlet.然后，您可以决定用户应该可以更改或不更改的条件(例如，隐藏类型过滤器并提供textsearch-input).

Also, if you're still with Archetypes and have more use-cases for pre-filtered searchresults depending on the context, I can recommend to have a look at collective.formcriteria, which allows to define search-criteria via the UI. I love it for it's generic and straightforward plone-ish approach: catalogued indizi and collections. In contradiction to eea.facetednavigation it doesn't break accessibility and can be enhanced progressively with some live-search-js-magic with a little bit of effort, too. Kudos to Ross Patterson here! Simply turn a collection (old-style) into a searchform by changing it's view and it can be displayed as a collection-portlet, as well. And you can decide which criteria the user should be able to change or not (f.e. you hide the type-filter and offer a textsearch-input).

这篇关于自定义Plone中针对特定内容类型的搜索portlet的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！