I'm able to successfully pull in a referenced value and save it to the database for a given node, but when I go back to edit the page, the value doesn't show in the autocomplete field anymore.
I tracked this down to these lines:
// If the language is set and not null add it as a query param.
if (isset($language->language) && $language->language != 'und') {
$field_query[] = 'ss_language: ' . $language->language;
}
The entity is set with the ss_language value set to 'und' but my default language is 'en' as defined in language_default().
So it's searching for a value of 'en' instead of 'und'.
I'm not using translation of any kind, so I'm not sure what the best solution is. I think you can change the query to search for the defined language OR 'und' like this:
// If the language is set and not null add it as a query param.
if (isset($language->language) && $language->language != 'und') {
$field_query[] = 'ss_language: "' . $language->language . '" OR "und"';
}
But I'm not sure if that would mean that if you did have both 'und' and 'en' values that sometimes you'd get 'und' and sometimes you'd get 'en' or what.
Alternatively, you can compare the language on the requesting entity with the given language, and if they're the same, don't bother with checking ss_language at all. That's what I'm attempting to do with the attached patch.
I'm definitely not sure this is the correct method though.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2404933-use_entity_language_on_query_2.patch | 4.26 KB | mikemiles86 |
| #1 | apachesolr_reference-language_undefined-2404933-1.patch | 1.83 KB | mariacha1 |
Comments
Comment #1
mariacha1 commentedHere's the patch.
Comment #2
mikemiles86@mariacha1
I understand the issue you have run into, but I have not been able to replicate 100% myself. However I think you've raised a valid point around detecting language and passing it as part of the solr query.
The module should be using the language of the entity instead of the site language, and if there is no language (LANGUAGE_NONE) then it should not be passed at all.
I have written a patch which will set the language based on the node language. My environment still works, so it does not break anything that was existing. Can you test in your environment and see if it resolves the issue?
Comment #3
mikemiles86Comment #4
mariacha1 commentedYep, that worked for me. Thanks!
Comment #6
mikemiles86Patch resolves issue. rolled into the 7.x-1.x branch and will be included in the next release.
Comment #7
mikemiles86