Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The changes in #3136510: Incorrect notice language specific field types missing broke the Portuguese language files again. They had been fixed previously in #3091574: Dynamic solr field type check encodes special characters.
So, we need to replace dashes with underscores in the case of zh-hans and zh-hant, but not in the case of pt-pt and pt-br. Not sure what the best way to solve this is. Maybe change the config like was done for Portuguese in #3087744: Update the Portuguese config to use the langcodes used by Drupal, or to change the line now committed from
$solr_field_type_name = 'text' . '_' . str_replace('-', '_', $language->getId());
to
$solr_field_type_name = 'text' . '_' . str_replace('zh-han', 'zh_han', $language->getId());
Comment | File | Size | Author |
---|---|---|---|
#14 | 3154019_complete.patch | 167.31 KB | mkalkbrenner |
Comments
Comment #2
mkalkbrennerI'm not sure about this.
Our tests use "de-at" which will be converted to "de_at"
See https://lucene.apache.org/solr/guide/8_5/defining-fields.html
So it is correct that we convert all language identifiers. One issue is that the comment is misleading and should not just mention "zh-*" as example.
So if there's an issue with "pt-*" the bug must be something else.
Comment #3
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedIn that case, the solution to #3087744: Update the Portuguese config to use the langcodes used by Drupal was wrong since it specifically added
text_pt-pt
and nottext_pt_pt
. Same for pt-br.See:
And compare with https://git.drupalcode.org/project/search_api_solr/-/blob/4.x/config/opt...
Comment #4
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedRunning
grep -R "name: text_" . | grep -v unstemmed | grep -v phonetic | grep -v spell | grep -v "text_..$"
on the config/optional directory results in the following lines that are the only ones affected by this 'bug':Comment #5
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedComment #6
mkalkbrennerThe config names are correct!
The conversion has to happen for the resulting field names in the Solr index.
Can you post your schema_extra_fields.xml?
Comment #7
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedgrep text_ schema_extra_types.xml:
Comment #8
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedAnd this is grepping the output of
drush --pipe solr-gsc localhost > lala.zip && unzip -p lala.zip | grep "text_pt"
Comment #9
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedIf the config names are correct, we need the code fix in the issue summary, as we can't have 'text_pt-pt' be replaced with 'text_pt_pt' in that case.
But if "Field names should consist of alphanumeric or underscore characters only", then those config names can't be right.
Comment #10
mkalkbrennerNo, the field names are correctly encoded. Everything you posted here of the the XML files is correct.
Comment #11
mkalkbrennerI think I got it. Working on a patch and a test ...
Comment #12
mkalkbrennerFirst of all it isn't a critical issue as search basically works.
But while reading the code, I noticed that a lot of edge cases are involved that could all lead to have that warning persisting. You'll see it in the patch, hopefully tomorrow.
Comment #13
mkalkbrennerIt turned out that a bigger patch is required. There might be different reasons why the warning persists. I hope that I captured all of them.
The patch is not final. The status report page still requires more testing and the update hook needs to take care about the new "pt" configs.
I think we should simply entirely overwrite the exists ones instead of updating them. What do you think?
Comment #14
mkalkbrennerI completed the update hook and updated the jump-start config-sets.
@jcnventura could you test the patch?
Comment #16
mkalkbrennerI mark it as fixed. But feedback is welcome!
Comment #17
jcnventura CreditAttribution: jcnventura at 1xINTERNET commentedYes, works perfectly fine. Thanks for fixing this. Even while it started looking like a minor issue, it clearly led to some major refactoring!