When a global search is performed within the CMS it displays the results using the 'Portal - Search Results' (search_results.do) CMS page.
The search results page is defined in two places in CMS: from within the CMS site record and the content configuration page.
| Within each CMS Site record: | Within the CMS Content Configuration page: |
 |  |
The Content Configuration page is where global defaults are specified. The global search results page will be used unless a different page is specified at the site level. This allows a different search results page to be be configured per CMS site if desired. There is a known issue where this doesn't work as expected (see: 'Search page' not overriding) and it is when a refined search is performed from the ' Search Results (Global)' dynamic block displayed on the 'Portal - Search Results' (search_results.do) CMS page...
...the page that displays this second set of search results will allows be the global default page from the Content Configuration record; if there is a different page defined in the site, it will not be used.
This occurs because all global searches on a CMS site are handled by a processor called ContentSearch. Content search begins to process the search term, then checks for the "sysparm_current_site" parameter within the "Search Results (Global)" [content_block_programmatic] record; however, it does not exist:
If the processor is not able to find this parameter it will default to whatever search page it finds on the Content Configuration [content_config] page. If the Content Configuration 'Search page' [search_page] is not populated or null, you are redirected to a blank page. This is because that page is looking for the sys_id of the content page and passes it to view_content with the sysparm_sys_id URI parameter and the url will look like this:
The workaround provides a link to an XML file containing a revised 'Search Results (Global)' dynamic content script that now includes "sysparm_current_site" which checks for the site's 'Search page':
<?xml version="1.0" encoding="utf-8"?>
<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">
<form name="content_search" id="content_search" action="content_search.do" method="post" style="padding-left:5px; padding-bottom:10px;">
<input type="HIDDEN" value="${current_page.getSiteID()}" name="sysparm_current_site"/>
<span class="globalSearch contextSearch" >
<g:evaluate var="sysparm_search">
var arr = new Object();
var sysparm_search = RP.getParameterValue('sysparm_search');
sysparm_search;
</g:evaluate>
<j:set var="jvar_cms_search_result" value="true" />
<j:set var="jvar_ts_groupid" value="" />
<j2:set var="sysparm_query" value="123TEXTQUERY321=${sysparm_search}" />
<g:inline template="textsearch.xml"/>
</span>
</form>
</j:jelly>
You can manually update the code above or import the xml file attached to the KB to resolve the issue.
This change will generate an entry within the Customer Updates as expected noting the record has been customized so any changes introduced on future upgrades will be skipped as the 'Replace on upgrade' is set to false:
It's recommended that you modify the 'Replace on upgrade' from 'false' to 'true' so updates introduced to this record by future upgrades will not be skipped per 6.7 Manage Customizations.
1 Comment
