[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi,

In theory yes, but definitely needs some custom work.

If it’s only CSS classes and nothing major, then I recommend using the group-header.php template file, where you can do some conditional checks via the $group_class, $group_url and $group_name variables.

If something more complex, then within the vertical.php you also have access to those variables, they are passed on, so you can do conditional checks against the $group_class, $group_url and $group_name variables too.

Based on that you could create more files like vertical1.php, vertical2.php etc.. and do logics like:

if ( $group_name === 'Group name 1' ) {
	require_once 'vertical1.php';
} else if ( $group_name === 'Group name 2' ) {
	require_once 'vertical2.php';
} else {
	require_once 'vertical_default.php';
}

..altough I’m not sure if the variables will be passed on to the required files.

Alternatively you can do the whole logic in the vertical.php file directly too:

<?php if ( $group_name === 'Group name 1' ): ?>
	<div>...</div>
<?php elseif ( $group_name === 'Group name 2' ): ?>
	<div>...</div>
<?php else: ?>
	<div>...</div>
<?php endif; ?>

[Ernest Marcinko]

Intersting, now the scroll animation triggers but it’s simply ignored for some reason. I don’t know if it’s a 3rd party script or an attribute, but something is blocking it.

Can you add temporary back-end details? I would like to install and test a beta release to see if a different method works.

[Ernest Marcinko]

Hi,

You can do that via creating a hidden post meta filter, this tutorial will explain it in details step by step.

I hope this helps!

[Ernest Marcinko]

Thank you!

I got the htaccess credentials, but not the log-in credentials for some reason.

It’s all right, from the front-end I see the problem. It seems like the selector has not been changed yet. Can you please make sure that this option is set to .green-overlay

The scroll is not triggered because the keyword parent selector is not found, but that should fix the issue.

[Ernest Marcinko]

Hi,

It’s likely due to the change in the block layout as it pushed itself to the left, and my guess is that either the page width or an overflow changes a tiny bit. Not directly caused by the plugin, but due to the inner block flow change.

It might be better to use an relative to absolute positioned version so the document flow is not interrupted. Try this custom CSS, this will basically remove the search from the flow, but retains the same position:

.asp_w_container.asp_w_container_2.asp_compact {
    position: relative;

    .asp_m {
        position: absolute;
        top: -32px;
        right: 0;
    }
}

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Okay, I suspected it has nothing to do with Elementor either, it wouldn’t make much sense, unless it was a bug of some sort, which at this point can be crossed out.

You can try this variation, but at this point I have no idea if it’s going to change anything at all:

add_action('wp_footer', function () {
	?>
	<script>
		let fakeInput;
		const detectIOS = () => {
			if (
				typeof window.navigator != "undefined" &&
				typeof window.navigator.userAgent != "undefined"
			)
				return window.navigator.userAgent.match(/(iPod|iPhone|iPad)/) != null;
			return false;
		};
		const focusInput = ( targetInput ) => {
			if ( !detectIOS() ) {
				targetInput?.focus();
				return;
			}

			if ( targetInput === undefined || fakeInput === undefined) {
				// create invisible dummy input to receive the focus first
				fakeInput = document.createElement('input')
				fakeInput.setAttribute('type', 'text');
				fakeInput.style.position = 'absolute';
				fakeInput.style.opacity = "0";
				fakeInput.style.height = "0";
				fakeInput.style.fontSize = '16px'; // disable auto zoom
				// you may need to append to another element depending on the browser's auto
				// zoom/scroll behavior
				document.body.prepend(fakeInput);
			}

			if ( targetInput === undefined ) {
				// focus so that subsequent async focus will work
				fakeInput.focus();
			} else {
				targetInput.focus();
			}
		}
		const f = ( ) => {
			let input = document.querySelector('.dialog-widget .asp_m input.orig');
			if ( input === null ) {
				return;
			}
			focusInput(input);
		}
		jQuery(document).on('elementor/popup/show', ()=>{
			setTimeout(()=>{f(true);}, 800);
			document.querySelectorAll(".asp_main_container").forEach((el) => {
				el.addEventListener("asp_search_end", () => {
					focusInput();
					setTimeout(()=>{f();}, 1000);
				});
			});
		});
	</script>
	<?php
}, 999999);

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

I understand, but the main issue is that it is not caused by Ajax Search Pro itself. There is no single piece of code that unfocuses the input field, it’s not possible to configure the plugin that way, it wouldn’t make sense at all.

If it’s only IOS the issue, all we have is to keep trying to workaround. I’m willing to help with it, even though it is way out of scope of support.

Can you please check if IOS phones is the only case where the code doesn’t work? I was working on a different feature where I found a yet uknown workaround for asynchronous IOS iPhone input focus which should work very well in this case too.
If every other device works and only IOS is left, then there is hope.

[Author]

Posts