Single Value (1) Image field importing as Multiple Values in Feeds

It sounds like a misconfiguration, but it can also be that your source provides two (or more) values for the image field. It could be an empty value + an actual image url.

Can you share how your source looks like?

Oh wait, I see something that could be an important detail in your description:

Failed importing 2 RSS Item items.

checking the CSV export

Are you importing from a RSS feed or from a CSV file? On the feed type, did you select the right parser?

In order to help you further, I will need to see an export of your configuration + a sample source file. It could be there's something strange in the CSV file that is causing this or that there's a misconfiguration.

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.

Reproduced this on D8 and knew we saw something like this in D7 too #2920690: Field validation errors in Number field.

The issue is that Feeds is appending the value to the new entity instead of replacing it in setTarget()

The property has to have a default set like this:

    $fields['attended'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Attended'))
      ->setDefaultValue(FALSE)
      ->setRequired(FALSE)
      ->setRevisionable(TRUE);

That causes "Attended (attended): Attended: this field cannot hold more than 1 values."

Removing the default value worked:

    $fields['attended'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Attended'))
      ->setRequired(FALSE)
      ->setRevisionable(TRUE);

It appears that on Entity creation, Feeds appended the value to the default.

Fixes it specifically for single valued fields.

This issue also appears in boolean fields.
The patch #9 fixes the issue for me, but I can't confirm if this is a complete solution yet.

So this issue occurs on at least base fields that set a default value? Interesting.

@djdevin
Do you want to write a kernel test for this bug?

Yes, I'd like to get into it a bit more though. This is the first time I have looked at D8 feeds (bringing functionality over from D7).

I also ran into this error for a custom entity type. EntityProcessorBase::clearTarget() currently checks if an entity implements TranslatableInterface, which ContentEntityBase already does, so that check almost has no value (because practically all supported content entity types extend that class). So this makes me think that this issue happens for non-translatable entities.

In my case, the issue is fixed when I add the following check to the clearTarget() method:

$entity->isTranslatable()

Attached a patch that adds this + a kernel test.

I'm not sure if this fixes the issue as well for when a base field provides a default value. It would be interesting to have a test for that case as well.

I had this error importing 'feeds_feed' entities:

Title (title): Title: this field cannot hold more than 1 values.
Source (source): Source: this field cannot hold more than 1 values.

Import was working initially, but then it stopped working one day.

This patch fixed the problem.

Just another confirmation:

I, too, was getting

Title (title): Title: this field cannot hold more than 1 values.

when importing CSV from one site to another. The patch in #14 fixed it for me and my import worked correctly.

Thank you!

In some of the multilingual tests $entity->isTranslatable() returned FALSE because the entity bundle was not set as translatable. This can be set as translatable with the service "content_translation.manager".

Let's see if that fixes the tests.

There are no functional changes in this patch, only changes in the tests.

+1 RTBC this patch helped us progress forward with a useable feed import. This must have been something introduced recently as our imports have not changed.

Re #8

I tested the case of using a base field with a default value. I found out that this only caused an issue if the entity type was not translatable. For translatable entities, base fields with a default value did not cause any issue during my testing.

The fix I provided earlier also fixed the issue for the base field case.

In the patch I added a test for the base field case.

@glynster
Correct, this bug was introduced in Feeds 8.x-3.0-alpha7. In that release multilingual support was added.

I think we're good to go. I did note some other issues related to translations, but that seem to be out of scope for this issue: I noticed imports could fail when configuring a field as non-translatable (on content translation settings page), but do select a language for it on the mapping screen.

Committed #19.

Hi @MegaChriz

I think this is not fixed or I experienced new very similar issue, see my debugging:

Because FileFieldItemList returns also extra properties, which doesn't exist in $values it appends existing values (the same goes for single image field).

array (
  'target_id' => '6',
  'alt' => NULL,
  'title' => NULL,
  'width' => '323',
  'height' => '452',
)

Hi @MegaChriz,

unfortunately, this issue for single value fields is still not resolved, at least for date fields. My content type is translatable, even the date field (although this does not make sense for a date field in my opinion).

While importing the tag <pubDate>...</pubDate> into a date field, the import fails due to:

Veröffentlicht am (field_date): Veröffentlicht am: this field cannot hold more than 1 values.
Please check your mappings.

Hi @MegaChriz,

sorry, my fault: I could solve my issue above with:
- install module feed_ex
- changing the XPath statement for this field in feeds_tamper
and
- installing the patch in this comment: https://www.drupal.org/project/feeds/issues/3172709#comment-14999631

In order to make it work, I had to use these settings:

context: /rss/channel/item
XPath value: pubDate
both option fields checked for this 'custom source':
- raw value
- inner xml.