Multisite, CPTs, and Autocomplete

Interesting use case here, especially with the pooling of everything into one index, if I’m reading things correctly.

It does have me wondering if it would be better to let them have their own dedicated indexes, but searching still queries from all. I say this because out of box, the plugin relies on post IDs to be the unique object ID identifier, and given that each site in a network gets their own posts tables, there’s definitely risk of content clashing. For example say you retained the “Sample page” in multiple subsites, and those sample pages always have post ID 2. You update Site 1 to have that page be repurposed as an “About” page, and then site 4 gets it repurposed as a “Contact” page. The “object ID 2” in your Algolia index would end up going back and forth between which page it represents.

That said, without going further into any discussion about what’s probably best practices, I want to check and see if you can find the example post type content in the index already? Did it get pushed into the index? If you’re not finding it, perhaps try editing a post in the post type, and see if that individual post gets pushed up, as the plugin should be self maintaining of the index. However, I’m wondering if maybe my object ID collision above may be playing a part here as well.

As long as the content item is in the index, I have to believe it’d be available for the Autocomplete usage, regardless of its original source.

I just ran across a post of yours on github where you recommended separate prefixes for each subsite for that reason. I will make that change, that makes sense.

The posts from the CPTs in question are included in the Index, and they are correctly returned with Autocomplete as long as you’re using the search form on a subsite where the CPT in use.

If I understand the settings properly, this is because the plugin’s Autocomplete settings includes a list of CPTs available on the current site. On the Main site, for example, there is no Events CPT in use, and so there is no checkbox to enable Events for Autocomplete. Therefore, the Main site’s search input doesn’t return Events.

On the Events subsite, there is an Events CPT, and in the Autocomplete settings Events can be checked to enable. The search input on the Events subsite returns those results just fine.

• This reply was modified 1 year, 8 months ago by erc.

The posts from the CPTs in question are included in the Index, and they are correctly returned with Autocomplete as long as you’re using the search form on a subsite where the CPT in use.

I wonder if that’s a template level detail in this case, specifically probably https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/templates/autocomplete.php#L102-L103

I suspect you could force an entire list of config indexes with https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.4.0/includes/class-algolia-autocomplete-config.php#L175-L193 even if it was a bit of a hardcoded array that gets returned, including enabled status and position.

Thank you for pointing me in the right direction.

Having different prefixes for each subsite will mean the number of indices will increase by quite a bit, so it might be tricky to manage all of them manually.

Or maybe we can take the approach that we just need to identify the oddball indices associated with these particular CPTs, and manually add those to the existing array.

I don’t suspect there’s going to be “one right way” here, since Algolia Search as a whole can be pretty flexible with enough finesse

Marking as resolved