Bug 10831 - QueryParser requires that defaultSortField and defaultSortOrder be set to non-NULL values
Summary: QueryParser requires that defaultSortField and defaultSortOrder be set to non...
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Testopia
Depends on:
Blocks: 12742
  Show dependency treegraph
Reported: 2013-09-05 21:37 UTC by Galen Charlton
Modified: 2020-11-30 21:45 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Note You need to log in before you can comment on or make changes to this bug.
Description Galen Charlton 2013-09-05 21:37:25 UTC
If QueryParser is enabled, the system preferences defaultSortField/defaultSortOrder (and their OPAC kin OPACdefaultSortField/OPACdefaultSortOrder) should not be set to NULL values.  Otherwise, for searches where the sort order is not explicitly specified (e.g., searches made from the staff and OPAC global search box), the search can fail.

This is due to several slightly questionable coding constructs collaborating in the confusion of both the user and the developer:

[1] If a default sort order is not set, catalogue/search.pl and opac/opac-search.pl can end up setting the @sort_by array to (undef).  This is because of the construct

@sort_by = $cgi->param('sort_by');

If the sort_by CGI parameter is not passed, the result is not an empty array, it's an array containing one element whose value is undef.

[2] The following code in C4::Search::parseQuery in turn uses @sort_by to add QP modifiers:

        if ( scalar(@sort_by) > 0 ) {
            my $modifier_re =
              '#(' . join( '|', @{ $QParser->modifiers } ) . ')';
            $query =~ s/$modifier_re//g;
            foreach my $modifier (@sort_by) {
                $query .= " #$modifier";

If the query is "history", the modified version becomes "history #" ... which in turn results in a query that will not make sense to Zebra.

One solution is to push through a DB update that extends the fix for bug 8012 to  set the system preferences to sensible default values (probably relevance descending) if they're currently NULL.  Note, by the way, that this means that the bug manifests itself only in databases old enough to have been created before the patch for bug 8012 was pushed.

Another part of the solution, however, ought to be make the code in question a little more robust.
Comment 1 Katrin Fischer 2020-02-24 20:50:13 UTC
We've voted to remove the QueryParser code (https://wiki.koha-community.org/wiki/Development_IRC_meeting_4_March_2020), so I am closing this WONTFIX.