Multisite, CPTs, and Autocomplete

  • Resolved erc

    (@erc)


    3 years, 1 month ago

    First, I want to say thank you for this incredible plugin, and thank you for supporting/maintaining it!

    I have a Multisite network with about a dozen subsites, and although it’s all one cohesive website (from a design and content perspective), there are instances where only one of the subsites include a particular Custom Post Type.

    WP Search with Algolia is activated on every subsite, and the same prefix is used for all indices. This means that as long as the CPT is available on every subsite (Pages, Posts) the plugin returns results as expected, network-wide.

    The problem comes where a single subsite has a CPT enabled (say, an Events CPT or a Products CPT). It doesn’t seem possible from within the plugin to allow results from those indices to be returned from the main site’s autocomplete… The UI where you choose which CPTs to use in the autocomplete can only list the CPTs for the current subsite.

    I guess my question is whether there’s some programmatic way to dictate a list of indices that could supersede the Autocomplete options for the plugin.

    Sorry for writing a book, hopefully that’s clear!

    • This topic was modified 3 years, 1 month ago by erc.
Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    3 years, 1 month ago

    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.

    Thread Starter erc

    (@erc)

    3 years, 1 month ago

    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 3 years, 1 month ago by erc.
    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    3 years, 1 month ago

    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.

    Thread Starter erc

    (@erc)

    3 years, 1 month ago

    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.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    3 years, 1 month ago

    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

    Thread Starter erc

    (@erc)

    3 years, 1 month ago

    Marking as resolved

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Multisite, CPTs, and Autocomplete’ is closed to new replies.