Customizing Field Output

Submitted by Brandon Cone on 08/01/2013 - 09:03:am

Ever have a website project where you just couldn't get a node's output to behave like you wanted?  There's no fault on your module selection, site structure, or designs, it just happens that sometimes the output doesn't fit with the designs.  

If you find yourself in this situation then the good news is that Drupal gives you several options.  All of the below solutions to this problem are relatively easy to implement (on a difficulty scale from 1 - 10 I'd say between 3 and 6).  Because each solution is different and depends on several other factors such as time, money, re-usability, etc I'm not going to rate these from best to worst or anything like that - just a list of options that I've found useful to me.

  • Display Suite - If you haven't tried this module yet, you should.  It allows you to do simple alterations on the field output like adding css wrappers (custom or standard). Also has more advanced functionality for how your entire node displays (1 column, 2 column, etc), creating additional node displays through configuration, and gives you access to some of the "locked" fields in Drupal like the node title, etc.  There is a lot more this module does but to expound on all of it would take away from the purpose of this post.   
  • hook_field_attach_view_alter() - There are not as many use cases for this hook as some of the other examples in this post, however, sometimes it is necessary.  An example of when you might want to implement this hook would be when you are displaying entity data inside a field (say a commerce product's add to cart form) and need to adjust the display of one of the components.  This provides you a quick way to alter the renderable array for the add to cart form after it is processed but before it is rendered as part of your node.  Like I said, this is a little limited but still useful to know about.
  • Custom Display Formatter - If you need an extendable, reusable implementation, this is probably the best way to go.  I wrote a blog post a while back about creating a custom field - you can read it here.  The benefits of creating a custom formatter vs an entire field is that you don't have to worry about the field's schema, settings - global v instance, or how it will save data.  All you need to concern yourself with is how it will display the given data.  The minimum that you need for this solution is to define a custom formatter (hook_field_formatter_info()) and then set up how your formatter will display (hook_field_formatter_view()).  
  • hook_page_alter - This hook gives you access to the contents of the page after they are placed in their renderable arrays (content, sidebar_first, etc) but before they are rendered.  If you know where the data is that you want to change, you can drill down to it using this hook.  Make sure you test this hook as both authenticated user and anonymous user as sometimes the contents of the $page array can change.
  • hook_node_view - This hook gives you access to the node and its renderable components before the node is rendered.  Your fields will often contain rendered content so you will want to make sure that any changes you make to fields is themed (either through a custom theme function or otherwise).
  • Custom Formatters - I recently discovered this module and was surprised at how much it can do for it's relative light-weightedness.  This module enables you to define custom formatters using either token replacements or PHP code.  Essentially you get some of the abilities as a custom display formatter without the overhead of hook implementations, etc.  Simply call your "formatter" function from your custom formatter.

I hope these ideas are helpful to you.  Feel free to leave any feedback about any other modules/tools/methods you've found to make your life easier in this regard.

Happy Coding!