Port issue nid field formatter to D7

This patch majorly conflicts with the code already in the 7.x-2.x branch from #1624874: Port project issue text filter and doesn't apply at all. Please do a 'git pull' and re-roll this so it applies cleanly to the end of the branch.

Thanks!
-Derek

Great, thanks for the patch and the reviews!

Yeah, the recursion problem is in project_issue_link_filter_callback(), not the theme function. See #1624874-8: Port project issue text filter.

That said, (and I'm guessing ChinggizKhan is going to hate me for this), but I'd really rather use #1624874 to fix that stuff, and leave this issue with the (hopefully simple) task of getting the nid file formatter working. Otherwise, git blame just gets confusing and weird. Can we focus on fixing the broken filter code over there and then circle back here with a much smaller patch that does what this issue says it's trying to do? My apologies for not doing a more thorough job reviewing and testing at #1624874 before I committed and pushed. I was in a hurry to try to unblock things, and ended up probably creating more work in the process. :( Sorry!

If I wasn't going to set this to 'postponed', I'd set it to 'needs work' for the following:

A) It's not clear why project_issue_theme() is being moved around in this patch. That just adds 32 lines of noise to the patch, making it seem like we're changing the entire function to remove a single line of code (the 'file' attribute from the array).

B) In core, the code style convention for try/catch is to treat catch like we do the else inside if/else. Namely, instead of this:

try {
  // stuff
} catch (Exception $e) {
  // other
}

it should be this:

try {
  // stuff
}
catch (Exception $e) {
  // other
}

C) At first it wasn't even obvious what we were calling that might throw an exception, but I guess that's coming from EntityMetadataWrapper and friends. Is it really worth the complication to use that wrapper abstraction, just to get a single value from a loaded entity? I'm not saying we should undo what you have here. I'm just asking. ;) Seems like an awful lot of trouble and call stacks to avoid just checking if $node->field_issue_assigned[LANGUAGE_NONE][0]['value'] is empty, and if not, to user_load() the result. Keep in mind that the filter and the code it calls are sort of a critical path performance-wise. Even with the filter cache, this stuff gets called a lot and I'd rather not add extra call frames and layers of abstraction unless they're really necessary. The whole filter API already requires us to do a lot of that, already -- I don't want to make a bad situation worse.

Anyway, most of these comments are off-topic for this issue, they really belong at #1624874 since they're about fixing the filter. But, since the patch was here, I wanted to comment on this before you re-roll anything and post it over there.

Thanks!
-Derek

Right. Please don't post another patch here now. Let's first get the filter itself cleaned up and working at #1624874, just touching the filter. I don't want to push this as-is since it's a confusion between partial debugging and fixing #1624874, mixed in with the field formatter changes. Let's forget about the field formatter entirely for right now and just focus on getting the filter and related code working. And let's discuss those details at #1624874 not here. Then this patch will be trivial and easy and only touching the field formatter.

Thanks!
-Derek

Looks like the status got clobbered during tagging, and that #16 is still awaiting review. I'll circle back when I get a chance if no one else beats me to it. ;)

Cheers,
-Derek

Sorry for the delays here. This was much better, thanks for putting up with my requests to keep the issues and patches isolated and clean.

When I tested this, #16 didn't work at all, due to this code block:

  if (!isset($entity->type) || !project_issue_node_type_is_issue($entity->type) || !isset($entity->title)) {
    return array('#markup' => check_plain($entity->nid));
  }

I had added a "Known issues" field to project nodes on my dev box. The $entity passed into hook_field_formatter_view() is the entity that the field is attached to (in this case, a project node), not the entity being referenced by an entity reference field (the issues). Basically, the same bug from #15 but a different manifestation of it.

So, I rewrote the logic quite a bit:
- We don't care about the $entity at all. All we care about is what lives in $items.
- Use entity_load() instead of node_load() so we can load all the referenced entities in 1 call (exactly what node_load_multiple() does).
- Added code so that if the referenced entity is not an issue node, we still do useful things. I might live to regret this, but it seems like a kind way to prevent some WTFs when people use this. Since you *can* configure this formatter to be used on any entity reference, we should try to support any kind of entity you might reference.

See these commits for the full diff:
http://drupalcode.org/project/project_issue.git/commit/34b336c
http://drupalcode.org/project/project_issue.git/commit/748c458

Thanks!
-Derek