Views is a highly flexible module to start with, but the contextual filters increase the use cases for the module by an order of magnitude. Contextual filters work similarly to regular filters, but there is one important difference. Instead of setting a filter value manually, the value is fetched from variables sent programmatically to the view. A regular filter could give you all nodes written by a specified user. A contextual filter for a node author would be able to display all nodes written by the currently viewed user, or the same user who wrote the currently viewed node. The concept is that contextual filters prepare a view for filtering, but the filter value is not yet determined. When the view is eventually called, it is also provided with data used to complete the contextual filters.

The classic example of how contextual filter values are provided to views is by the view path. If a view has the path example.com/my-view, the URL example.com/my-view/story/22 will call the view along with two values for contextual filters (in this case story and 22). But there are more ways of providing contextual filter values. These are discussed in Chapter about Page manager and Panels.

The difference between standard filters and contextual filters may seem trivial, but in practice it is huge. Contextual filters allow you to reuse views in many different situations and allow Views to interact with other parts of the website. One could write an entire book about how to use contextual filters in Views.

TIP1: Until recently, contextual filters were called arguments in Views, and much documentation and many tutorials and Views-compatible modules still use that term. If you see the term argument, it should be interpreted either as a contextual filter, or the value provided to a contextual filter.

TIP2: the standard functionality of contextual filters may be extended to accept filter ranges, such as example.com/my-view/story/21--100 by installing the Views Contextual Range Filter module.

TIP3: you can configure both an (exposed) regular filter and a contextual filter for the same field in your view, but the result may not be what you expect. For a description of the issue and a solution, see the Views Filter Harmonizer project page.

Comments

nithinkolekar’s picture

a little clarification needed. When we say "Content: Has taxonomy term ID" or "Content: Nid",what do we mean by Content? is it the element which is being viewed currently or the element that is about to be fetched from view(output of view).

When "Content: Has taxonomy term ID" is added to views,will it
compare with the currently viewing node whether it has term id or compare with views data that is being fetched, whether it has taxonomy terms

sujumayas’s picture

You have to imagine "Content" as the broad category between your contextual filter is going to act. So, when you find "Content" at the start of a contextual filter, it defines the context in which your contextual filter is going to work: referring to de content of your field or view.

So, for content, you have Author, author id, fields, url, node id, taxonomy term (if selected), etc.

So when you choose "Content: Has taxonomy term ID" it means that you are going to filter by the taxonomy term your content has.

And when you choose: "Content: Nid" it means that you are going to filter by the Node ID. (wich is an specific id that drupal gives any content when its created, so it can be easily found/used in the future).

nithinkolekar’s picture

pardon me, still not get what "content" means when we are applying "contextual filter" "Content: Has taxonomy term ID"

ex. When we go to any drupal module page for ex. rules there will be a block called related projects. Lets assume that it is a view rendered in block which has contextual filter "Content: Has taxonomy term ID".

Here "content: has taxononmy term id" will treat which one as content?

1 rules page which is currently being viewed(basically a node)
or
2 related projects details fetched by the views which are also nodes.

mindless_mind’s picture

It will be: 2. Content will be a node which will be shown in block view.

In your example, imagine that in such filter, there was selected: "provide default argument", with some PHP code. In code there could be some "magic" that grabs and returns term id from "currently displayed node".
That term id, will be passed to filter, and your view will display nodes containing such term.

dschoni’s picture

The examples or tutorials I found are all about Taxonomy or User-ID.
What if none of these are required?

As example:
I would like to get a list of all the chapters of a book of the same level (depth).

There is no Taxonomy and no User-ID.
I've got the Content-ID from the URL, which delivers the actually opened books page.
There is a filter "Depth", which seems to be useless. I can't do anything with it.

  1. So why is it there?
  2. How does it work?
  3. How can I use it?

There are many other filters, which all seems to block any output, without a missing or invalid filter value.
No result. This means, it's not recognizable, what these are for. No help, no hint, nothing.

So the documentation should explain some technical details, about:

  • how the filter works in general
  • how to get usable results
  • relationship between contextual filters, relations and views fields

I've spent weeks for that.
I've tried even relationships. (Book, parent book page, book page - nid,bid,pid)
The results were:

  • I can get the actual page out of the filter.
  • I can get the books title.
  • I can get the children pages!
  • I can get the parent page.
  • But never get the other pages of the same hierarchy level.

There is another thing I never found working:

Context Filter Legacy in attachements:

  1. What is it for?
  2. How does it work?
  3. How can I use it?

As I did experiments with different settings and filters I found, that it forwards the results to it's assigned block(s).
So this gives an additional output before or after the main output.
This is useful, as in my example, to get the books title above the returned chapter title(s).

A documentation should show, how something is built and how one can use it.

The documentation in it's momentary state is useless.
If I could get a solution, I would be glad to document the whole thing here on the page.

Hmm ... as I see now, this is for Drupal 7.
I did not realize before.
I couln't find it for Drupal 9.