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.
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.
hook_views_pre_render()
you don't get the rows as render arrays, which would be, in many cases, very helpful.
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.