Missing hook_entity_view() and hook_entity_view_alter()

In Drupal 8, I'd love to standardize on drupal_alter('entity_view') and to get rid of the domain specific drupal_alter()s (e.g. drupal_alter('comment_view', $build). We need the generic one for different reasons, and it would allow us to streamline and simplify the code.

I'd be in favor of this patch, especially if we added "Drupal 8 @todos" to the domain specific drupal_alter()s. It tells people to start using the generic one in Drupal 7.

Yeah, there's definitely use-cases for this. Some modules will want to act on entities generically, rather than on a per-type basis. Just one of about a bazillion examples: contrib really will need a comment module that allows comments on entity types other than nodes. Media entities will need comments. Product entities will need comments, etc. Basically, for all the reasons we made fields work with entities generically, and not just with nodes, many contrib modules will need to do the same: comment, fivestar, flag, etc. Some of these modules will be able to become fields, but not all. So, IMO, this is "major".

It's a shame that we're still finding this now, rather than earlier in the dev cycle. But considering the entity API is brand new to D7, we shouldn't be too surprised to be still finding holes in it. Fortunately, this hole is easy to fix without breaking BC. #830704: Entity forms cannot be properly extended might be more challenging.

What I don't like about #2 though, is that hook_entity_view_alter() runs after hook_TYPE_view_alter(). I would prefer it to look more like:

drupal_alter(array('entity_view', 'node_view'), ...);

For all the same reasons that we did this structure for 'form' and 'form_ID'.

But, I also realize that isn't completely clean, because we can't do the same for the non-alter hooks. Not sure how to best deal with that yet.

For D8, I'd like to move what we did for drupal_alter() into module_invoke_all(), so that we could do module_invoke_all(array('GENERIC_HOOK', 'SPECIFIC_HOOK'), ...).

But, I also realize that isn't completely clean, because we can't do the same for the non-alter hooks. Not sure how to best deal with that yet.

Actually, maybe that's not a problem. The order in which hook_entity_view() and hook_node_view() implementations run shouldn't matter. Who cares if a low weight hook_entity_view() runs after a high weight hook_node_view(). Those implementations are for adding NEW things, not for altering a different module's decision. But I think we need to avoid a low weight hook_entity_view_alter() overruling a high weight hook_node_view_alter(). So CNW for #5.

This looks RTBC, except that the test bot doesn't run.

Dries and I talked about this yesterday. This seems to be pretty firmly in the "API oversight" rather than the "new feature" side of API additions, so committing #7 to HEAD.