[Ernest Marcinko]

Hi,

The issue was only that a custom field was not selected which bricks uses to store the content, I have selected it for you here: https://i.imgur.com/XmlgVWb.png

Now it should return the correct matches.

[Ernest Marcinko]

I looked through the tickets but I couldn’t find either of them, I don’t recall their site names unfortunately. They didn’t share their code with me though, so it wouldn’t help either way.

If I were to solve this I would approach it like this:
– Loop through the main archive query and create an array of the groups based on the defined criteria
– Each group should contain the IDs of the posts/products for every group
– Generate sub-queries for each group
– If using a page builder, then name the queries and hook into them to override the IDs from the generated groups

Then figure out a way to perhaps use pagination, but that has to be also custom coded as the original paniation will not work correctly because of the subqueries and the divided result counts.

[Ernest Marcinko]

Hi,

I’m afraid it is because synonyms are only supported for post type results. For users, taxonomy terms and other result types is not yet possible, I’m sorry.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You are very welcome 🙂 I will keep this topic open for a few days in case something comes up.

If you like the plugin and have not rated already, feel free to leave a rating on the wordpress plugin repository, it’s greatly appreciated.

[Ernest Marcinko]

Looks good to me!

The number of results on the plugin’s end is controlled under the Search Sources -> Limits panel: https://i.imgur.com/8O5MCFn.png
That should do the trick 🙂

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Not sure, it can be a theme thing. It might be optimal to exlcude them from the results page overall to avoid any conflicts generally:

add_filter(
	'asp_query_args',
	function ( $args ) {
		if ( !$args['_ajax_search']  ) {
			$args['search_type'] = array('cpt');
		}
		return $args;
	}
);

Try adding this code via the Code Snippets (or similar) 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.

[Ernest Marcinko]

If the site output is different for mobile and desktop then it matters unfortunately. In this case that is what you try to achieve, to have a separate search layout for one and a separate search for the other. If it gets cached for one user agent, then it’s going to be served the same for both.

It’s not an issue when there is only one search. In this specific case you needed separate content length for desktop/mobile, but that I believe is not possible to achieve via custom CSS. As far as I know there is no CSS rule to limit word length within a block element. To get around it I suggested using 2 search bars, the caveat with this solution is that there is going to be a different output for mobile and desktop view.

If it’s more acceptable to use only a single search bar, then I can try to look for a different way to limit a keyword length based on user agent types via a custom code snippet on the server side, but I’m not sure how well that works when it comes to asynchronous requests, as that information is many times not available during that (I’m not sure).

I wish there was a custom CSS to do this, that would resolve this in 3 lines for sure.

• This reply was modified 10 months ago by Ernest Marcinko.

[Ernest Marcinko]

Hi Tom,

Thank you for all the details, I will try to answer everything to best of my knowledge.

SKU search
If you are using the index table engine, then I believe I have coded it to get the parent product fields even if the variations are not selected. Can you please try to de-select the variations from the index and re-index? Please let me know if parents show up from variation SKUs. If not, then I will look at a possible snippet to make it happen, it’s probabl doable with a small custom code.

Fuzzy Search
This is a bit more problematic, especially where single keywords come to the table. By default the keyword length for both searching and indexing is set to 2 – so singular characters are ignored. It’s also limited by mid-keyword matches, but that can’t be resolved.
First, you should try to change that on both the index table panel here (then re-index), then also on the search instance settings here.
It may improve it a bit, but it’s not going to be perfect.

Ordering
That is indeed the correct way to do it. No need to re-index either. You only need to re-index whenever you change anything on the index table settings menu.
This however will affect the performance a bit as a custom field subquery is executed to get the sales number. It shouldn’t be significant, unless you have tens of thousands of products. In that case it can be noticable.

Autocomplete & Keyword suggestion
Yes, of course. That includes the title field of every selected custom post type.

Speed
Sure!

So, to get the absolute best possible query performance you want to avoid the following: filters & exclusions
Those generate additional small sub-queries which can have a significant perfomance impact as they are uncoupled from the index. Looking at the first search bar configuration I found both. I think the filters should be removed, as I don’t see any use for them in the header. The exclusions are probably something you can also remove if you can live with some out of stock and catalog products in the results.

But again, this depends on the setup, you can expect about 10% performance increase from that.

More importantly I would consider reducing the number of plugins active if possible. Those generate a huge overhead for all the requests, including pageviews, admin page and also live search queries. I usually aim to have less then 10 plugins active when possible, but I know in many cases this is not possible of course. Turning off anything that you don’t use, or use only use occasionally can have significant benefits.

For years I personally don’t use cache or security (like WordFence) plugins anymore as those can slow down all requests by a lot. Instead I use Cloudflare to mitigate that task outside of WordPress, for us it works great and gives us the performance we need. Neither this site nor ajaxsearchpro.com use any cache or security plugins, instead we pay a $20/mo Pro plan on Cloudflare, and it handles all the caching and security outside of our local servers with great success. When “real” users and requests reach our servers we don’t have to check against any threats as it was already done even before reaching us. Keep in mind it is not a simple one click solution, it requires some configuration and back and forth to get it right. But when it’s right, it works like a charm. When you have Cloudflare setup correctly, using any cache or security is basically redundant in my opinion as all threats are already mitigated and you are only creating extra overhead.

I hope this helps!

• This reply was modified 10 months ago by Ernest Marcinko.

[Ernest Marcinko]

Hi,

The search results page in wordpress is specifically built to only display post type results. The plugin tries to “hack” those other results by sending fake posts with a modified url and titles as a placeholder.

You have two options:

1. To not display those results there using a custom code snippet. If it is okay to ignore them on the result page, then I can provide a small custom code snippet to exclude them when the results are directed to the search results page. Let me know if you need that.

2. To use the theme functions to modify the search.php file to fetch the fields from the live search (such as the images) on the results page. This requires custom coding though, so I only recommend doing that if you are comfortable with theme editing. These may or may not work, highly depends on how the search results page is built so I can’t guarantee anything.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

All right, the error message may actually help here – it says that the PHP PDF parser is not able to make a character conversion due to a reading restriction.

Can you please enable the external media service? There is a free version of it, and then the plugin will use the server to process the file contents via a custom built high-end document parser.
That should avoid this error message and allow the indexing of all documents correctly.

[Ernest Marcinko]

Okay.

Can you please check the results limit and increase it here: https://i.imgur.com/HwGGPrA.png

If less results are showing up, then it is possible that it’s because of hitting the limit.

[Author]

Posts