Michael Beckwith

So, yes, you are making use of algolia_excluded_post_types filter, but one thing I think we need to do with better clarifying is that filter is specifically for the autocomplete page and those settings.

If you check out https://github.com/WebDevStudios/wp-search-with-algolia/wiki/Filter-Hooks there’s a section for the Search page settings/Instantsearch, for which I’ve pasted the intended filter example below.

<?php
function my_exclude_searchable_custom_post_type( array $post_types ) {
    if ( array_key_exists( 'custom_post_type', $post_types ) ) {
        unset( $post_types['custom_post_type'] );
    }

    return $post_types;
}
add_filter( 'algolia_searchable_post_types', 'my_exclude_searchable_custom_post_type' );

As per one of the notes there:

With this hook, we’ve already fetched all the post types that have exclude_from_search set to false, so we need to remove instead of add.

You’ll want to update the custom_post_type part to match which you want to exclude, and repeat as necessary. Alternatively if you know exactly which post type you want, you could have the filter return something like this, for example just have it index the page post type.

return [ 'page' => 'page' ];

Regarding the indexing/not indexing part your exclusion function may be best done as such

function algolia_exclude_extra( $should_index, $post ) {
    // Check if the post type is 'page'
    if ( in_array( $post->post_type, [ 'page' ] ) ) {
        // Check if the post belongs to the 'Services' category
        if ( ! has_category( 7, $post ) ) {
            // Exclude the post from being indexed
            return false;
        }
    }
    
    // Allow indexing for all other cases
    return $should_index;
}
add_filter( 'algolia_should_index_searchable_post', 'algolia_exclude_extra', 10, 2 );
add_filter( 'algolia_should_index_post', 'algolia_exclude_extra', 10, 2 );

From your original version, it looks like the return $should_index line was never getting reached, because your else clause also returned false.

• This reply was modified 9 hours, 30 minutes ago by Michael Beckwith.

Which search version do you have configured presently? I’m not seeing hints of Instantsearch so I’m suspecting it’s the “Use with Native Search Template.”

Have you checked and verified that the wp_searchable_posts index in your Algolia dashboard has records in it?

Good day @jinsley8,

So there’s two components. If you’re using the Instantsearch integration, we have a searchbox in place in the templates for that already.

Example lines from our template:

• https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/templates/instantsearch.php#L109-L116
• https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/templates/instantsearch.php#L19
• Widget docs: https://www.algolia.com/doc/api-reference/widgets/search-box/js/

For the Autocomplete integration, we still presently ship with Autocomplete version 0.38.x which we are able to automatically bind to majority of any theme’s built in search field. We’re able to attach by way of the <input name="s" /> input types which tie in to WordPress’ search system with that name attribute.

One of the reasons why we have yet to attempt upgrading Autocomplete to version 1.x yet, is because we lose that automatic binding ability. This is because with the newer Autocomplete, their code expects to just be provided a <div id="autocomplete"></div> container and they handle the rest of the binding for the Autocomplete integration.

If you’re hoping for/looking for a Full Site Editor solution, as opposed to a more classic theme that everything above applies to, I know we have this github ticket open https://github.com/WebDevStudios/wp-search-with-algolia/issues/216

I did some testing at the time and came up with what I have posted at https://www.ads-software.com/support/topic/customize-instantsearch-php-with-fse-theme/#post-17319232

Overall, yes, but we can’t modify that SearchConfig.php file as that’s part of the composer package for the Algolia Search client.

That said, I know we have https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/factories/class-algolia-search-client-factory.php#L60-L86 where we’ve previously customized some details for the search config, and I believe we should be fine with adding in more conditionals. Perhaps we should even fill in all the missing items from https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/vendor_prefixed/algolia/algoliasearch-client-php/src/Config/SearchConfig.php#L25-L39

Worth trying out in adding your values in the the class-algolia-search-client-factory.php around line 85 just to help confirm that things take like needed. If yes, then we can get an issue opened and a PR in place to fill in the missing config options.

Definitely understood. Thanks.

Any news or changes here @teddtucker ?

Just wanting to see if there’s any news or changes on this front.

Any news or changes here?

This got resolved in the Github issue linked, and solutions provided there.

Assuming you’re good with it, that would remove the automatic integration with the original search field. If you ideally want it working in both, you’d want to amend the selector to include both.

If you’re referring to Autocomplete, I know we have the algolia_autocomplete_input_selector filter which defaults to a javascript selector value of "input[name='s']:not('.no-autocomplete')" seen at https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/class-algolia-template-loader.php#L86

If you’re referring to backend search, then I believe you’re going to need to make the algolia_should_filter_query WP filter return true, and that can be seen at https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/class-algolia-search.php#L76-L92 where it defaults to the evaluated value of $should_filter = ! $query->is_admin && $query->is_search() && $query->is_main_query();

Should I contact the theme’s author…

This is definitely going to be the best route as this topic isn’t a “custom supports” topic/field setting, it’s all dependent on what post types the theme registers their metaboxes and whatnot for. It’s possible that they don’t have things built out to also include these in your screenshot on post types that they can’t predict existing. Thus why many themes that have options to add in their options/builders/etc to post types that they can at least get listed out and offer checkboxes for to include.

Hi @jubbling

I have a **hunch** that you’re using JupiterX theme and/or core plugin. From what I’m seeing, they have a setting at /wp-admin/admin.php?page=jupiterx#/settings#post-types that you can use to enable more settings and such for other post types. From what I’m seeing in their core code, they default to just post, page, and portfolio.

<small>Enable Jupiter X features (Customizer, Meta options, etc.) for these post types.</small>

Worth checking out for sure, to see if that gets those screen options added to the post types.

Not really an issue that would somehow be solved from an update to WP Search with Algolia.

What code examples have you tried? Did you make sure to make the language code an attribute that’s being indexed as well as made it an attribute for faceting/filtering?

Based on my experiences, I believe it’d still return 1 result.