Question marks stop ‘Scroll to first keyword match’ from working

[stu_zJTY]

Hi.

One of the reasons for us choosing Ajax Search is the scroll to keyword match feature. This is particularly useful when a search phrase matches an FAQ within an article, so when the user clicks on the article in the search results, it then automatically scrolls down the page to where the FAQ is located.

The problem we’re having is to do with question marks at the end of a search phrase and keywords within content articles.

For example, if we have an article that includes a section with the heading “how to stop a noisy dog”, if we search for “how to stop a noisy dog”, it will show that article in the search results and the click thru will scroll down the page to that section title. Perfect!

However, if we search for “how to stop a noisy dog?” (with a question mark), the click thru now doesn’t scroll down to the section title “how to stop a noisy dog”, instead it stops at a very loose match further up the page that has much less relevance.

Now, I did find a filter to remove question marks from the end of search queries, which did fix that particular issue. But, it then causes the following issue…

For example, if another article contains the sub heading “how to stop a noisy cat?” (with a question mark), if we do a search for “how to stop a noisy cat?”, the click thru to that article doesn’t scroll down to that sub heading because the filter is removing the question mark from the query.
Without that filter it would match and scroll down to it.

What we need is for the ‘scroll to keyword’ feature to work regardless of whether the search query, or keyword phrase in the content, contains a question mark at the end.

I tried various filter code snippets and admin settings but the crux of the problem seems to be with the Javascript that does the scrolling to the keyword match, which I wasn’t able to override.

We are using ASP with Elementor Loop Grid.

Please let me know if need any further information.

Kind reagrds

Stuart

[Ernest Marcinko]

Hi Stuart,

I see. I am not sure if this should be patched, as I feel this should be intentional for most cases, but I will definitely consider it.

You can actually fix this through a code snippet, but as you noticed this is on the client side, not on the server side. This should do the trick:

add_action('wp_footer', function () {
	?>
	<script>
	window.addEventListener("load", () => {
		document.querySelectorAll(".asp_main_container").forEach((el) => {
			el.addEventListener("asp_results_show", (event) => {
				// event.detail carries the arguments
				const [id, instance] = event.detail;
				document.querySelectorAll(".asp_r_" + id + '_' + instance + ' .asp_res_url').forEach((el)=>{
					const url = new URL( el.getAttribute('href') );
					let phrase = url.searchParams.get('asp_highlight');
					if ( phrase !== null ) {
						phrase = phrase.replace(/[!?]/g, '');
						url.searchParams.set('asp_highlight', phrase);
						el.setAttribute('href', url.href);
					}
				});
			});
		});
	});
	</script>
	<?php
});

[stu_zJTY]

You cannot access this content.

[Ernest Marcinko]

Unfortuantely this is unrelated to the plugin settings, the snippet is to do a client side correction on the arguments passed in the results.

In case you will have it somewhere public, I will check it out to see why the snippet isn’t doing it’s thing.

[Author]

Posts