Can someone explain the functional difference between contextual filters and relationships?

I understand that a relationship is a table join, and a contextual filter is passing parameters to the view. Both adjust view data. How would you describe when each should be used?

I have been building complex views for a few months now, but sometimes I still don't have an intuition for what I need - I generally have to find a tutorial on exactly what I am trying to do, and I think it stems from not really understanding these two capabilities.


Thanks for all the answers helping to describe the SQL building. On that topic, I found this advice very helpful.


5 Answers 5


Just think of it terms of SQL:

  • a 'relationship' is a JOIN on another table
  • a 'filter' (contextual or not) is a WHERE clause.

'Contextual' just means the parameter comes from the current context, e.g. part of the URL, something in the session, etc


I think you described it well yourself. A relationship is a join. You are joining another table to the base table for the view you are creating. A contextual filter is an argument you are passing to the query created by the view.

If you are creating a list of node titles a simplified query you are creating might be:

SELECT title FROM {node};

A contextual filter would pass an argument into that query. You can grab the argument from the URL or a number of other places. In this example the type would be an argument you are passing using a contextual filter:

SELECT title FROM {node} WHERE type = 'page';

An example of a relationship might be accessing user info about the node author. If you added a relationship to the user on the user id the query might look something like this:

SELECT title n, username u FROM {node} n JOIN {user} u ON n.uid = u.uid WHERE type = 'page';


I think some examples can ease understanding.

When we should use relations

We have data A and data B, B relates to A. This relation could be caused by Drupal (like author of a node), or be caused by a reference module (like taxonomy, node reference, user reference, etc).

Imagine that A is the content piece and B is the author. We are designing a view of nodes (type A) , and we want to restrict nodes to ones which are written by a user (type B) whose score is more than 100 (imagine this field is added to user fields).

I need data of user. To get these data we use a relation. We make a relationship based on author's uid, which brings information about a user with it.

So we use relationships to access data of B using its relationship to A.

What is a contextual filter

Imagine I want a block that lists all nodes written by a user. I want it to be displayed on each user's account page.

I have to filter nodes by something which is contained in the page which the block is shown on. In this situation I use a contextual filter.

I get data from the page (address, title, body, etc) where the block should be displayed; here there is not a straight relation. The view's content must be filtered by the user's id, but we are not getting the uid from a user. Rather, we are getting this info out of the page the view will be rendered on.

So contextual filters are usually used when we want to filter a view based on a place it will be displayed.


Relationships give you information about entities that are not listed in the fields b joining current content with other entities. For example detail information about the author of the node is not in the fields, Only it's uid is in there, so by selecting author as relationships you can get the rest of the information.

Contextual filters are similar to regular filters in that you can use mainly the same fields to filter the records on. Where contextual filters differ greatly is that you do not set the filtering value when you create the View, but it is taken from context. Contextual filters are great for when the View needs to display content dynamically depending on various contextual conditions


For example, you were tasked to build a Forum that does cross-listing users according to their geolocation.

So, we have a content type called Forum that includes all the necessary fields like entity reference and taxonomy. That entity fields are connected to that forum content type.

So the way to do it

We can actually determine the cross-listing the moment the user logged in and choose the right location, and that location we'll use it as a location ID (base on Continent and not base on the Country) That continent will be use as a block (Contextual Filter) to be use as a parameter, once it gets fired or click by the the user, lets say the User chooses "Asia" all that comes out inside the forum will be only "Asia" and i'll place also a exposed filters for the Category [ Education, Science, Ecosystem, etc.] and label it as Category above the Forum. So it will be easy for the user to go choose a category they wanted to go or look at to read.

So for the Continent block, i'll use relationship, Adding relationships using the Location Id, not the author id. So, now that location id will be the Identifier, and go back to Contextual Filter and hit "add" choose location id, and the User: Location Id.

Above there is a Relationship that holds the Location id as the identifier. In the forum page, i'll select the "Validator as User" in the "Type of user filter value to allow: select "only allow string usernames".


  • Setup location Id of the User to use as a Contextual Filter to use as parameter to the forum content type by grabbing or declaring the node to make a bridge that once that geolocation (continent) gets fired it sends us to directly to the forum according by Continent, and the topics within that Continent.

  • Forum View, set up all the necessary fields and formats within this View.

I'll use Contextual Filter and Relationship to bind the Content type "Forum" and also the users geolocation id, it helps me determine to filter them accordingly.

As i may not be confident as how this should work, just a quick query. Anyone here would Kindly let me know if i can use the Location id on this matter? Big Thanks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.