- Issue created by @ecvandenberg
- Status changed to Fixedover 1 year ago 2:53pm 26 March 2024
- 🇳🇱Netherlands megachrizI think that you might have accidentally reversed a config update. In feeds_post_update_ensure_feeds_item_storage_config_cardinality_is_unlimited()the cardinality of all feeds_item fields were set to unlimited. This resulted into a change in all field.storage.*.feeds_item configuration items. But if you had done a config import after running database updates, then the change coming from that update got reversed.Solution: - If you manage the config files in yml files, go through every field.storage.*.feeds_item.yml file and set 'cardinality' to -1.
- After that, do a config import.
 For example, field.storage.node.feeds_item.yml could then look like this: uuid: fca90d5d-2059-40ba-b99c-76b7ead03233 langcode: nl status: true dependencies: module: - feeds - node id: node.feeds_item field_name: feeds_item entity_type: node type: feeds_item settings: target_type: feeds_feed module: feeds locked: false cardinality: -1 translatable: false indexes: { } persist_with_no_fields: false custom_storage: falseNote: the same question has been asked recently in 💬 feeds_item this field cannot hold more than 1 values. Fixed . 
- If you manage the config files in yml files, go through every field.storage.*.feeds_item.yml file and set 'cardinality' to 
- 🇳🇱Netherlands ecvandenbergMegaChriz, you are the best! 
 That really makes sense. In the past I wasn't aware of this effect. And indeed I see the cardinality: 1 in the config files.
 That makes me think what else might be mixed up in my sites...Many thanks for your quick response. 
- Automatically closed - issue fixed for 2 weeks with no activity.