The Problem

Today I ran across an issue when trying to format out some Views that were integrated with Organic Groups. I needed to format out a few things, and the one I will speak on and demonstrate here is pulling out the member count in an Organic Group. By default, when you pull that data out in a view, it creates a link to the default OG page for members inside a group. The default path for that page is: og/users/$nid/faces. I find that link horrible, ugly, and just pure nasty in a nutshell. I really don't want anything in a client facing path that references a module name or abbreviation in the path. Of course, you could use a custom path to overwrite those path(s), but that's only if you really want to also use the default view that OG provides for members.

In the project I'm working on, these links that I'm modifying point to a custom panels page with multiple views inserted that relate to the members of the group. This gives me a flexible usage so that any time the member count of the group is pulled & displayed using views, that it will render the way I want, and link where I want the user to go.

In that handler function provided by OG it's also only wrapping a link around the numeric value of the member count, but what I need is more text available to that linking the full text like 24 members.

The project I'm working on has some unique requirements in the wireframes & designs related to the groups, and so some custom work was needed. This walkthrough will show a setup in a custom module that overwrites the default field handler that views uses to render that field.

The Solution

Now, this particular solution is for this simple use case, but can be applied in a variety of ways. I found very little documentation on this topic, and how to accomplish it with ease, hence the reason for this posting.

Step 1 - Adding to your custom module

I'm not going to walk through you creating your own module files, because if you are trying to overwrite a views handler, I'd bet my cookies that you know how to create a .info & .module file, and if not, you can find more on that in this post from the Drupal handbook pages.

First, let's add the views_api hook to our .module file in order to get views to recognize some of the things we want to override. This is going to use us to use a custom MYMODULE.views.inc file and have it pick up the data & hooks we want to implement there as the ones we'll use aren't recognized without this function being present.

Step 2 - Create your custom views handler

Next, we create the file MYMODULE.views.inc in the root of your module's directory. We will also create a folder called includes where we stuff our custom handler functionality in another include file. First is the example of the custom handler I've created at MYMODULE/includes/MYMODULE_handler_field_og_member_count.inc. This really can be named anything, but I prefer to keep a very strict naming convention for functions & files so I can remember what the hell is going on later. We will tell views later how to and where to reference the function we will be placing in this file.

In short, this is the custom functionality that I want/prefer to use rather than the default field handler provided in the og_views module. You can further reference the files in the includes folder under that module for more reference on actually putting the handler together.

Step 3 - Tell views about your handler

Next, I want to alert views that I have a field handler that doesn't suck for my usage, and to use it instead. This is where I really found a roadblock as I hadn't needed to tackle this before, and there was only one tiny bit of docs I could find on this in a patch to the views docs that I don't see live anywhere. There are two functions that we will be placing in our MYMODULE.views.inc that we created and left empty just a moment ago.

This first function will look familiar to hook_theme(), and in essence, it is much the same. It tells views where to find functions to use to format certain objects.

So we have told views that we have a handler function, we have defined our handler function, and now our last issue to accomplish is to have views recognize that the handler function is put in place to overwrite another one that we don't like for whatever reason. To accomplish that, we need to use hook_views_data_alter(). Good luck finding docs on this one!!! It was in fact after kind of figuring out how to manipulate the $data array, VERY simple to implement the custom handler I'd created.

Step 4 - Tell views to use your handler instead of the default one

Conclusion

Wow, that was damn easy! The main thing is figuring out where in the $data array in hook_views_data_alter(). I was able to uncover all of that in the place where Organic Groups declares it's array of views data in og_views_data_og(). Using that array structure provided in the function that is providing the table data to views in the first place, you can see where the handler is located, and overwrite that appropriately using hook_views_data_alter().