[Ernest Marcinko]

There are no silly questions.

You can still do it with a single instance + a bit of custom CSS.

First, make sure to turn on the settings visibility, so it’s visible. Then via custom CSS you can forcefully hide it on the front page like so:

div.asp_ss {
   display: none !important;
}

If you only add this to the front page, the settings will still be visible on the search.php.

[Ernest Marcinko]

Oh I see. I’m afraid no, that is not possible to do. At the moment for each taxonom only a single filter box is permitted.

I usually suggest a custom code where I can, but in this case it’s not possible. However it will be in a future release when a refactoring is finished on the search filter settings.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Sure!

By default the taxonomy names should be displayed above each filter. You can change that here: https://i.imgur.com/DFd5wHH.png

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi,

Thank you for the details!

To achieve the exact same grouping I have changed the configuration to a content type grouping, like so: https://i.imgur.com/OsUwarN.png

To maximize the performance I have enabled the index table engine. After that I did some testing on the responsiveness, and the search process now finishes within ~0.06 seconds accoring to the measurments, which is exceptionally good (meaning the optimization works).

I have also tested the server XHR response time, which is ~1.4 seconds for a completely empty request, meaning that is the minimum overhead added on top of Ajax Search Pro response times – so the total average response time is therefore 0.06 + 1.4 seconds. There is always some overhead, as this is the general time for WordPress to run initialize. This can be further improved by turning off unused plugins, removing unused code snippets etc..
I usually aim to use as few plugins as possible (mostly less than 10), but of course plugin quality also matters. The 1.4s overhead seems about average to me. On very highly optimized servers it’s around 0.4 seconds or even less, but that requires a lot of code optimization.
Chances are that on production it’s going to be lot less, as staging environments are usually shared on resources so they are not as quick as the production counterparts.

[Ernest Marcinko]

Hi Sebastian,

Special characters are automatically trimmed during indexing.

Excluding numerical strings from the index is only possible via a custom code:

add_filter( 'asp_indexing_keywords', function( array $keywords ) {
	foreach ( $keywords as $keyword => $data ) {
		if ( is_numeric($keyword) ) {
			unset($keywords[$keyword]);
		}
	}
	return $keywords;
});

Try adding this code via the Code Snippets plugin or to the functions.php file in your theme/child theme directory – make sure to have a full server back-up first for safety. For more details you can check the safe coding guidelines.

After adding the custom code a new index needs to be generated so the numerical values are excluded.

[Ernest Marcinko]

Hi,

Sure!

It is probably due to the default checkbox logic, meaning that it excludes everything that is unchecked. You can adjusted that here: https://i.imgur.com/nTjNeNF.png
That should resolve the issue.

[Ernest Marcinko]

Hi Sebastian,

All right, I will keep that in mind in case someone else has a similar issue.

[Ernest Marcinko]

I see. I checked the configuration and the filter logic was set to OR, I changed it back to AND, now it should be all right.

[Ernest Marcinko]

The issue was that the action was removed from the search result title and was replaced with the default permalink. I have changed it back to the action. Now it’s okay.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

It’s all good 🙂

[Author]

Posts