Contextual filters are added and managed in the advanced section in the Views main configuration panel. They generally follow the same patterns as filters, but have a number of settings that normal filters lack. (See figure 10.7) Take a deep breath:

  • When the filter value is not in the URL: This setting determines the view behavior, if there is no value for the contextual filter. This is an essential setting when using contextual filters in block displays.
  • Override title: This setting is used to alter the view's title, if there is a contextual filter value present. You may use variables in the form %1, %2, and so on, to include the first, or second filter values in the title (and so on). If there is any title element associated with the filter value, such as a node title for node IDs or user names for user IDs, the title element will be used - but only if the contextual filter is validated (see "Specify validation criteria" below). A typical use case is the title articles written by %1.
  • Override breadcrumb: This setting allows you to set the breadcrumb to use when a filter value is present – or default to using the view title. The breadcrumb will lead to the view without this contextual filter value and the view must have a valid response to this.
  • Specify validation criteria: Since you cannot limit what users may input as contextual filter values in the path, there may be reasons to verify that the filter value corresponds to what you expect. This setting allows you to validate the filter value in a number of ways. It also determines the view behavior if the validation fails. A typical example is to only allow filter values that are node IDs for selected node types.
  • More/allow multiple values: This setting allows several values for the contextual filter. Values separated by commas are interpreted by Views as AND conditions. Values separated by plus signs are interpreted as OR conditions. A typical example is allowing several taxonomy term IDs to display all content marked with any of the terms.
  • More/exclude: This setting inverts the filtering. The rows matching the filter criteria will be excluded rather than included. A typical example is applying this to a node ID filter to exclude the node currently viewed from a list of similar content.
  • Reduce duplicates: When filtering on several criteria, Views may end up repeating some of the results (if they meet more than one condition). This option reduces any duplicates, but makes the database query heavier. A typical example is reducing duplicates occurring when filtering on multiple taxonomy terms.


Figure 10.7: The settings available for contextual filters vary between different data fields. This is the settings for content: nid.

It is worth pointing out that contextual filters lack some of the settings available for normal filters:

  • There is no functionality for grouping contextual filters in OR or AND groups.
  • There are no options for selecting which operator should be used with contextual filters (save the exclude option). All default to is equal to.

TIP: There is a data field unique to contextual filters – global: null. It is used to have the view accept filter values without altering the database question created by Views. The null contextual filter may still alter the title or breadcrumb of a view and validate the input.

AttachmentSize
09.7 configure contextual filter.png59.48 KB

Comments

qasimzee’s picture

Is it possible that the breadcrumb of the view with contextual filter leads to filtered output?
For example, the final link of the breadcrumb trail on view page user/12/nodes should lead to user/12/nodes instead of "user/all/nodes".

--
Qasim Zeeshan
http://qasimzeeshan.com

alansaviolobo’s picture

Can anyone provide insights as to why contextual filters cannot/do not work with operators other than =

tonyhrx’s picture

I had this problem using date filters.

What I wanted was to use the mini-calendar from the Calendar module and when you clicked on a day in the mini-calendar it showed events greater than or equal to the day, rather than the day itself.

I ended up using hook_views_query_alter as shown below. I used dpm($view) to examine the query

function my_module_views_query_alter(&$view, &$query) {
//check what view we need to use
	switch($view->name) {
		case 'my_view':
			_my_module_my_view_views_query_alter($view, $query);
			break;
	}
}

function _my_module_my_view_views_query_alter(&$view, &$query) {
//check what display we are using - otherwise this will affect the whole view and lead to  a world of hurt.
if($view->current_display == 'page_3') {
//look into the where clause of the query and the date value. This is stored as yyyy-mm-dd
//lets change it to a unix timestamp so we can use it in our query
$date_value = strtotime($query->where['date']['conditions'][0]['value']);
//now lets unset the where bits of the query
	unset($query->where['date']['conditions'][0]);
	unset($query->where['date']['conditions'][1]);

//we only need to know dates 'greater than or equal to' so we can reset the query as shown below
			
	$query->where['date']['conditions'][0] = array(
	'field'=> 'field_data_field_dates.field_dates_value',
	'value' => $date_value,
	'operator' => '>=',
	);
	}
}
dschoni’s picture

If I use variables like in Figure 10.7 I've got the result exactly as I enter it.
This meens, there is no interpretation of the variable.

The result for the title is "This is node %1".

Drupal 9.2.10.