invoke hook_taxonomy_term_update() when the hierarchy changed

This is a good, clean, wholesome move towards leveraging the module's own API, and would enable us module developers to hook into term updates in a much cleaner fashion.

+100 :)

Have tested this patch and it works for me.

This passed three weeks ago. Any reason not to commit?

This does definitely seem like the "right" thing to do (and I have had to implement workarounds in the past to get around the fact that this isn't happening), but I think we need to discuss whether we actually should do it in Drupal 7 at this point. There's a possible performance impact on the admin page if tons of terms are going to be saved at once, plus the sudden triggering of hooks on each one of these which didn't happen before could have unexpected effects depending on what those hook implementations are doing. As an extreme example, I have worked on sites that use https://drupal.org/project/deploy to deploy changes to taxonomy terms between sites on save, and it would be unexpected to suddenly deal with 50 or so of those on a single page request.

Also, #1818560: Convert taxonomy entities to the new Entity Field API did this for Drupal 8 (as part of a larger set of changes) and didn't wind up with a @todo, so I'm curious why the implementation in this issue came out so different...

There are some minor code style issues in the patch too, such as:

+    } else {
+      // TODO: Handle multiple parents after UI bug is fixed

"else {" should be on its own line, and use @todo - see https://drupal.org/coding-standards

@David_Rothstein I appreciate your really thoughtful response. It would be interesting if someone could test this patch with deploy or migrate module (any kind of bulk movement of terms). But in the end, this really is the right thing to do. You can't really argue with @SpaJenniOs here.

Changing a term's hierarchy should be captured as a change to a term.

And a change to a term should trigger some kind of hook/event that can tapped in to.

Now, where we might find some operable middle ground is that maybe a change to a term's hierarchy doesn't necessarily have to trigger a taxonomy_term_save(). Perhaps what should happen is that we create a new hook for the taxonomy module. taxonomy_term_update_hierarchy(). That function could do a module_invoke_all.

Doing it this way would have two benefits:

1. Reduce the impact on existing code since no modules have implemented this new hook yet.
2. Still allow modules to hook into the change to the hierarchy and respond in an appropriately drupally fashion.

The drawback is that we loose the centrality of taxonomy_term_save(), which is, as @SpaJenniOS points out, the "real" place where term changes should be channeled and worked with.

Here is the other approach - to invoke a different hook so other modules can react to the hierarchy change.