The four templates
The entry point is
ws_search.htm. It fetches the results via an ExternInclude, and you design the output in incl_factfinder_search.htm.
ws_search.htm
This template corresponds to the shop’s normal search page. The only difference is one line:incl_factfinder_search.htm and inserts the result at this position.
ws_search.htm
ws_search.htm
incl_factfinder_search.htm
This is where the actual work happens. The template displays, in order, the search input field, the filters, the sorting, the number of hits per page, the paging bar, the campaigns, and finally the hits. Filters, sorting, and number of hits are in a sharedform element and trigger a submit when changed. The paging bar and the results are outside the form because they work with links.
incl_factfinder_search.htm
incl_factfinder_search.htm
The hidden field with
~E-Search_FollowSearchName~ passes the identifier of the previous search on to FACT-Finder. This tells FACT-Finder that the visitor is refining their search rather than starting a new one, and FACT-Finder evaluates this in its statistics. Don’t omit it.incl_factfinder_shopnavigation.htm
This template performs the same task for the category view. It looks similar to the search template but has three important differences. First, it checks on the outside with{E-Search_Success} whether FACT-Finder responded at all, and on the inside with {E-Search_Result} whether the filtering returns any hits. Both counterparts are left empty in the example and commented as a hint: this is where the normal WEBSALE category view belongs as a fallback.
Second, the filters on the one hand and the sorting and number of hits on the other are in two separate forms, because they go to different targets. So that changing one doesn’t lose the setting of the other, each form carries the values of the other as hidden fields.
Third, it handles price sliders separately. A pricerange filter doesn’t have a single value but a start and an end.
Category filters don’t appear in
{@E-Search_FilterField} in the shop navigation. The module deliberately filters them out because the category is already set via the navigation. This is added here. If you do need them, check a filter with {E-Search_FilterField_IsCat}.incl_factfinder_campaign.htm
You define campaigns in the FACT-Finder Campaign Manager and assign them a criterion there. In the template, you query this criterion as a parameter and thereby determine which campaign appears where.incl_factfinder_campaign.htm
incl_factfinder_campaign.htm
The third block shows a useful pattern: the negative bracketing with multiple criteria catches all campaigns for which you haven’t provided a design of their own. This way, no newly created campaign falls through the cracks.
Prerequisite in the shop.config
Both filter lists carry the same comment: you need the entryDirectShow = yes in the <SearchFactFinder-Filter> section.
The difference is subtler than the comment suggests. With DirectShow = yes, the shop takes over the filters as FACT-Finder delivers them, including the labels stored there. Without this entry, it only shows the filters you have listed yourself in the shop.config and uses the labels stored there. Depending on the setting, ~E-Search_FilterField_Text~ returns one label or the other. This is added here.
Reference: shop.config, section SearchFactFinder-Filter
What the examples don’t show
The templates use a small portion of the available filter tags. The reference page describes them in full. Reference: FACT-Finder, filters, sorting, and navigation Ten of them are also missing there so far and are added here. They are useful if you want to design the filter bar differently by filter type instead of as drop-down lists.You can limit the number of filter options offered in the
shop.config. If the limit is set, the module stops the {@E-Search_FilterField_Option} loop after this number.Note on all four templates
The examples use the HTML 4.01 doctype and
charset=ISO-8859-1. For a new shop, use the doctype and character set of your other templates instead, usually HTML5 and UTF-8.Compared to the previous documentation, four places in the listings have been corrected: “müglich” instead of “möglich” five times in the navigation template, the paging arrows
< and >, which appeared in the text as bare angle brackets, the inconsistent submit() versus this.form.submit(), and two comments with incomplete sentences.