Fatal error: Maximum execution time of 30 seconds exceeded

I have done a bit of further testing. I have also applied the code snippet to throttle the results to 250 but unfortunately the same error happens. This happens when using a portion of a word instead of a whole word. For example – If I just put in ‘aus garden’ instead of ‘australian garden’ the search times out and I get a fatal error. I am hoping this is just a setting or something that can be fixed.
I am using default operator AND – and I dont use fuzzy search and I have limit searches checked off. I dont have custom excerpts/snippets check off.

Does “checked off” mean the options is checked, or that it is off? “Limit searches” should be enabled.

Relevanssi is timing out while sorting the posts. Are you using the default relevancy sorting?

Do you have the fuzzy search completely disabled, or set to “sometimes”?

There is a check mark in the box beside ‘Limit Searches’
I am using the setting ‘Don’t use fuzzy search’
Default order for results: Relevance (highly recommended)

I think I have found the reason. I have a code snippet so that search results are sorted alphabetically – I deactivated this and it is now not timing out. This did seem to work fine before, perhaps some updates are making it now not work. Is there something I can change in the code snippet below or a new code snippet so that results are sorted alphabetically by product name ?

// SEARCH RESULTS – sort by TITLE OR NAME

add_action(‘pre_get_posts’,’sortby_title_query’);

function sortby_title_query($query) {
if ( isset($_REQUEST[‘s’]) ) {
$query->set(‘orderby’, ‘title’);
$query->set(‘order’, ‘ASC’);
}
}

It’s weird. Yes, the sorting procedure changed recently, and it is somewhat more complicated than it used to be, but it shouldn’t be that much slower.

In Relevanssi’s lib/search.php file, if you find this line:

if (is_array($orderby)) {

and add

var_dump(count($hits));

before it, what kind of results you see for searches that time out and for searches that don’t time out?

I get this weird code at the top left of the page -> int(123) the 123 is the amount of results. I tried deactivated my alphabetical code snippet and then reactivated it and tried searches both ways. Its the same results as before. whole word searches work, partial word searches give a fatal error if the alphetical sort is activated.

Not really sure what you expected me to see and so it is hard to say….

the partial word search brings back mostly irrelevant results even though I am using the AND option, it doesnt seem to be using that with partial words. aus garden brings back all kinds of results that aus is not in – seems to be like a fuzzy search even tho I dont have the fuzzy search option turned on. Using the whole word australian brings back the correct results.

But I can live with all that, if I could find a way to sort the results alphabetically.

I found your code snippet from here https://www.relevanssi.com/user-manual
so I thought I would try that, but it also gives the same fatal error with partial word search – same as the other code snippet I was using

add_filter('relevanssi_modify_wp_query', 'rlv_sort_by_title');
function rlv_sort_by_title($q) {
	$q->set('orderby', 'post_title');
	$q->set('order', 'asc');
	return $q;
}

That was what I was looking for… 123 results shouldn’t break the sorting.

Is the fuzzy search setting switched to “never”, or “sometimes”? Is the “OR Fallback” enabled or disabled?

I think you may have misunderstood – the 123 results are for the whole word results – that work. The searches that gives a fatal error – I just get a blank screen.
I am using the setting AND – require all terms
Disable or Fallback does not have a check mark beside it.
I have using the setting Relevance (highly recommended)
I am using the setting ‘Don’t use fuzzy search’
Limit Searches does have a check mark beside it.
Nothing else in the settings has a check mark beside it.

But what you said made me think – I dont think the ‘limit searches’ is working all the time even tho I have it enabled. Perhaps this is the reason partial searches are resulting in a fatal error when the sort by title code snippet is enabled.

When the code snippet to sort results by title is deactivated – sometimes I get the limit of 500 results – other times I am getting 870 results, 1000, 1088 results for a partial word search I just did.(if the code snippet to sort by title is activated – I get a fatal error)

Limit searches works per search term, so if the limit is 500 and you search with a two-word search phrase, you may end up with 1000 results.

If you change the var_dump(count($hits)); to var_dump(count($hits)); exit(); and add it to the same place as before, do you now get a reading for those broken searches as well?

Does it help if you disable the OR fallback?

I am using the setting AND – require all terms
If i put a check mark in the Disable OR fallback – I get no results at all in the search for the partial word search – but I dont get a fatal error either.

Re your code var_dump(count($hits)); exit();
With the code snippet sort by title enabled or disabled and using my partial word search I get a blank screen with int(1370) at the top left corner of the screen. I dont get a fatal error. (it doesnt bring back any results either for any search, other than the blank screen)

So I guess maybe thats the solution – put a check mark in the Disable Or fallback – and dont provide results for partial words….thats better than fatal errors….

If you search for “aus” and “garden” alone, how many results you find with each of those words?

Anyway, I did some testing, and the title sorting seems quite slow. I had a set of 500 search results, and the default relevancy sorting took under 0.02 seconds, while post title sorting took over 7 seconds. That’s over 300 times more than the relevancy sorting, so I guess it’s not a surprise that you’re running into trouble with the title sorting.

Version 4.0 of Relevanssi (out later this year) will run the sorting much faster: the new algorithm will do the same post title sorting in less than 0.5 seconds. That’s probably going to fix this issue for good.

garden would have well over 6000 results alone.

I will look forward to the updates you advise – slow is not great, but better than fatal errors.

Thanks