Provide entity post-save hook

In order to get #1183440: Multilingual Feeds - Make field import language-aware working (so that the translations can be recorded), this is rather necessary. Here's a patch as part of the work I've been doing for that issue. (#1364070: Record translations created by Feeds is now waiting for this to get committed.)

Adding tag.

@colan - Trying to apply your patch. Which version of feeds should i patch this against? I did a patch of a clean clone from drupal (7.x-2.x-dev) and the patch failed.

$ git apply -v -p1 add_entity_save_hooks-1362378-1.patch
Checking patch feeds.api.php...
add_entity_save_hooks-1362378-1.patch:15: new blank line at EOF.
+
Hunk #1 succeeded at 239 (offset 15 lines).
Checking patch plugins/FeedsProcessor.inc...
error: while searching for:
          }
          $this->map($source, $parser_result, $entity);
          $this->entityValidate($entity);
          $this->entitySave($entity);

          // Track progress.
          if (empty($entity_id)) {
            $state->created++;

error: patch failed: plugins/FeedsProcessor.inc:126
error: plugins/FeedsProcessor.inc: patch does not apply

Should i be patching againsted the 7.x-2.x-alpha version?

If it doesn't work against the latest dev version, then it'll need to be re-rolled. Set it to "needs work" if that's the case. Not sure you need the "-p1". Try it without it as well.

@colan Yeah i did a -p0 and it had produced a missing path issue:

$ git apply -v -p0 add_entity_save_hooks-1362378-1.patch
Checking patch a/feeds.api.php => b/feeds.api.php...
error: a/feeds.api.php: No such file or directory
Checking patch a/plugins/FeedsProcessor.inc => b/plugins/FeedsProcessor.inc...
error: a/plugins/FeedsProcessor.inc: No such file or directory

I also removed the -p0 and it has failed as well:

$ git apply -v add_entity_save_hooks-1362378-1.patch
Checking patch feeds.api.php...
add_entity_save_hooks-1362378-1.patch:15: new blank line at EOF.
+
Hunk #1 succeeded at 239 (offset 15 lines).
Checking patch plugins/FeedsProcessor.inc...
error: while searching for:
          }
          $this->map($source, $parser_result, $entity);
          $this->entityValidate($entity);
          $this->entitySave($entity);

          // Track progress.
          if (empty($entity_id)) {
            $state->created++;

error: patch failed: plugins/FeedsProcessor.inc:126
error: plugins/FeedsProcessor.inc: patch does not apply

Could you please re-roll your patch against the latest dev version?

This is going to be non-trivial, as I wasn't aware of #1005128: Rules integration & enable modules to customize imports, whose commit conflicts with the way this is done. This is what happens when the issue queue gets too big. So this is a quasi-duplicate. That one has a pre-save hook (which has a different signature - that's the problem), but no post-save hook, which is still required.

It's necessary to have a discussion over there to determine how to proceed.

@colan Do you think there is a way to roll an short-term fix to just get the post-save hooks working? I'm not really interested in rules integration with my import at this current moment. I'm more interested in solving these issues: #1183440: Multilingual Feeds - Make field import language-aware & #1364070: Record translations created by Feeds

As I don't have time to merge all of this stuff right now, I recommend the following: Get the dev version of Feeds just before that commit got in, and then apply the language patches you mentioned (from around that time). This should allow you to get stuff working. This is what I did the other day.

The pre-save hook is done as of #1005128: Rules integration & enable modules to customize imports. With info in there, and an example implementation over at #1364070: Record translations created by Feeds, it should be possible for someone to redo this patch. I just don't have time right now, sorry.

I have modified FeedsProcessor.inc to run the pre and post save hooks. They do run, but function entity_translation_feeds_presave($source, $entity) and function entity_translation_feeds_postsave($source, $entity) are still not being called.

          // Allow modules to alter the entity before saving.
          module_invoke_all('feeds_presave', $source, $entity);
          if (module_exists('rules')) {
            rules_invoke_event('feeds_import_'. $source->importer()->id, $entity);
          }
          
         // Allow modules to alter the entity after saving.
          module_invoke_all('feeds_postsave', $source, $entity);
          

All for the issue, but this is not a release blocker.

I was searching for a way to hood entity_save because there isn't a feeds_postsave hook. I would like to pass the data table id to a queue for further processing.

Is this code current available? Or tips for hooking the entity event?

Thanks!

Reworked the patch for latest head.

Been testing this for a few weeks now and works great for my purposes (making modifications after a node is imported via feeds)

Marked #1772402: Add postsave (after save) hook to FeedsProcessor as a duplicate.

Marked #1962000: New hook hook_feeds_postsave() as a duplicate.
But please verify that issue, since it has a nice example in the patch.

I have merged in my patch #1962000: New hook hook_feeds_postsave() which as mostly a duplicate of this patch. I have included my example, and I have add the $entity_id as a parameter.

The main reason for doing this, is because there is no other way to tell if this is a new entity or an existing one. Yes on nodes you can use $entity->new_item, but this is not available on users or taxonomy.

Forgot to change status.

Also see http://drupal.org/node/1939256 for how I have used this new hook.

oops, php error is the example.

Committed to 7.x

I've removed the entity_id. That can be found on $entity->feeds_item->entity_id as well.

As I said above the main reason for the $enitity_id was to use as an indicator that the entity is new. With nodes you can check new_item but with users or taxonomy you can't check that.

In the patch the $entity_id for a new item will but NULL, and not the actual id. There are a few ways to get the id, but none that I can think of to check if the entity is new.

With Feeds Delete this means I have to do an additional check to to know if I need to write it down.

If you have any ideas on how to reliably tell if an item is new.

Thanks.

$entity->feeds_item->entity_id will be 0 if the entity is new, or the entity_id if it previously exists.

Yes on a new item it is, but during the entity_insert the entity_id is updated to the new id. and because this is an object it is all past by reference and past back to hook_feeds_after_save() with this updated.

I was using this field as the key for my own table so I know this is never 0

Edit: I see. It's incredibly dumb that we move item saving into entity hooks just because item deleting is there.

hmmm...

Back to 7.x-1.x then.

A possible way to fix this is by adding a property is_new on the feeds item, as it is that you want to know and not the entity id. Passing $entity_id to the hook can be confusing as I would expect it to be the saved id and not the id it had before saving. If you want it solved it that way, it should at least have been called $old_entity_id.
Another way is passing $is_new to the hook.

So, to sum up, I see three ways of fixing this so far:

1. Add a is_new property on the feeds item.
2. Pass a parameter called is_new to the hook.
3. As gorden suggested in #18, except that the passed parameter is called $old_entity_id (to avoid confusion).

The attached patches implements solution 1 (add a is_new property).

Oops, wrong version selected. Try again...

#28: feeds-adds-is_new-property-1362378-28.patch queued for re-testing.

Ok, I actually went ahead and added the $entity_id argument to all of the hooks as that was the only way to do them consistently.

I committed this as well, the is new attr could be useful in other places like mapping.