Add hook_entity_postsave hook

I was thinking the same today.

I think the rational at some point was to not have any $op parameters anymore in hooks, which in the days of hook_nodeapi() made sense, because everything passed through that hook. Ironically, if you take the rational strict, there should have been an presave_insert and presave_update :-)

If we'd introduce post_save, then _insert and _update in a way don't make any sense anymore and those should be removed because you can all isNew() to figure out if it's a new or existing (although we can't for BC reasons). I agree, if you don't care about it, it's kind of tedious having to implement those two hooks, I actually could have used it as well.

Features are 8.1 though.

Sounds reasonable to me. Added standard template.

extra words

The attached patch add the hook_entity_postsave() call right after the hook_entity_insert()/update() call. I may also remove the hook_entity_insert()/update() tests since they will be deprecated!?...

Remaining things I'm thinking off:
- Update core/lib/Drupal/Core/Entity/entity.api.php
- ...

Hmm no, we shouldn't remove tests as long it's there.

Marked #2848894: new hook to cover both entity insert and update - hook_entity_postsave as duplicate.

#2798783: hook_entity_insert() and hook_entity_update() are confusing is also a dupe.

Closing my issue. Please copy over the api.php changes as well as the @todo/deprecation comments.

Closing my issue.

#2798783: hook_entity_insert() and hook_entity_update() are confusing, for reference.

I don't think that isNew() works, would definitely need more specific tests than just checking that it is called.

At this point, the entity is no longer new as it has been saved already. That's why we pass the additional flag to postSave().

Also agreed that if we do this, we should deprecate the other two hooks.

Adding related events-dispatching discussion, which will require a re-roll here if it lands first.

¿This will be added to core?

Re #15:

I don't think that isNew() works, would definitely need more specific tests than just checking that it is called.

At this point, the entity is no longer new as it has been saved already. That's why we pass the additional flag to postSave().

Well this actually has the answer in it :). The post save hook should be consistent with the postSave method and have a second parameter indicating whether this is an insert or update operation.

Added reroll of patch #6 on Drupal-9.2.x.

This seems like people participating in this thread have been in agreement that this change would be a good thing. I am also in a situation right now where I am needing to implement both insert and update, and dreaming of a hook_entity_postsave. Is there anything that can be done to keep this issue moving? I would be happy to assist with reviewing patches on D10 if that will help.

Had a thought, what if we call this hook hook_entity_upsert?

Since thats what DB's etc use. Our terminology cleanly already matches it with insert/update.

I don't have particularly strong feelings about this, and would be okay with this direction. But I think I prefer postsave. For one, it will be clearer that this occurs later than presave. Additionally, insert, update, upsert, are all database language. Maybe my expectations are off, but I did not find this hook naming to be the most intuitive. I expect this will change between people, but as a Drupal developer I was looking for something closer to Drupal language, and not database language. I understand why insert is called insert, but it did not stand out to me as what I was looking for immediately. I think my prior point is the more important one for me. Though I am stating these preferences, I can appreciate the idea, and ultimately I really just want to see this feature in core, whatever the hook gets called.

My immediate use case for a postsave hook is for a hook triggered after all insert or update hooks to an entity are executed. The immediate goal of this ticket is to simplify the entity API. My use case might be an edge case.

I found this issue as a result of an issue I reported to the estimated_read_time module https://www.drupal.org/project/estimated_read_time/issues/3427894

The logic of that module currently executes presave, but can possibly run into trouble when it uses data that only exists after the content is saved.

Without a postsave hook, we could use the Event Dispatcher to hook into entity.post_save. But it's weird there isn't a hook that fires AFTER all the entity saving.

I would appreciate having that today.

Patch for D11
Made a mistake, do not use this patch.

The correct patch for D11

Arguably this is no longer needed now that we have hook attribute.

class MyHooks {
  #[Hook('entity_insert')]
  #[Hook('entity_update')]
  public function entityPostSave(EntityInterface $entity): void {..}
}

Agreed, it's one extra line now, that's pretty minimal overhead. I'm suggesting we close this. 3 hooks will add confusion as to what the difference is and deprecating insert/update seems like a _lot_ of work with limited benefit.

There's another issue where hooks that happen after the transaction are being discussed, I thought at first it's this one, but this just adds it directly after insert/update.

Nevertheless, I will add the reroll for D11.3, as the suggestion in #42 at the end doesn't give the same guarantee that the patch provides.
The patch runs hook_entity_postsave() AFTER the hook_entity_insert() and hook_entity_update() are finished.
The suggestion in #42 may run the code BEFORE hook_entity_insert() and hook_entity_update() are completed.

> The suggestion in #42 may run the code BEFORE hook_entity_insert() and hook_entity_update() are completed.

No, it doesn't run BEFORE. It is a part of those hooks, it is neither before nor after. just like your postsave hook implementation could be before or after other implementations.

OOP hooks provide convenient definitions to specify if your hook should run last if that's what you want: https://www.drupal.org/node/3493962

postsave is still within the transaction, so when it runs then then the changes are not yet available to other processes. hook-as-services make it reasonable simple to run something then delayed in a terminable service, that is then outside of the transaction.