Correct field output in Drupal 7
Translation of an article from ComputerMinds : Rendering Drupal 7 fields (the right way)
Use field_view_field ()!
Drupal 7 gives you the opportunity to work with entities (Entities), and with it a powerful API for working with fields that can be attached to entities. If you manage the fields through the "Field Management" and "Display Management" tabs on the material type page, then Drupal will take care of the correct work with the fields.
However, we often encounter the need to display a field outside the entity. A typical example would be the display of data about the author of the node in the side column of the site. Of course, modules such as Panels and CCK Blocks can do this on their own, but to do it manually is not so difficult.
')
You may have seen (or wrote) a code that looks like this:
Digging into the node object was pretty common in Drupal 6, and the “safe_value” would seem to help avoid potential problems. What's bad about it? Let's consider.
Fortunately, there is a field_view_field () !
This function will return the cleared values ​​(fix 4) of the field in full (fix 3) in the current language (fix 1) and in an array format ready for rendering, therefore you will receive all the related data with markup (fix 2). Victory! If the field does not matter, the function will use the reserved parts of the logic language available for the current language. You can also pass an array of formatting options or set the view mode as an additional function argument. Isn't it a great option?
Suppose you just want to get one value without markup. There are two Field API functions to help you in this case. First, we have field_get_items () which returns the element fields in the correct language (again, you can specify the language if you need it). You can dig into it and get raw data, perhaps for use on the server side or if you want to do something exotic, like, for example, “alt” values ​​for an image field. Do not forget that you are dealing with raw data and you need to do the correct preliminary data processing before using the values, otherwise you will create vulnerabilities in your project.
In addition, there is another handy Field API function, field_view_value () , which will help when you want to get a single field value using the built-in data cleaning rules. This function also uses the format field. It takes one field value, which is taken from the array returned by field_view_value (). Here is an example:
Where $ delta is the index of the field whose value you want to get. For a single field, the value of $ delta will be 0. Everything is very simple.
And, just for fun, here is a final example using some formatting options that indicate the ImageCache style and make a reference to the node. This example will work the same way as field_view_value () and field_view_field ().
Of course, in the case of, for example, using the “field-as-a-block” Field API, it does it really well, cleanly and simply. We are dealing with the visualization of arrays, so we can make changes until the trigger () function is invoked, which is called in the template file. And, using field_view_field () and field_view_value () you can be sure that the data will be processed in accordance with the built-in data cleaning rules.
Short answer
Use field_view_field ()!
Full answer
Drupal 7 gives you the opportunity to work with entities (Entities), and with it a powerful API for working with fields that can be attached to entities. If you manage the fields through the "Field Management" and "Display Management" tabs on the material type page, then Drupal will take care of the correct work with the fields.
However, we often encounter the need to display a field outside the entity. A typical example would be the display of data about the author of the node in the side column of the site. Of course, modules such as Panels and CCK Blocks can do this on their own, but to do it manually is not so difficult.
')
You may have seen (or wrote) a code that looks like this:
// $block['content'] = $node->field_name['und'][0]['safe_value']; Digging into the node object was pretty common in Drupal 6, and the “safe_value” would seem to help avoid potential problems. What's bad about it? Let's consider.
- First, the element ['und'] is part of the localization of the field in Drupal 7; direct access to its meaning will lead to problems in any multilingual environment.
- By accessing the field value directly, we lose the ability to themeize the field render and use basic markup.
- [0] [safe_value] explicitly refers to the first field value - if you want to use each value from multiple field values ​​- you will have to use a loop.
- Some fields (for example, node references) do not have a safe_value element, only value, which can be easily displayed without corresponding preprocessing. This is dangerous, and not only because node references contains dangerous data (the same nid), but also because it is a habit habit, especially for new developers. Using the value of other types of fields can also be very dangerous.
Fortunately, there is a field_view_field () !
$output = field_view_field('node', $node, 'field_name'); This function will return the cleared values ​​(fix 4) of the field in full (fix 3) in the current language (fix 1) and in an array format ready for rendering, therefore you will receive all the related data with markup (fix 2). Victory! If the field does not matter, the function will use the reserved parts of the logic language available for the current language. You can also pass an array of formatting options or set the view mode as an additional function argument. Isn't it a great option?
Additional tips
Suppose you just want to get one value without markup. There are two Field API functions to help you in this case. First, we have field_get_items () which returns the element fields in the correct language (again, you can specify the language if you need it). You can dig into it and get raw data, perhaps for use on the server side or if you want to do something exotic, like, for example, “alt” values ​​for an image field. Do not forget that you are dealing with raw data and you need to do the correct preliminary data processing before using the values, otherwise you will create vulnerabilities in your project.
In addition, there is another handy Field API function, field_view_value () , which will help when you want to get a single field value using the built-in data cleaning rules. This function also uses the format field. It takes one field value, which is taken from the array returned by field_view_value (). Here is an example:
$node = node_load($nid); $field = field_get_items('node', $node, 'field_name'); $output = field_view_value('node', $node, 'field_name', $field[$delta]); Where $ delta is the index of the field whose value you want to get. For a single field, the value of $ delta will be 0. Everything is very simple.
And, just for fun, here is a final example using some formatting options that indicate the ImageCache style and make a reference to the node. This example will work the same way as field_view_value () and field_view_field ().
$node = node_load($nid); $image = field_get_items('node', $node, 'field_image'); $output = field_view_value('node', $node, 'field_image', $image[0], array( 'type' => 'image', 'settings' => array( 'image_style' => 'thumbnail', 'image_link' => 'content', ), )); This is rock!
Of course, in the case of, for example, using the “field-as-a-block” Field API, it does it really well, cleanly and simply. We are dealing with the visualization of arrays, so we can make changes until the trigger () function is invoked, which is called in the template file. And, using field_view_field () and field_view_value () you can be sure that the data will be processed in accordance with the built-in data cleaning rules.
Source: https://habr.com/ru/post/163501/
All Articles