Open designzwang opened 2 years ago
Hey @designzwang, I think this should be possible, just a matter of getting the prefix/index set properly, but I'm also double checking.
What's the index name(s) that you're using presently?
Hello @tw2113 , thanks for checking this request! I am a bit hesitant to post the index name publicly, actually it is just a string containing the site name and some numbers. I set up the plugin with the respective API Keys, and the connection to algolia was OK ("We succesfully managed to connect to the Algolia servers with the provided information.") But since there is only one field for index prefixes I could not continue. Since I don't know how the plugin works under the hood I did not want to let it "do things" with the Admin key of our production environment :-) I'd better create a new algolia account , using the free version, for this type of experiment ...
I guess the plugin would create and use multiple indexes, right? So I thought about a workaround where I would let it do its work and then simply rename my "global" index to match one of the names the plugin expects. Would that work?
I just became aware that there is a wiki section with docs about extending the plugin, so I will also have a look there. A pointer where or what too look for wold be helpful though ;)
Thanks, Ulrich
Multiple indices are definitely possible as a whole, thanks to that prefix
field, but the other parts of the resulting indexes tend to be more hardcoded.
Picture of some of my indexes in a test install that I use the plugin with.
Some of the prefixes I used are "wdssupport", "wpmain", and one with a default "wp_". The parts that aren't the prefixes are the hardcoded parts. Part of me want to see how close your indexes may have been to these examples, but sounds like probably not close at all.
My index name is not "close" at all - i.e. it does not match any of the hardcoded names or the prefix. Meanwhile I set up a free algolia accout to use as a testing sandbox and will try how things work out in the next couple of days.
Sounds good.
I did open https://github.com/WebDevStudios/wp-search-with-algolia/issues/241 for consideration to help with this.
Hi @tw2113, meanwhile I have connected my demo/sandbox index to the plugin and have tried to let my external crawler fill the index that was created by the plugin ( PREFIX_searchable_posts). Since the object attributes ("fields") that our crawler uses are completely different from the ones the plugin has, I was not really successful. The autocomplete search found some results ( 1660 in this case) The demo is on an internal network, so I can't not show it publicly, but here is a screenshot:
The additional attributes seem to choke the result display which remains empty. Console shows "Uncaught (in promise) TypeError: data.images is undefined"
I guess it would require too much work to extend the plugin to handle arbitrary indexes with different fields/attributes, so we will probably use our crawler in combination with the ready-to-run javascript widgets from algolia for both the search box and result page.
@designzwang
This sounds more like our out-of-box templates aren't matching up with the attributes that are being pushed in to the indexes.
In that section, you can see all the extra attributes we're including and getting data for. data.images
would be coming from line 220.
Meanwhile, with the autocomplete, we try to reference that spot at line 23 here:
https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/templates/autocomplete.php#L22-L24
So, for your case, you'd need to update the template files to match all the properties/attributes you're saving, and reference them appropriately. very likely through the data
main js object. You can inspect that object with <# {{ console.log(data) }} #>
inside the <script type="text/html" ...>
tags found in the templates.
@tw2113 Thanks for this pointer, I'll have a look at it!
As an example, I got Autocomplete customized for indexes, outside of the ones created by the plugin, using the following example code
function add_custom_index( $config ) {
$config[] = [
'enabled' => true,
'index_id' => 'Product Feed',
'index_name' => 'Product Feed',
'max_suggestions' => 5,
'position' => 11,
'tmpl_suggestion' => 'autocomplete-feed-suggestion',
'admin_name' => 'Product Feed',
'label' => 'Product Feed',
];
return $config;
}
add_filter( 'algolia_autocomplete_config', __NAMESPACE__ . '\add_custom_index' );
Hi,
Additional context We are migrating from a different CMS to Wordpress. The old site search is already using Algolia ( index filled by crawling the site via HTTP) This is why we were researching Algolia/WP integration and found this plugin to be the best starting place. The important thing is - our index contains additional URLs/content from other sources outside the CMS and this is still needed in the future. So for a complete site search we need to query our "global" index, and so far we have never been using more than one index.
Is your feature request related to a problem? Please describe. I would like to use an existing algolia index as the source for the searches instead of using the plugins built-in indexing or in addition to the built-in indexes.
Describe the solution you'd like If there is an existing Algolia index, it would be great if the search functionality and integration into WP search pages that this plugin already has, could be used for searching on an existing index ( i.e. having config options for the name of the index to be used and then using this index as an additional source or even as the only source)
Describe alternatives you've considered We could continue to use our old existing javascript-based search frontend that is using the existing index , which would mean we would have to integrate it into the theme and continue crawling the site instead of directly indexing the contents. The second alternative would be to build a custom plugin based on Algolias samples for WP integration, however using your plugin would of course benefit from the integration into the search pages being already done.
So - would this be possible by extending this plugin? If the plugin already has hooks/filters that would help doing this, I would appreciate any pointers ... or other possible workarounds you might come up with
Regards, Ulrich