Closed thekenshow closed 1 year ago
See that code snippet you have there that is passing the index named crawl
? you just need to change that to the name of your indexes. As you have multilanguage and the format of your indexes is crawl-[LANG]-troylfs
based on your CLI output, you would need to add a variable in it so something like:
{% set index_name = 'crawl-' ~ grav.language.getActive ~ '-troylfs' %}
{% include 'partials/algolia-pro/instantsearch.html.twig' ignore missing with { index: index_name } %}
HI, thanks for the quick response. I've applied that change (more verbose because grav.language.getActive doesn't return the default language in a Gantry particle).
{% if grav.language.getActive == '' %}
{% set lang = 'en' %}
{% else %}
{% set lang ='fr' %}
{% endif %}
{% set index_name = 'crawl-' ~ lang ~ '-troylfs' %}
{% include 'partials/algolia-pro/instantsearch.html.twig' ignore missing with { index: index_name } %}
On my dev site(7.3.3) I'm getting "Undefined index: crawl-fr-troylfs" and "Undefined index: crawl-en-troylfs".
After pushing this change to my staging site (7.4.33), which is directly online, I'm getting "TypeError Return value of Grav\Plugin\AlgoliaProPlugin::getIndexConfiguration() must be of the type array, null returned"
Apologies, i gave you bad advice :) I was going on an implementation I had done for a client project that used the Algolia JS API directly, not using the InstantSearch/Twig system we use in Algolia Pro by default.
The name of the index is the configuration name, not the actual Aloglia index name.
Grav comes with crawl
and pages
by default, it should be just the crawl
you had previously. it should be able to automatically reconstruct the correct Algolia index name based on the language. Im not sure why it's not working for you as it is doing this on the https://learn.getgrav.org site without anything custom
Ah. I've reset back to where I was, and I'm getting consistent EN results on dev and staging. This isn't good, because I can't test the Algolia indexing because it seemed yesterday that when I indexed the FR content with the CLI, that took over search for both the main (EN) and FR sites. Those are live as of today because I assumed this was a configuration issue.
Where does the decision get made for which index to use? Is that in the Algolia Por plugin? Where do the languages to be indexed get determined?
Also, I don't see any language selection on learn.getgrav.org, and the <html>
element has lang="17"?
You have to be in the other language to search for it.. so /fr
in your URL, then it should use the french version
Yes, I get how the language selection works for the site. You can test the FR site at https://troylfs.com/fr, and the EN at https://troylfs.com.
I remembered the keyboard shortcut to activate the search, so I can work on the side to work without exposing it to FR visitors (search button is hidden).
I've reindexed Algolia Search from the production site just now, and showed 24 records:
But when I log into the Algolia site, the crawl-fr-troy
index is empty:
I ran a separate CLI command to index just the FR site, but it made no difference. Still no records there.
Querying the EN index with CLI returns results, same for the EN Web UI search:
Querying the FR index with CLI returns nothing:
How can the indexing succeed, report the number of records created, but nothing is actually done?
Disable smart indexing during testing and development. The clear grav cache.
Success! Thanks.
I have few questions:
FYI: There are a couple terms missing from Algolia's language.yaml file (circled red in image below).
BTW, you will see many more records coompared to pages. Algolia has a limit on how much content can fit into a record, so we have to "Chunk" up content from a single page so that 1 page may actually consist of any number of records depending on content length.
NOTE: This behavior is quite common and actually very useful. We use it to allow us to show results from within a page, an even provide links that jump to closest headers to that content you search for.
Thanks for these details, very useful. I'll manage my dev/stage/prod indexes more carefully going forward.
Hi, I got the same error in a project with multiple languages (in my case only in production environment). After reading the code I just found the error was about. This error is about caching the configuration without separating by active language. If see the first image below, when there is no configuration in the cache, the plugin will call the function responsible to bring the configuration and after this save it in the cache. However, if you look at second image you see that there is a line that will set the lang option. That's the bug, the first time we go to some page(clear the cache first) it will get the active lang and create the configuration and cache it, after this any page will consume the configuration from the cache independently the language. To resolve this(as a suggestion), we need pass the lang in the $options before we call those methods(see third image).
Note: The version I got the error is 3.2.0 but even updated the plugin the error wasn't fixed.
@rhukster, sorry to bump this one - @felipedasilva is my colleague and although this is issue is closed it indeed is a problem for us and seems like the same root cause as the one of @thekenshow. Maybe it is worth re-opening or maybe you just want to use the bugfix @felipedasilva for releasing a new version? We can confirm that this fixed our issue on production. Thanks a lot!
I'm back from vacation now. I'll take a look at this as soon as I can.
btw, had a quick look through your fix, and it actually looks pretty good to me.. the only minor change i'll make the logic to caclulate the language:
if ($language->enabled()) {
$options['lang'] = $language->getLanguage();
}
already does the check for active and falls back to default.
released 1.0.9. Seems 1.0.8 never got published either so might. jump from 1.0.7 -> 1.0.9
FYI found a couple more multilang issues and fixed them in last releases. Should be better now via admin where those problems manifested.
Found a few more multilang issues. Should be good now.
I have a Grav v1.7.39.4 site with latest plugins and have just expanded an EN site to a bilingual EN/FR site. When I index the site using the CLI, it creates separate indeces:
But when I use the front-end search, both sites return FR results.
I can query language-specific results with the CLI, for example:
How do I specific the search language in my site configuration or templates?
I tried modifying the Twig above to specify
{ index: 'crawl-en-troylfs' }
but that blew up the site.The only reference to "lang" in the front or back end docs is some code in Adding custom CLI Index Options (advanced).