Search page show all post types

[pawkat]

Describe the bug I want to see on the search page only posts, the current URL is "https://superstate.no/?s=lmnt", I just add the get parameter for limit post types and the URL wll be "https://superstate.no/?s=lmnt&post_type=post". The bug:

• page 1 shows 1 post
• page 2 shows 3 posts
• page 3 shows 1 post
• page 4 - 404 page

To Reproduce Open the page https://superstate.no/?s=lmnt&post_type=post Or you can:

1. go to the https://superstate.no/blog/ page
2. enter search keyword "lmnt"
3. click "Enter"
4. on the search page add "&post_type=post" to the URL

Expected behavior each page should show 9 posts like it was with the common URL

Screenshots https://prnt.sc/441q_wPtGArG https://prnt.sc/0eDhaTDkAxmf

Additional context Please let me know if there is some another way to do it

[tw2113]

Not sure if you are working on this right now, but the way things are showing changed part way through me looking at everything.

Initially it looked like the results weren't being powered by Algolia at all, and then when I used the search at the top, I was at least able to confirm that Autocomplete was working, but wasn't completely sure about InstantSearch.

[pawkat]

@tw2113 Sorry for the late response, please see the screenshot (https://prnt.sc/ujBGM45y5JPz), you can see that there is chosen "Use Algolia in the backend". And I checked wp-query, your plugin updating common query, for using parameter "post__in"

[tw2113]

Gotcha, it's only the setting used to modify WP_Query behind the scenes and serve Algolia results with that.

I don't think we have that out of box with the plugin, but I have to think this could be done with your own custom callback on pre_get_posts.

Something like:

function wds_algolia_limit_algolia_post_type( $query ) {
    if ( is_admin() || ! $query->is_main_query() ) {
        return;
    }
    if ( ! $query->is_search() ) {
        return;
    }

    if ( ! empty( $_GET['post_type'] ) ) {
        $query->set( 'post_type', sanitize_text_field( $_GET['post_type' ] ) );
    }
}
add_action( 'pre_get_posts', 'wds_algolia_limit_algolia_post_type' );

[pawkat]

Hi @tw2113, I make updates that you suggest, but it isn't working as expected, could you please see the result? Steps to reproduce:

• go to https://superstatedev.wpengine.com/blog
• enter a keyword, for example, "lmnt", and click enter (https://prnt.sc/VAbZdEvecHqT)
• you will be redirected to the search page The problems:
• 1st page shows only 1 posts
• 2nd and 3rd pages shows 2 posts
• 4th page = 404

Expected result: showing 10 results on every page like on live (https://superstate.no/?s=lmnt), without 404

[tw2113]

I'm going to need apache lock credentials to view that staging site. Emailing them to support@pluginize.com would reach me, and I recommend using https://onetimesecret.com/ as well for that.

Admittedly I didn't directly test the snippet above, I was largely going on muscle memory for modifying queries. That said, I wonder what the request is ending up being for the algolia arguements. I believe that may be able to be seen in browser consoles and the XHR requests.

[pawkat]

@tw2113 done, check your email inbox

[tw2113]

confirmed receiving and reviewing soon.

Thank you for your patience over the weekend.

[tw2113]

Without being able to see the request queries, it's a bit hard to say. One thing I did notice is that &post_type=post is also being appended and that's limiting things to just the post post type. When I removed that from the query string, I was seeing more results and 10 per page. Looks like the search form in question has a hidden field setting the post type by default which definitely feels like it's playing a part in things.

[pawkat]

I can provide you admin and ftp credentials, and you will be able to see the query. Could you help me research resolve of this task?

[tw2113]

Before we go that route at all, when you remove the &post_type=post portion of the URL, are you seeing the results/display that you're expecting? It's basically telling the search query to only do post.

[pawkat]

Yes, without the post type parameter it’s displaying correctly, but I need to show only posts on this search page

[tw2113]

As a secondary question, are all the posts you're expecting to see for this, in the Algolia index with the correct post type values?

[pawkat]

Yes, see screenshot https://prnt.sc/Z05XFPZDhHeY, https://prnt.sc/Fu91keAtHkng, https://prnt.sc/Dt7JYyhXknqU

[tw2113]

Trying my best to avoid logging in to support sites whenever possible for what it's worth.

Have you ever heard of the plugin Query Monitor? https://wordpress.org/plugins/query-monitor/

It could provide more information, including what's going on with the request itself. For example, I did a quick setup of Algolia in a local install, and set it up to be just backend, and here's what I'm seeing for a search query:

I'm curious what this main query would look like between the one that we've had working, vs just posts.

[pawkat]

I can't see the main query - https://prnt.sc/8-VQFJ0HQWZ3, https://prnt.sc/8vg1gn9C7OC9, https://prnt.sc/xZVv9p9rQ7SK, https://prnt.sc/sKwzLkoS2PRW, https://prnt.sc/_Esh9FDLd51N

[tw2113]

if you select the dropdown next to the "Caller" heading, one of those should be "Main Query". As you can see in your screenshots, there are often MANY queries for posts going on in various ways, including menus! among others.

[pawkat]

@tw2113 It's very strange, but I haven't "Main Query" option in the select https://prnt.sc/ofIbrlbtZUeC.

[tw2113]

hmm, not sure on that one then.

[pawkat]

@tw2113 in this case I can provide you access to the admin/ftp and you can see the query for example on pre_get_posts hook

[tw2113]

Please reach out at https://pluginize.com/contact/ and provide this issue link as part of the message so that we know what the ticket relates to: https://github.com/WebDevStudios/wp-search-with-algolia/issues/225

[pawkat]

done, I'll wait for response

[tw2113]

Responded there.

[aparun]

https://superstate.no/?s=lmnt - Results are 10 pages (Some of them are posts and some of them are products) https://superstate.no/?s=lmnt&post_type=post - Only posts but the results are still 10 pages

With post_type=post, there are fewer items because we do not see products now, but the search result count is the same. This is because even though products are not showing, they still take up space.

That's why we see only one item with post_type=post, on the first page. Because 8 of 9 items were not the post on the search result. (See the first screenshot) That's why on the 4th page you see 404, because, on the normal search results, there are not any posts on the 4th page. (It is now the 6th page)

When you filter the results with post_type=post, we must see 9 posts on the first page but we see 1 post. The other 8 items are products and they are not visible but they just take up space.

Screenshots for 1st page of search results: Search result: https://prnt.sc/G9aWEJva_2Vy Search result only post: https://prnt.sc/ckVz_kpFXwMn

Screenshots for 2nd page of search results: Search result: https://prnt.sc/8ATpzC2ppcn5 Search result only posts: https://prnt.sc/dA9-A_d1iZPR

[aparun]

I want to share a solution for this. It may be not the best solution but until they update the plugin, you may use it.

Because the problem is so annoying when you filter the results by post type.

For example:

You search "keyword" and 20 posts are found. 15 products, 5 posts.

On the first page, 10 products, and on the second page 5 products and 5 posts.

When you filter the results with post_type=post, you see 404 not found. Because there is not any post on the first page of results.

The first page of ?s=keyword&post_type=post is 404. But there are 5 posts found on the second page.

Now, the solution.

For backends search, the plugin uses wp_searchable_posts index.

So you can make an if statement to change this according to post type.

For example:

if ($post_type == 'product') { wp_posts_product } else { wp_searchable_posts }

I will explain here how to do it.

If you use another filter inside the product post type such as custom fields, you will encounter the same problem. Like:

url/?s=keyword&post_type=product (Search only inside products with wp_posts_product) but if you filter this results like:

url/?s=keyword&post_type=product&price=10,50

The same problem occurs. We see products that prices between 10-50, but the other products still take up space. I found a solution to this also. if there is a filter with price=, I use one page, so all results are showing. If you need, I can explain.

The solution:

The plugin uses wp_searchable_posts index for the backend.

In includes/class-algolia-settings.php there is a function.

public function get_native_search_index_id() {
        return (string) apply_filters( 'algolia_native_search_index_id', 'searchable_posts' );
    }

We create another function under it.

public function get_native_search_index_id2() {
        return (string) apply_filters( 'algolia_native_search_index_id', 'posts_product' );
    }

In /includes/class-algolia-plugin.php, we change this:

$index_id = $this->settings->get_native_search_index_id();
        $index    = $this->get_index( $index_id );

        if ( null === $index ) {
            return;
        }

        new Algolia_Search( $index );
    }

to this:

$index_id = $this->settings->get_native_search_index_id();
        $index    = $this->get_index( $index_id );

        if ( null === $index ) {
            return;
        }

        $index_id2 = $this->settings->get_native_search_index_id2();
        $index2    = $this->get_index( $index_id2 );

        if ( null === $index2 ) {
            return;
        }

        new Algolia_Search($index, $index2 );
    }

Now the index is all post types and index2 is only product post.

In includes/class-algolia-search.php

We change this

try {
            $results = $this->index->search( $query->query['s'], $params, $order_by, $order );
        } catch ( AlgoliaException $exception ) {
            error_log( $exception->getMessage() ); // phpcs:ignore -- Legacy.

            return;
        }

to this

global $wp_query;   
$post_type = get_query_var('post_type');   
if( $wp_query->is_search && $post_type == 'product' )   
        {   

        try {
            $results = $this->index2->search( $query->query['s'], $params, $order_by, $order );
        } catch ( AlgoliaException $exception ) {
            error_log( $exception->getMessage() ); // phpcs:ignore -- Legacy.

            return;
        }
    }
    else {
        try {
            $results = $this->index->search( $query->query['s'], $params, $order_by, $order );
        } catch ( AlgoliaException $exception ) {
            error_log( $exception->getMessage() ); // phpcs:ignore -- Legacy.

            return;
        }
}

Now, when you search normally, the results are coming from wp_searchable_posts index. But when you filter the results with post type and post type is the product, the results are coming from wp_posts_product which is only product items are indexed.

[pawkat]

Hello, I added the filter:

add_filter('algolia_native_search_index_id',
__CLASS__.'::algolia_native_search_index_id');

public static function algolia_native_search_index_id($search_index =
'searchable_posts')
    {
        $post_type = array_key_exists('post_type', $_GET) &&
$_GET['post_type'] ? $_GET['post_type'] : '';
        if (! $post_type) {
            return $search_index;
        }

        return "posts_{$post_type}";
    }

and now when we submit the form in the header we will be redirected to the page https://superstatedev.wpengine.com/?s=magnesium&post_type=product where we see only products, and when we submit the search form from the https://superstatedev.wpengine.com/blog/ (https://prnt.sc/LGg_x3baIDoa), we will be redirected to the https://superstatedev.wpengine.com/?s=lmnt&post_type=post and see only posts. Seems that all works as expected, could you also test it? Thank you so much!

ср, 24 авг. 2022 г. в 19:57, aparun @.***>:

I want to share a solution for this. It may be not the best solution but until they update the plugin, you may use it.

Because the problem is so annoying when you filter the results by post type.

For example:

You search "keyword" and 20 posts are found. 15 products, 5 posts.

On the first page, 10 products, and on the second page 5 products and 5 posts.

When you filter the results with post_type=post, you see 404 not found. Because there is not any post on the first page of results.

The first page of ?s=keyword&post_type=post is 404. But there are 5 posts found on the second page.

Now, the solution.

For backends search, the plugin uses wp_searchable_posts index.

So you can make an if statement to change this according to post type.

For example:

if ($post_type == 'product') { wp_posts_product } else { wp_searchable_posts }

I explained here https://wordpress.org/support/topic/wrong-search-count-with-post_type-search/#post-15946586 how to do it.

If you use another filter inside the product post type such as custom fields, you will encounter the same problem. Like:

url/?s=keyword&post_type=product (Search only inside products with wp_posts_product) but if you filter this results like:

url/?s=keyword&post_type=product&price=10,50

The same problem occurs. We see products that prices between 10-50, but the other products still take up space. I found a solution to this also. if there is a filter with price=, I use one page, so all result on the are showing.

— Reply to this email directly, view it on GitHub https://github.com/WebDevStudios/wp-search-with-algolia/issues/225#issuecomment-1225989894, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXMMQ5ZSMYKVAYZS5N2VYLV2ZH55ANCNFSM5365H4LQ . You are receiving this because you authored the thread.Message ID: @.***>

[aparun]

Hello, I added the filter: add_filter('algolia_native_search_index_id', CLASS.'::algolia_native_search_index_id'); public static function algolia_native_search_index_id($search_index = 'searchable_posts') { $post_type = array_key_exists('post_type', $_GET) && $_GET['post_type'] ? $_GET['post_type'] : ''; if (! $post_type) { return $searchindex; } return "posts{$post_type}"; } and now when we submit the form in the header we will be redirected to the page https://superstatedev.wpengine.com/?s=magnesium&post_type=product where we see only products, and when we submit the search form from the https://superstatedev.wpengine.com/blog/ (https://prnt.sc/LGg_x3baIDoa), we will be redirected to the https://superstatedev.wpengine.com/?s=lmnt&post_type=post and see only posts. Seems that all works as expected, could you also test it? Thank you so much! ср, 24 авг. 2022 г. в 19:57, aparun @.>: … I want to share a solution for this. It may be not the best solution but until they update the plugin, you may use it. Because the problem is so annoying when you filter the results by post type. For example: You search "keyword" and 20 posts are found. 15 products, 5 posts. On the first page, 10 products, and on the second page 5 products and 5 posts. When you filter the results with post_type=post, you see 404 not found. Because there is not any post on the first page of results. The first page of ?s=keyword&post_type=post is 404. But there are 5 posts found on the second page. Now, the solution. For backends search, the plugin uses wp_searchable_posts index. So you can make an if statement to change this according to post type. For example: if ($post_type == 'product') { wp_posts_product } else { wp_searchable_posts } I explained here https://wordpress.org/support/topic/wrong-search-count-with-post_type-search/#post-15946586 how to do it. If you use another filter inside the product post type such as custom fields, you will encounter the same problem. Like: url/?s=keyword&post_type=product (Search only inside products with wp_posts_product) but if you filter this results like: url/?s=keyword&post_type=product&price=10,50 The same problem occurs. We see products that prices between 10-50, but the other products still take up space. I found a solution to this also. if there is a filter with price=, I use one page, so all result on the are showing. — Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXMMQ5ZSMYKVAYZS5N2VYLV2ZH55ANCNFSM5365H4LQ . You are receiving this because you authored the thread.Message ID: @.>

I added the code in functions.php but got an error:

Parse error: syntax error, unexpected 'public' (T_PUBLIC), expecting end of file in /var/www/html/wp-content/themes/my-theme/functions.php on line 853

The line is: public static function algolia_native_search_index_id($search_index =

[pawkat]

Just I use this in the PHP class, you can add in the next way:

add_filter('algolia_native_search_index_id', function ($search_index = 'searchable_posts') { $post_type = array_key_exists('post_type', $_GET) && $_GET['post_type'] ? $_GET['post_type'] : ''; if (! $post_type) { return $search_index; }

return "posts_{$post_type}";

});

пт, 26 авг. 2022 г. в 12:11, aparun @.***>:

Hello, I added the filter: add_filter('algolia_native_search_index_id', CLASS.'::algolia_native_search_index_id'); public static function algolia_native_search_index_id($search_index = 'searchable_posts') { $post_type = array_key_exists('post_type', $_GET) && $_GET['post_type'] ? $GET['post_type'] : ''; if (! $post_type) { return $search_index; } return "posts{$post_type}"; } and now when we submit the form in the header we will be redirected to the page https://superstatedev.wpengine.com/?s=magnesium&post_type=product where we see only products, and when we submit the search form from the https://superstatedev.wpengine.com/blog/ (https://prnt.sc/LGg_x3baIDoa), we will be redirected to the https://superstatedev.wpengine.com/?s=lmnt&post_type=post and see only posts. Seems that all works as expected, could you also test it? Thank you so much! ср, 24 авг. 2022 г. в 19:57, aparun @.

>: … <#m4513945269989636445> I want to share a solution for this. It may be not the best solution but until they update the plugin, you may use it. Because the problem is so annoying when you filter the results by post type. For example: You search "keyword" and 20 posts are found. 15 products, 5 posts. On the first page, 10 products, and on the second page 5 products and 5 posts. When you filter the results with post_type=post, you see 404 not found. Because there is not any post on the first page of results. The first page of ?s=keyword&post_type=post is 404. But there are 5 posts found on the second page. Now, the solution. For backends search, the plugin uses wp_searchable_posts index. So you can make an if statement to change this according to post type. For example: if ($post_type == 'product') { wp_posts_product } else { wp_searchable_posts } I explained here https://wordpress.org/support/topic/wrong-search-count-with-post_type-search/#post-15946586 https://wordpress.org/support/topic/wrong-search-count-with-post_type-search/#post-15946586 how to do it. If you use another filter inside the product post type such as custom fields, you will encounter the same problem. Like: url/?s=keyword&post_type=product (Search only inside products with wp_posts_product) but if you filter this results like: url/?s=keyword&post_type=product&price=10,50 The same problem occurs. We see products that prices between 10-50, but the other products still take up space. I found a solution to this also. if there is a filter with price=, I use one page, so all result on the are showing. — Reply to this email directly, view it on GitHub <#225 (comment) https://github.com/WebDevStudios/wp-search-with-algolia/issues/225#issuecomment-1225989894>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXMMQ5ZSMYKVAYZS5N2VYLV2ZH55ANCNFSM5365H4LQ https://github.com/notifications/unsubscribe-auth/AGXMMQ5ZSMYKVAYZS5N2VYLV2ZH55ANCNFSM5365H4LQ . You are receiving this because you authored the thread.Message ID: @.>

I added the code in functions.php but got an error:

Parse error: syntax error, unexpected 'public' (T_PUBLIC), expecting end of file in /var/www/html/wp-content/themes/my-theme/functions.php on line 853

The line is: public static function algolia_native_search_index_id($search_index =

— Reply to this email directly, view it on GitHub https://github.com/WebDevStudios/wp-search-with-algolia/issues/225#issuecomment-1228256124, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXMMQ75IDLKH4VHNUQBRUDV3CC4JANCNFSM5365H4LQ . You are receiving this because you authored the thread.Message ID: @.***>

[aparun]

Just I use this in the PHP class, you can add in the next way: add_filter('algolia_native_search_index_id', function ($search_index = 'searchable_posts') { $post_type = array_key_exists('post_type', $_GET) && $_GET['post_type'] ? $_GET['post_type'] : ''; if (! $post_type) { return $searchindex; } return "posts{$post_type}"; }); пт, 26 авг. 2022 г. в 12:11, aparun @.>: … Hello, I added the filter: add_filter('algolia_native_search_index_id', CLASS.'::algolia_native_search_index_id'); public static function algolia_native_search_index_id($search_index = 'searchable_posts') { $post_type = array_key_exists('post_type', $_GET) && $_GET['post_type'] ? $GET['post_type'] : ''; if (! $post_type) { return $search_index; } return "posts{$post_type}"; } and now when we submit the form in the header we will be redirected to the page https://superstatedev.wpengine.com/?s=magnesium&post_type=product where we see only products, and when we submit the search form from the https://superstatedev.wpengine.com/blog/ (https://prnt.sc/LGg_x3baIDoa), we will be redirected to the https://superstatedev.wpengine.com/?s=lmnt&post_type=post and see only posts. Seems that all works as expected, could you also test it? Thank you so much! ср, 24 авг. 2022 г. в 19:57, aparun @. >: … <#m4513945269989636445> I want to share a solution for this. It may be not the best solution but until they update the plugin, you may use it. Because the problem is so annoying when you filter the results by post type. For example: You search "keyword" and 20 posts are found. 15 products, 5 posts. On the first page, 10 products, and on the second page 5 products and 5 posts. When you filter the results with post_type=post, you see 404 not found. Because there is not any post on the first page of results. The first page of ?s=keyword&post_type=post is 404. But there are 5 posts found on the second page. Now, the solution. For backends search, the plugin uses wp_searchable_posts index. So you can make an if statement to change this according to post type. For example: if ($post_type == 'product') { wp_posts_product } else { wp_searchable_posts } I explained here https://wordpress.org/support/topic/wrong-search-count-with-post_type-search/#post-15946586 https://wordpress.org/support/topic/wrong-search-count-with-post_type-search/#post-15946586 how to do it. If you use another filter inside the product post type such as custom fields, you will encounter the same problem. Like: url/?s=keyword&post_type=product (Search only inside products with wp_posts_product) but if you filter this results like: url/?s=keyword&post_type=product&price=10,50 The same problem occurs. We see products that prices between 10-50, but the other products still take up space. I found a solution to this also. if there is a filter with price=, I use one page, so all result on the are showing. — Reply to this email directly, view it on GitHub <#225 (comment) <#225 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXMMQ5ZSMYKVAYZS5N2VYLV2ZH55ANCNFSM5365H4LQ https://github.com/notifications/unsubscribe-auth/AGXMMQ5ZSMYKVAYZS5N2VYLV2ZH55ANCNFSM5365H4LQ . You are receiving this because you authored the thread.Message ID: @.> I added the code in functions.php but got an error: Parse error: syntax error, unexpected 'public' (T_PUBLIC), expecting end of file in /var/www/html/wp-content/themes/my-theme/functions.php on line 853 The line is: public static function algolia_native_search_index_id($search_index = — Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXMMQ75IDLKH4VHNUQBRUDV3CC4JANCNFSM5365H4LQ . You are receiving this because you authored the thread.Message ID: @.>

Wow, thank you so much!

Now when I filter post type with post_type=post (or product), it exactly works as expected. Only shows that post type.

I have only one problem with custom field filters.

For example, I have a custom field called "days". I filter products with this.

url/s=keyword&post_type=product&days=1,4

Here I have the same problem. Only products whose days field between 1 and 4 are showing. No problem, but the other products (that are found in the search query) take up space just as I explained before. So if there is not any product with days 1,4 on the first page result of url/s=keyword&post_type=product, they do not show up on url/s=keyword&post_type=product&days=1,4. They show up on url/page/2/s=keyword&post_type=product&days=1,4

The temporary solution to this is if there is a custom field filter, I set the total post -1, so all posts are showing on one page.

Like:

$endofurl = '';
        if ( isset( $_GET['days'] ) ) {
            $endofurl = $_GET['days'];
        }

if ($endofurl !== '') {
         $query->set( 'posts_per_page', -1 );
         } else {
         $query->set( 'posts_per_page', $params['hitsPerPage'] );
         }

[tw2113]

@aparun are you able and willing to make a pull request with all the changes, so that we can better review it?

[tw2113]

@pawkat I know it's been a long time, but this is still a bit on my mind.

Have you found a working solution for this? Or is it still an ongoing issue that you've just kind of left as is reluctantly?

[tw2113]

So I've been digging in to this topic.

We have the algolia_search_params filter found at class-algolia-search.php in 2.6.1.

This filter can be used to amend the search parameters before they're sent to Algolia.

Available parameters for the array shown, including attributesToRetrieve and the like can be found at https://www.algolia.com/doc/api-reference/search-api-parameters/

In terms of our original issue above, the most important parameter is going to be the filters parameter. You can read more about this specific parameter at https://www.algolia.com/doc/api-reference/api-parameters/filters/

Based on all of my testing, adding a filters parameter that's set to post_type:my_post_type allowed for filtering down to just "my_post_type". I tested this out by making a query for a value that's indexed in multiple post types in my index. Once I set for a specific post type, only that one type came back.

function algolia_example_filter_search_params( $params ) {
    $params['filters'] = 'post_type:page';
    return $params;
}
add_filter( 'algolia_search_params', 'algolia_example_filter_search_params' );

As per Algolia's own documentation, you will need to make this edit for your index's settings:

You must declare for each attribute you use as a filter in attributesForFaceting, except for _tags, which are automatically considered as attributesForFaceting

Because of this, I feel like this filter could be considered potentially the Algolia equivalent for pre_get_posts specific to the Algolia search request.

This is going to be much better and appropriate than trying to alter/amend what indexes are being searched through, as is demo'd above in previous conversation

[pawkat]

@tw2113 I can't remember all history of this, but now it's fixed. I have the code in my theme: add_filter('algolia_native_search_index_id', CLASS.'::algolia_native_search_index_id'); public static function algolia_native_search_index_id($search_index = 'searchable_posts') { $post_type = array_key_exists('post_type', $_GET) && $_GET['post_type'] ? $_GET['post_type'] : ''; if (! $post_type) { return $search_index; }

    return "posts_{$post_type}";
}

[tw2113]

Based on reading everything above, and my findings from last week, you're essentially changing the index to search instead of filtering the content type. I definitely understand not wanting to change something that's working, but I believe my info in https://github.com/WebDevStudios/wp-search-with-algolia/issues/225#issuecomment-1741373480 would be more advantageous as it'd prevent needing to maintain settings for so many different indexes/configurations.

Just some thoughts. That said, I'm going to close this ticket.