[Ernest Marcinko]

On the screenshot it’s highlighted, but that does not mean it was a match for that keyword. The highlighter script runs during the page load, after the query is completed. It is much more likely that either the other word, or a partial was matched somewhere and the highlighter highlights it as it only sees the search phrase – not the matching (it’s impossible).

Cyrillic should work the same way, it shouldn’t affect it.

If you want I can investigate this further, just make sure to add temporary back-end and FTP details, and I will run a debugging session.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi,

I assume you are reffering to this option under the search instance settings? What that does is when set to 3 is, when a phrase is entered, say “3 5 666” it is considered as “666”. So 3 and 5 are ignored. If there is nothing left, then the an empty phrase search is executed.

There is a separate keyword lenght option on the index table settings here: https://i.imgur.com/fvKZCnG.png
I suggest setting that instead, so shorter keywords are not indexed whatsoever. After changing the option you will have to make a new index.

On top of that, I recommend setting the minimum character count to 3 so the search doesn’t trigger under 3 characters, just to make it more user friendly: https://i.imgur.com/TcdLEd0.png

This configuration will ensure that no entries below 3 characters are triggered, and for longer entries phrases below 3 characters are completely ignored (as they aren’t in the index)

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Wow, thank you very much for sharing it with us 🙂 This might be helpful for others!

[Ernest Marcinko]

That code look okay to me, it doesn’t work?
The hook seems to be correct as far as I can tell.

[Ernest Marcinko]

That will not fix the issue, it is unrelated to the spinner. This is again caused by a 3rd party script, so I can’t guarantee anything. Normally the plugin does not blur the focus when displaying the results.

Try this variation:

add_action('wp_footer', function () {
	?>
	<script>
		const f = ( select = false ) => {
			let input = document.querySelector('.dialog-widget .asp_m input.orig');
			if ( input === null ) {
				return;
			}
			input.focus();
			if ( select ) {
				input.setSelectionRange(0, 9999);
			}

		}
		jQuery(document).on('elementor/popup/show', ()=>{
			setTimeout(()=>{f(true);}, 800);
			document.querySelectorAll(".asp_main_container").forEach((el) => {
				el.addEventListener("asp_search_end", () => {
					setTimeout(()=>{f();}, 500);
				});
			});
		});
	</script>
	<?php
}, 999999);

But again, this is just patching over and over something that may change and cause the conflict to appear again. It would be the best to find what the cause is.

[Ernest Marcinko]

All right, thank you for the feedback, I will make sure to include this fix in the next update.

The Lite and Pro are standalone plugins, so you should only have one of them enabled, in this case the Pro version. You can remove the Lite version if you want to, it’s not needed for the Pro.

[Ernest Marcinko]

The linked plugin works on WordPress 6.0 and above, including 6.1.7.

[Ernest Marcinko]

Hi,

I can confirm there is an issue with the keyword highlighter. The exact matching works all right, but the highlighter simply highlights the first phrase match incorrectly. Luckily this is a very minor bug and I was able to locate it and find a potential fix already.

Please download this beta version and install it.

After installation, clear all layers of cache so the scripts are refreshed. After that, the scrolling should prioritize exact match highlights and scroll to the first location of a possible exact match.

[Ernest Marcinko]

Hi,

On the error console there is a 403 error for all plugin assets, meaning that the files are not accessible, the server refuses to give access to them. This includes the scripts as well as the stylesheets: https://i.imgur.com/cATDnyi.png

The most likely cause is a permission change on the server side or a firewall block. I recommend these steps to resolve the issue:
– Make sure the wp-content/cache folder exists and it’s writable. The folder permissions should be 0755 and owned by the www-data user if you are using apache with mod PHP. If you are using PHP-FPM, please consult the server admin about proper folder ownerships.
– Also make sure the wp-content/cache/asp folder exists with the same permissions and ownerships.
– Check the apache mod_rewrite rules for any blocks for the upper mentioned folders

By default all of these should be just fine, unless the permissions or ownerships were changed on the server side by either a plugin/script or manually.

[Ernest Marcinko]

Hi,

The script still works, the focus is removed by something else. I see a lot of minifed scripts and some errors in the console so it’s probably related to that. The proper solution would be to find out which one is triggered during the pop-up open and remove the incorrect handle that causes the issue.

I can suggest a different method, but there is no guarantee it will work whatsoever:

add_action('wp_footer', function () {
	?>
	<script>
	jQuery(document).on('elementor/popup/show', ()=>{
		setTimeout(()=>{
			let input = jQuery('.dialog-widget .asp_m input.orig').get(0);
			input.focus();
			input.setSelectionRange(0, 9999);
		}, 800);
	});
	</script>
	<?php
}, 999999);

This should delay the focus by a bit, so could potentially override the incorrect blur.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

No worries, we will figure this out.

Can you please go to the Ajax Search Pro -> Compatibility & Other settings submenu, and change the script loading method to “Classic”: https://i.imgur.com/sTPZQ1w.png
After that, please clear all layers of cache: page, minify, cloudflare etc..

I just did a few tests and this seems to have resolved it on my end, I see the translations.

[Author]

Posts