In D7.59 I have to import .csv file and there are all the mappings prepared for that. The file has 500 records, that will become nodes of a content type "record". There are no nodes of this content type in Drupal before the import (all nodes are deleted). When I start the import after it finishes I get the result, that 334 nodes were created and 266 nodes were updated.

Log does not show any errors by the way.

I presume that there are some kind of feeds cache that has to be cleared, to make sure that it does not think that some of the nodes are still in the site. Can someone tell me what SQL tables I should truncate, or maybe there is another way to solving this?

  • What are your importer settings WRT updating/creating nodes? Which field are you using as the Unique? Is it NID? Are you sure those nodes are deleted? I don't expect feeds to cache imports, are you maybe choosing an older csv version for import? Or the import was interrupted mid-way and started again?
    – prkos
    Nov 29, 2018 at 15:32
  • Importer settings direct to create nodes, unique field is not NID, it's field for unique number that each record has. As for deletion - I am simply deleting all the nodes of of that content type. And it according to log the import is not interrupted... But it looks like freeds importer somehow holds the info about previously imported records and therefore it considers part of them as already imported and therefore 'updates them'... Despite that in tge system I have only 'created' ones. Nov 30, 2018 at 6:59
  • 1
    Well, it looks that I've found a simple solution for this issue: I've a) cloned a Content Type of a record, b) cloned Feeds Importer, c) checked if all the mappings are correct, d) changed the settings in Field Validation (As this module was used to use other field as Unique, not NID) and all good as the feeds doesn't have any relations with some previously imported content - all the imports are getting through now. But still - if someone knows how to clean up everything in Feeds from MySQL DB side (or somehow else), please comment, as there could be a situation, when cloning can't be done. Dec 2, 2018 at 13:03

1 Answer 1


Feeds keep track of previously imported items in the feeds_item table. This also includes items that were only updated by Feeds, but not originally created by Feeds.

Under normal circumstances, when you delete an entity imported/updated by Feeds, Feeds will delete the corresponding import meta data from the feeds_item table. There can be occasions where this does not happen. These are:

  • During the deletion of the entity, a PHP fatal error occurred which prevented Feeds from cleaning up the import metadata. Non-fatal errors should not cause this, as Drupal would then perform a rollback of the deletion.
  • Feeds is disabled when deleting the entity.

Feeds doesn't clean up orphaned items from the feeds_item table. To clean this up, you'll need to execute a query on that table. The id column represents the importer ID and feed_nid the feed node ID (the latter is only used when you have attached your importer to a content type and you need to create a node to import content).

Example query to delete all import metadata for the importer 'my_importer':

DELETE FROM feeds_item WHERE id = 'my_importer';

There is an issue to let Feeds automatically clean up orphaned feed items: https://www.drupal.org/project/feeds/issues/1394320

For more information about the feeds_item table, see https://www.drupal.org/node/1768352

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.