Visualization is a module for Drupal 7.x that provides a solid and easy accessible way to visualize data. It provides a theme hook that takes a data array and some options and will then render a chart in-place. It also provides a Views Display plugin so that users can easily visualize data retrieved through Views. The different charting libraries are pluggable through the CTools Plugin system; the module provides an implementation for the Google Visualization API and Highcharts.
We will open the core sandbox and meta issue soon, once the above dependencies are resolved or worked around, so that contributors can begin to explore what it means for Views to be in core.
We are planning one last major sprint before feature freeze in the week preceding BADCamp. (Pantheon will be hosting this sprint; more details soon.) The BADCamp sprint will be our chance to coordinate our final push to make Views core-ready. Once Views is committed to core, all further work will take place in our sandbox and the Drupal core issue queue.
the 'right way' to do this is to work with entity approach and avoid the ['und'][0] business but I never got it to work in views. i.e. code $node=menu_get_object(); $field = field_get_items('node', $node, 'field_event_artistref'); return field_view_value('node', $node, 'field_name', $field['target_id']); code. Here's a link I was following on the topic computerminds.co.uk/articles/…
The Relevent Content Bean essentially provides your site administrators with a light-weight query builder (build on top of EntityFieldQuery) for creating blocks that contain dynamically-filtered listings of nodes. Like Views, Relevant Content Bean allows you to select the number of node results to display, apply filters to the list of returned nodes, change the display options for these nodes, and manage the sort order of your results.
use one exposed string filter to search on multiple fields.
Bear in mind, that, for now, only populates STRING exposed filters, so those filters that take an array (options) or special types won't work, although it may not be difficult to extend it.
...you have "First Name", "Second Name" and "Last name" set up as node or user's fields and you'd like to use one expose filter to search on any of those fields.
Use the Computed Field module to create yet another field stored in the database, combining the two (or more) fields you want to search, then expose a filter for that field instead of both of the individual fields. (I don't like this because it duplicates content/storage, and involves an extra module to do so).
Use the Views Filters Populate to invisibly populate a second field that you've added to a views OR group (using Views OR in Views 2.x, or the built-in AND/OR functionality in Views 3.x).
Views 3 now supports queries against Google Analytics. I've added this experimental module to the 7.x-3.x development release of Google Analytics Reports.
Using Empty Text
There is a situation where one field of a Drupal View needs to pull its content from two fields (aka cck fields) of a node. In my case, they were default author field and a custom field called contributor. This example uses Drupal 7 and Views 3.
If optional the contributor field was not empty, it would display the contributor and skip the author field. If there was no contributor, then the author, which cannot be optional, would be displayed by default.
In the end, one argument against using Views for our content queries overrode all others: we wanted our client to use Views. Our client had specified that once they received the sites, their own developers would be using Views to build blocks and pages themselves. We knew that if we worked in Views for our own work, the Views we created would eventually be exposed to them, which leads to possibilities of regression and error. We wanted our core querying functionality to continue to function without concern that it might be tampered with.
wondering why I wouldn't just build this in Views. Indeed, this might look a bit masochistic if you're used to Views. However, there are a few things to consider:
EntityFieldQuery is core. If you are interested in keeping your installation as lean as possible, this is something to consider. Views is a contributed module, and so it automatically adds size and overhead to your Drupal install.
EntityFieldQuery is small. The amount of code required to generate an equivalent listing in Views, compared to what we built above, is much, much greater.