This small module allows you to have a contextual filter argument apply only when there is no corresponding regular (exposed) filter value present. This is most common on initial page load. After that the contextual filters will silently retreat and let the exposed filter values as selected by the visitor do their thing without interfering. This means that you can take advantage of friendly URLs using contextual arguments instead of ugly and verbose query parameters. Put the URLs anywhere on your site, in emails and in newsletters to take visitors to tailored Views pages.
This small module allows you to have a contextual filter argument apply only when there is no corresponding regular (exposed) filter value present. This is most common on initial page load. After that the contextual filters will silently retreat and let the exposed filter values as selected by the visitor do their thing without interfering. This means that you can take advantage of friendly URLs using contextual arguments instead of ugly and verbose query parameters. Put the URLs anywhere on your site, in emails and in newsletters to take visitors to tailored Views pages.
This small module allows you to have a contextual filter argument apply only when there is no corresponding regular (exposed) filter value present. This is most common on initial page load. After that the contextual filters will silently retreat and let the exposed filter values as selected by the visitor do their thing without interfering. This means that you can take advantage of friendly URLs using contextual arguments instead of ugly and verbose query parameters. Put the URLs anywhere on your site, in emails and in newsletters to take visitors to tailored Views pages.
This module helps reducing these two problems, by introducing a new way of handling arguments. Using the "Views arguments in filters" module, you can use placeholders when configuring filters, like so: Node: Title CONTAINS %1 Node: Post date >= %2 Where %1 and %2 is the standard replacement patterns used to fetch the values for input argument %1 and %2.
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/…
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.