[Ernest Marcinko]

Neat, then it’s a bug, I will make sure to perma fix this for the next release.

Copy the contents of the wp-content\plugins\ajax-search-pro\includes\classes\Search\SearchPostTypes.php and that’s it.

[Ernest Marcinko]

Interesting, I’m not sure why I can’t replicate this. I suspect it might be to do something with the timing.

Either way, I have a suspicion of what might be causing it. I see you have a child theme active, and I guess the other site may have the non-child theme active. So if I’m correct, then for some reason the switch of the blogs during the search is not reverting back correctly.

I have moved a piece of code via FTP so the switch happens sooner, but I can’t test it as it’s working on my end. Can you please see if you get anything different now?

[Ernest Marcinko]

Thanks for the details!

I tried every single possible way, but it seems to work all right on my end. I have noticed though, that the results cache is enabled – which could explain the issue. If the templates were not in place yet and a search was conduced, the results were cached including the complete output.
I can’t replicate probably because the cache have expired by now. I forcefully cleared the cache just to be sure, but I can’t seem to replicate the problem.
The templating paths are correct as far as I can see. I also recommend updating to the latest version of the plugin 4.26.11, just to be up to date.

[Ernest Marcinko]

Hi Dorian,

It’s possible via using a bit of custom code, this knowledge base will guide you how to.

[Ernest Marcinko]

Well, not exactly specific results for specific tags, but you can prioritize results individually.

Sorry about that crashed page, it was a debug output I forgot to turn off, now it should be okay.

[Ernest Marcinko]

I’m sorry Levon, unfortunately I am not available for custom jobs – development and support takes all of my time.

[Ernest Marcinko]

You are welcome!

I’m afraid none of those are possible.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi,

Thank you very much for all the details, it helped a lot.

It was actually a yet unknown bug related to a very specific configuration causing the problem. The issue was related to searching the post IDs, along with the “AND with exact keyword matches” logic + the stop words in combination.

What happened is, that the plugin tried to get “AND” matches from both the indexed sources and the IDs separately, ending up with some results being excluded and reverting back to the secondary logic, as if the primary was never considered.

I have made a few direct changes to the main search code to address that, I will make sure to include that in the upcoming update, so you don’t have to worry about it.

I have also made a few changes on the configuration, adjusted the keyword logic, and also added the stop-words as whole keyword exceptions so when people type it in they are being ignored (as they are not indexed). Now you should get much more relevant matches as expected.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi,

Looks like you may have some corrupted files on there. Make sure to delete the plugin first, then install it again. That should clear the plugin directory from corruptions and resolve the issue.

[Ernest Marcinko]

That should not be happening at all. I just checked the corresponding code section, and it should always include the template from the theme directory if it exists, regardless of anything.

I may have to check this directly to see what is going on. Can you add temporary FTP and back-end access? I will try to run a debug query to see what’s going on in the template engine.

[Ernest Marcinko]

Yes, exactly like that – but that would not help either, because the post object does not contain the metadata information. The post meta needs to be fetched either way separately.

According to the docs, somethins like this is the way:

add_filter('asp_result_css_class', function($css, $id, $result){
	if (isset($result->post_type) && $result->post_type == 'product') {
		$product = wc_get_product($id);
		if ( $product->is_type('external') ) {
			$css .= ' my-css-class-name';
		}
	}
	return $css;
});

But if the is_type function can be stubbed with post meta check for the product type, then it might be a bit more efficient, as the wc_get_product is then not neccessary, saving some queries. I’m not sure how WooCommerce stores the types, but I guess it’s post metadata, so it’s probably doable.

[Ernest Marcinko]

You cannot access this content.

[Author]

Posts