[Ernest Marcinko]

You cannot access this content.

[Ernest Marcinko]

Hi Seamus,

Thank you for the details, it helps me understand the issue better.

You are looking for this hook:

apply_filters('asp_index_post', WP_Post $post, array $args);

In your case, the final code will look something like this:

add_filter('asp_index_post', function( $post ) {
	if ( $post === null ) {
		return $post;
	}
	$meta_key = 'available';

	if ( function_exists('get_field') ) {
		$available = get_field( $meta_key, $post->ID, true ); // ACF support
	} else {
		$available = get_post_meta( $post->ID, $meta_key, true );
	}

	if ( $available ) {
		return $post;
	}
	
	return null;
}, 10, 1);

Basically whenever the hooked function returns null, the post is skipped from the index. In the code above a check is made on the “available” custom field. If it is true, then the post is returned, otherwise null. It may need some testing to make sure the field values are that, but based on your description I assumed this solution.

[Ernest Marcinko]

Hi!

The stop words on the index will only apply to the index table. It is possible to apply the same stop words to each search instance too, here. Copy the same stop-words list to that field and it should fix the issue.

[Ernest Marcinko]

I don’t think a function will do a trick here, the original search form needs to be altered with an extra parameter. There is usually a searchform.php file in the theme directory, but it can be different, especially if it’s in the header. It might be somewhere in the header files or similar. It is differently for every theme, so it’s impossible to tell without going through all the source code.

[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 see, not sure why the output is altered though, shortcode blocks should return them as is. There is probably a wp_kses hook somewhere forced on the full output, as I see multiple similar paragraph wraps on the rest of the page. It’s not a big deal, but for some reason it happens.

Either way, my mistake with the custom CSS, the order value should be 9:

.probox p:has(.promagnifier) {
    order: 9;
}

This will resolve it.

[Ernest Marcinko]

Well, it is outside of Ajax Search Pro, but I will try to help. The only issue with the embedded search is that it’s not having the “post_type=product” argument, which is the trigger for WooCommerce to capture and display it’s product results page.

Maybe you can set up a .htaccess redirection, or a programmatical redirection so the post type argument is added.

Even simpler might be to add an extra hidden input to the modal search with the post type argument, so it’s autoamtically captured by the woocommerce results page. That might be the simplest possible solution in my opinion.

[Ernest Marcinko]

Hi,

Sure! No worries, I will initiate the refund process in a minute. It may take up to 30 days to complete depending on the payment method (it is usually much faster).

[Ernest Marcinko]

Forgot to add, if it’s not possible to change, no worries, this custom CSS will resolve it either way:

.probox p:has(.promagnifier) {
    order: 5;
}

[Ernest Marcinko]

Thank you! I see the problem.

On the results page, there is an empty paragraph injected to the search, right before the button, so the CSS doesn’t apply properly. This usually happens the the search is placed into text module instead of a shortcode module (or not it’s own module).

Can you please check if you can replace that block with the ajax search pro search block? My guess is, that right now it might be a text block with the search shortcode or something similar.

[Ernest Marcinko]

Great! The new version was released, after updating to 4.28.0 make sure to upgrade your code too to avoid the deprecation warnings.

[Ernest Marcinko]

Hi Steve,

May I take a look at the issue somewhere? I can probably tell just by looking at the page.

[Author]

Posts