could not update term that is created by feeds

“Thanks for filing a bug report. It would save me time in trying to replicate this issue if you can provide an export of your configuration + a sample source file. I had cases in the past where the issue turned out to be a configuration error and these are hard to replicate.
Can you provide the following:

The source file you were trying to import (may also be a sample file, as long as that sample file can demonstrate the problem).
An export of your configuration, packed inside a feature module, which includes:
The Feed type;
The content type selected on the processor;
Fields used on your content type;
Field storage items of your fields;
Optionally other configuration that is related.
If you want to be sure that I can install your configuration, try to enable the created feature module on a clean install.”

“Thanks for filing a bug report. It would save me time in trying to replicate this issue if you can provide an export of your configuration + a sample source file. I had cases in the past where the issue turned out to be a configuration error and these are hard to replicate.
Can you provide the following:

• The source file you were trying to import (may also be a sample file, as long as that sample file can demonstrate the problem).
• An export of your configuration, packed inside a feature module, which includes:
  • The Feed type;
  • The content type selected on the processor;
  • Fields used on your content type;
  • Field storage items of your fields;
  • Optionally other configuration that is related.

If you want to be sure that I can install your configuration, try to enable the created feature module on a clean install.”

Just pasted in the code version of our "requesting more info" response so you can see it better and the features module link works. Thanks for helping us reproduce the bug.

I encountered this issue today too!

I haven’t investigated the cause yet, but I think it is related to Feeds trying to autocreate a term in the language configured on the target. In my case the language configured on the term reference target is ‘Default’, so I think Feeds tries to create a “translation” in the language ‘Default’. The reason of the resulting failure could then be that Drupal complains that ‘Default’ is not a valid translation language.

See \Drupal\Tests\feeds\Kernel\Feeds\Target\TranslationTest::testAutocreatedTermLanguage()

I think we need to add a test that is similar to the one mentioned above, but with the target language set to ‘Default’.

The bug would then be in \Drupal\feeds\Feeds\Target\ EntityReference::createEntity(), most likely this piece:

// Set language if the entity type supports it.
if ($langcode = $this->getLangcodeKey()) {
  $values[$langcode] = $this->getLangcode();
}

This patch could fix the issue for future imports. I do wonder if the fix is correct. It seems as though the language configured on the processor will get ignored with this change. Maybe I need to add a test for that.

Let's see what the tests have to say about it.

Thanks @megachriz.

The tests generate expected output!

@haixiali does the patch above fix the issue for you?

I did some tests. When not configuring a language on the taxonomy reference target, a term was created in the site default language and not the language configured on the processor.

The configured language on the processor is respected for the entities to be imported, before and after the patch. But I wasn't too sure if this was already covered by the tests, so I added a test for this.

The attached patch should fix the autocreated term to be created in the language configured on the processor, if not configured on the target. I had to make a method on the processor public for that, so this introduced in fact an API addition. But that's okay when in alpha stage.

Let's see if this fixes the failing test.

Nice work improving the tests @megachriz.

@haixiali does the patch in #11 fix the issue for you?

Same here. When I edit one of these problem terms, I see this error in the console when I try to click Save:

An invalid form control with name='weight' is not focusable.

Then I expand "Relations" and the Weight field is empty and required. If I put in a value like 0 (zero), it lets me click the save button but then shows this white screen error:

The website encountered an unexpected error. Please try again later.

InvalidArgumentException: A translation already exists for the specified language (x-default). in Drupal\Core\Entity\ContentEntityBase->onChange() (line 810 of /home/user/public_drupal/web/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

The strange part is I went into phpmyadmin and change the taxonomy_term_field_data table "langcode" column from "x-default" to "en" so it shouldn't be showing x-default unless that's buried in another table somewhere?

Edit:
Looks like these are the tables:

taxonomy_term_field_data

taxonomy_term_revision

taxonomy_term_field_revision

@c2oxide
When working on multilingual support, I got the meaning of the constant LanguageInterface::LANGCODE_DEFAULT (which equals "x-default") wrong. The langcode should never be "x-default". If your site default language is English, it should be "en". If you configure a language on the processor or target, it should be that language.

I'll be checking my patch today and then hopefully commit it. After that, a new release will follow shortly. Cause there is no easy way to recover from this issue. Ways to recover from this issue are:

• Programmatically set the langcode on the term:
  

  $term = \Drupal\taxonomy\Entity\Term::load($term_id);
  $term->langcode->value = 'en';
  $term->save();
  

• Adjusting the langcode value in the database (apparently in the tables "taxonomy_term_field_data", "taxonomy_term_revision" and "taxonomy_term_field_revision").
• Deleting the term (and reimport it [after this issue is fixed]).

Committed #11.