What or is there a hook that you can utilize right before rendering results to the php template?

Also, is this means of altering view results bad practice? I'm trying to avoid using the views php field.

5 Answers 5


You can use something along the lines of this:

MYMODULE_views_pre_render(&$view) {

  if ($view->name=='NAMEOFTHEVIEW') {

    foreach($view->result as $r => $result) {
      // do whatever you want with each "row"


  // other views might go here


and this is certainly NOT a bad practice at all, and, at least IMHO, far superior to php fields in the view itself.

  • I implemented this hook and it execution calls this function and comes to the function declaration line. But it does not go inside the function. What might be the issue?
    – cissharp
    Commented Jun 1, 2016 at 17:01
  • 1
    In hook_views_pre_render() you don't get the rows as render arrays, which would be, in many cases, very helpful.
    – CamilB
    Commented Nov 30, 2017 at 10:42

So by design, every single theme hook defined by hook_theme will have a preprocess function called for it. The trick with Views is knowing what all of those actually are.

To get the definition of every Views theme hook available for your current site, you'll need drush, but you can do the following:

drush @alias php-eval "var_dump(array_keys(views_theme()));"

That will spit back every theme hook defined for Views on the current site. For me it returned the following:

array(35) {
  [0] =>
  string(16) "views_mini_pager"
  [1] =>
  string(16) "views_view_field"
  [2] =>
  string(19) "views_view_grouping"
  [3] =>
  string(10) "views_view"
  [4] =>
  string(22) "views_view_unformatted"
  [5] =>
  string(17) "views_data_export"
  [6] =>
  string(28) "views_data_export_csv_header"
  [7] =>
  string(26) "views_data_export_csv_body"
  [8] =>
  string(28) "views_data_export_csv_footer"
  [9] =>
  string(28) "views_data_export_doc_header"
  [10] =>
  string(26) "views_data_export_doc_body"
  [11] =>
  string(28) "views_data_export_doc_footer"
  [12] =>
  string(28) "views_data_export_txt_header"
  [13] =>
  string(26) "views_data_export_txt_body"
  [14] =>
  string(28) "views_data_export_txt_footer"
  [15] =>
  string(28) "views_data_export_xls_header"
  [16] =>
  string(26) "views_data_export_xls_body"
  [17] =>
  string(28) "views_data_export_xls_footer"
  [18] =>
  string(28) "views_data_export_xml_header"
  [19] =>
  string(26) "views_data_export_xml_body"
  [20] =>
  string(28) "views_data_export_xml_footer"
  [21] =>
  string(14) "views_view_raw"
  [22] =>
  string(15) "views_view_list"
  [23] =>
  string(15) "views_view_grid"
  [24] =>
  string(16) "views_view_table"
  [25] =>
  string(18) "views_view_summary"
  [26] =>
  string(30) "views_view_summary_unformatted"
  [27] =>
  string(14) "views_view_rss"
  [28] =>
  string(28) "views_view_summary_jump_menu"
  [29] =>
  string(20) "views_view_jump_menu"
  [30] =>
  string(17) "views_view_fields"
  [31] =>
  string(18) "views_view_row_rss"
  [32] =>
  string(21) "views_form_views_form"
  [33] =>
  string(18) "views_exposed_form"
  [34] =>
  string(10) "views_more"

So, in my case, I needed to add some additional row data to views_data_export_xml_body. So I defined the following in my module:

function my_module_preprocess_views_data_export_xml_body(&$vars) {
  $vars['themed_rows'][0]['item_1'] = 'whatever';

It's not a very practical example but it does demonstrate how to discover, identify, and implement a preprocess function for any Views theme hook. Hope this helps.


I like this page : The life of a view

Views is an amazing module not only because of its UI for query generating but also as it provides comprehensive hooks.

Sometimes these hooks confuse beginners with their sequence.

Here is the processing sequence of these hooks for your convenience.


It depends on what you want to do. Fortunately, all of the views functions are now in the Drupal API Reference.

There are two groups that you want to look at. There are the views hooks. These are used to mess with the $view object at various points in the view construction process. The documentation isn't that great. You can sometimes guess from the name about what you can do, but typically, you have to dpm($view), see what is there and try stuff in different hooks. If you want to alter how a view works, use a hook.

Then there are the preprocess and process functions. Like the rest of Drupal, these match up one-to-one with the views template files. If you want to alter how a view is rendered, then use one of these.

I don't think altering view behavior with the hooks is a bad idea at all. I general, I try to avoid PHP code in UI config at all costs.


You're looking for hook_views_pre_render(). All of the views hooks are defined in views.api.php, and are worth a read-through if you plan on altering anything in the view query-building and/or rendering process.

Gregory's answer also has a good link that outlines the order of hook calls.

Make sure, though, that whatever you need to do really needs to be handled through a hook—with Views 3.x, most of what I've ever needed to do, markup-wise, is easily achievable through the Views UI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.