Jump to:
| Project: | Views |
| Version: | 6.x-2.2 |
| Component: | Views Data |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
I set up a template file to display my view with some custom layout. Upon removing a field from views my field alias names changed and broke my template file.
The problem can be reproduced in Drupal 6.9 with CCK and Views installed on MAMP. I have also had the same issue with a LAMP stack.
To produce the problem:
1. Perform a clean install of Drupal 6.9
2. Install CCK-6.x-2.1 and Views-6.x-2.2
3. Other than the core modules, enable CCK Content, CCK Text, Views, and Views UI.
4. Create a CCK content type with 2 text fields called "test_1" and "test_2".
5. Create a few nodes with this content type.
6. Create a new View and add a Page display with the fields "test_1", "test_2" and save view.
7. Copy "views-view.tpl.php" from the views module folder and add to the Garland theme.
8. Add
<?php
print_r($view);
?>9.
<?php
print($view->result[0]->node_data_field_test_1_field_test_2_value);
?>10. Remove "test_1" field from the view.
11.
<?php
print($view->result[0]->node_data_field_test_2_field_test_2_value);
?>Every time I add or remove fields from Views my template file beaks because the fields have a new alias.
Is there a way to keep the field alias the same while editing my view?
Comments
#1
This is the expected behavior; you should never refer to the alias names used in the $result directly. If you do, you run the risk of exactly this happening.
This:
print($view->result[0]->node_data_field_test_2_field_test_2_value);is a bug in your code.
#2
Not only is that a bug, that is begging for cross-site scripting attacks.
#3
I did not see anywhere in the $view object that I could grab the value from the field other than from the field alias.
Is there another way to grab the field value?
#4
Use the $rows variable in your template. This contains the sanitized values, ready for printing, and are named nice, sane things like $rows[0]['field_test_2'].
#5
Thanks for the tip. I will look into the $rows variable instead of the $views object.
#6
It actually depends on the template (sorry about that, I am a bit inconsistent about this). Sometimes it's $rows and sometimes it's $fields -- but this should be documented at the top of every template. In addition, there's a more extensive document telling you how to find this information in the advanced help.
#7
How would I access hidden fields?
They do not appear in the $rows or $fields variables.
#8
That's slightly trickier:
<?php$value = $view->handler['field_id']->render($view->result[$numeric_id_of_row_starting_from_0]);
?>
#9
Since that seems like scary voodoo Views dark magick, ;) I spoke with merlin on IRC and he suggested #362218: Add a consistent way to render fields from a view as a consistent way to deal with printing any type of field, hidden or no.
#10
Just a quick correction to #8 to save the next person some headaches. This ended up actually being:
<?php$value = $view->field['field_host_value']->render($view->result[$count]);
?>
(Where the CCK field was named 'field_host')
Thanks again, Earl!
#11
There (still) seems to be a related problem with Views + Views Custom Field. See #701798: use of the "field id" instead of field aliases.
#12
Re #10
or use:
<?php//within field tpl files
$value = $view->field['field_host_value']->render($row);
?>
#13
I hope this help you: http://drupal.org/node/997228#comment-4731518
#14
Volkswagen golf 7 - это выбор для ценителей германского качества.