I am working with the CSV importer and I am rapidly importing and deleting nodes in order to nail down my mappings before I let Feeds churn through and create nodes from a CSV with several thousand rows. The problem I am having is that when I use the "Delete Items" tab to clear out nodes that have been imported, I keep getting "there is no new content" when I reimport the CSV file, and no nodes are created. I've tried changing the "Update existing nodes" setting to all three options with no difference. It seems that if I sometimes rename the CSV file and import it that it creates the nodes. Is there something simple I'm missing to get it to quickly reimport every time? Thanks.

Comments

ben.hamelin’s picture

Feeds needs a way to handle the various import options, specifically:
"update existing nodes" vs. "replace existing nodes"

*** The following is my interpretation of feeds, so take it for what it's worth!!

The way Feeds tracks this is to store a record in the feeds_node_item table, where one of the fields is the hash value of the imported data for that node. When you run another import, and the data for that node has not changed, it will get skipped.
**********

If you have access to your database, try clearing the hash value of one of these records, and you should then see that one node (see the nid column) get updated.
Another trick would be to "hard code" one of your CSV fields (say add an "xxx" to one of your string fields) and run the importer. Again, the hash value will not match and you should see an update.

Obviously the NAME of your CSV source is not affecting the process.

One complaint I have is that the MAPPINGS for an importer are also not included in this "new content" test.
For example, I added a NEW mapping to a NEW CCK field, where the SOURCE CSV file already contained the value in question. When I reran the importer, I still got the "there is no new content" message. I used the string append trick to get around this.

Hope this helps!

bh

kapayne’s picture

sub

jangolden’s picture

I was also getting this error, but it was due to csv line breaks on a MAC. I found the solution here http://drupal.org/node/912682.

EvanDonovan’s picture

Version: 6.x-1.0-beta10 » 6.x-1.x-dev
Category: support » bug

I was getting this issue the other day with a CSV importer using the Feeds Node processor, where I had the Source field in Drupal as the "unique target". I checked the {feeds_node_item} table, though, and it did not appear to have any entries. Is that possible?

To solve my issue, I had to delete the Feed importer, and create a new one with the same configuration.

EvanDonovan’s picture

Title: "There is no new content." when reimporting CSV » "There is no new content." when reimporting CSV with same values for each record after having deleted originally imported nodes

Retitling for clarity.

sanguis’s picture

Subscribing

sanguis’s picture

I just want to point out that the XML I was importing was invalid, when when I turned on the "Tidy" option for xPath it started working again

joomlerrostov’s picture

Version: 6.x-1.x-dev » 7.x-2.0-alpha4

I have the same issue with Feeds 7.2 alpha 4, trying to parse html page to nodes.
When i delete content via admin interface, then import - it works, but if use tab Delete items and then reimport - it says There are no new content.

Clear caches and run cron - no matter
help

megachriz’s picture

Category: Bug report » Support request
Issue summary: View changes
Status: Active » Fixed

Feeds keep track of imported items in the "feeds_item" table. Normally, when you delete content, Feeds will delete the reference to that content from the "feeds_item" table (since it implements hook_entity_delete()). There are cases this can fail, for example if you delete content manually from the database or if errors occur during deleting content. In this case Feeds does not know the content is deleted and assumes it still exists. Solution to this problem would be to delete the references to the deleted content in the "feeds_item" table.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.