Last updated April 4, 2011. Created by RamMohan.Sakhamuri on March 17, 2006.
Edited by HongPong, RobRoy, hunmonk, merlinofchaos. Log in to edit this page.

Arguments are parts of the URL of a view that can be used to reduce the result-set. A classic example of an argument would be in the case of taxonomy/term/TID or tracker/UID. In the former case, the view is restricted to posts tagged with the associated taxonomy ID; in the latter case, the view becomes restricted to posts by the specified user.

There is also a special case where arguments can be embedded into a View's URL. For example, the URL /user/$arg/track would be valid on any /user/WHATEVER/track URL, and the WHATEVER would be passed into the view as the first argument.

A given view can have multiple arguments. For example, you might have blogs as a view, and provide UID, Year, Month, and Day as arguments in that order. Thus the URL might look like blogs/1/2006/3/15 which would display all blog posts written by user id #1 on March 15th, 2006. Arguments can also be specified as *, which will be interpreted as 'all values'; so in this case, blogs/*/2006/3/15 would show blog posts by ALL users on that date.

Changed as of Jun 24, 2006: Argument Titles

As of today's update, titles for pages that have arguments now work the way most people probably thought they should work.

Argument Title Overview

If a page has an argument, the title for the last argument given is used. If that argument has no title, it continues to the previous argument's title; if there are no previous arguments, it uses the page's title. All of these arguments may use % substitution.

Argument Title Example

Let's say we have a view that will select nodes with an option to specify the node author and/or the taxonomy term to which that node belongs. The first argument is a user ID, and the second argument is a taxonomy term ID. Both arguments have the Default option set to a summary view; this means that if we give no arguments, we'll get a summary view for the user ID argument, which will be a list of users.

The Page Title (which is the "Title" textbox under the "Page" panel on the Views administration page) is the title of the page when no arguments are given. Since in our example view, omitting all arguments results in a summary view of users, we'll set the Page Title to "Users".

To recap, our first argument is a user ID and the second argument is a taxonomy term ID. Applying the explanation in the Argument Title Overview above to our example we get the following order of operations:

How Views determines the title for our example view

  1. If both the user ID (argument 1) and taxonomy term ID (argument 2) are specified, our Title for the second argument will be used. We set it to "User %1, Term %2" so the resulting title would be something like "User John Doe, Term Some Term".
  2. If a user ID (argument 1) is given, but not a taxonomy term ID (argument 2), then the Argument Title for the first argument will be used. In this case, we set it to "Terms for %1" so the resulting title would be "Terms for John Doe".
  3. If neither argument is specified, the Page Title (the "Title" textbox under the "Page" panel) will be used resulting in a title of "Users".

What if I want to specify only the SECOND argument, but not the first?

Coming back to our example, what happens if we want to find all nodes under a particular taxonomy term, but we don't care who the node author is? This is where the Wildcard and Wildcard Sub argument options come in to play. Wildcard is the URL text that can be used in place of an argument when you want to return all results for that argument. Wildcard Sub is the text that will be used in the argument title for any %1, %2, etc. substitution.

For our example view, we'll set the Wildcard for the user ID argument to "all" and set Wildcard Sub to "(All Users)". Now if we access our view at the path my_example_view/all/34, our view will return all nodes in the taxonomy term ID 34 belonging to any user and the title of our page will be taken from the argument 2 Title resulting in something like "User (All Users), Term Some Term".

Argument Type
This simply displays the name of the argument.
Default
This option tells Views what to do if an argument isn't specified. The choices are:
  • Return a Page Not Found. In this case, the argument is not optional, and if not specified, the view simply isn't there, and 404s the user.
  • Show all values. In this case, the argument is completely optional, and if not there is simply ignored.
  • Display a Summary View. In this case, if the argument is missing Views will not display the actual view, but instead will get a list of all possible arguments and display a list of them, with links to the view with the argument, and a count of posts that argument contains. In the above example, if the User ID argument is set to a Summary View, and the user goes to 'blogs', views will provide a list of every user with at least 1 blog post.
Title
The title specified for an argument is only used if 1) that argument is the last argument present. It is used to provide different titles based upon which arguments are present. With the blogs example above, the actual Title for that view might be "Users with Blog Posts, because if the UID is not present we'll get a summary view. The title for the UID argument might simply be "Blog Posts for %1", only showing the user, since if that title is used, the rest of the date is not specified. Please note that as of Jun 24, 2006 this is a change from previous behavior.
Option
The option field is specific to a given argument; often it is not even present. If it is present, its usage should be described in the help text for that argument.
Wildcard
The URL string that can be used in place of an argument when you want to return all results for that argument, such as "all" or "*".
Wildcard Sub
The text that will be used in the argument title for any %1, %2, etc. substitution when that argument's Wildcard string was given for that particular argument.

The following is a list of arguments supported by Views by default. There can be much more than this! Modules can create argument handlers and provide them. As handlers are provided, they should all provide some form of documentation in the Views help section.

Node Type
The node type argument allows users to filter a view by specifying the type of node.
User ID Authored
The User ID argument allows users to filter to nodes authored by the specified user ID.
User ID Authored or Commented
The User ID argument allows users to filter a to nodes authored or commented on the specified user ID.
Taxonomy Term ID
The argument will filter by a taxonomy term ID. For this argument, set the option to the depth to search. See taxonomy for more information.
Taxonomy Term Name
The argument will filter by a taxonomy term name. For this argument, set the option to the number of characters, using 0 for full term; use 1 for an A/B/C style glossary.
Node Title
The argument will filter by the node title. For this argument, set the option to the number of characters, using 0 for full term; use 1 for an A/B/C style glossary.
Year
This argument allows users to filter by what year the node was posted, in the form of CCYY.
Month
Months are specified by the numbers 1-12. Since this argument does not specify a year, it is recommended that it usually follow a 'Year' argument.
Week
This allows the user to filter a view by the week number from 1-52. It is recommended this argument follow a 'Year' argument.
Month + Year
This argument combines Month and Year into a single argument, specified in the form CCYYMM.
Full Date
This argument is a complete date in the form of CCYYMMDD.
Node ID
This argument is a single Node ID.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

When using taxonomy term IDs as arguments, if you want to include multiple tids the way to do it is as follows:

http://site.com/myview/4,5,6 = nodes with term IDs 4, 5, AND 6
http://site.com/myview/4+5+6 = nodes with term IDs 4, 5, OR 6

This is the same behavior as the general taxonomy module uses, but it took me a while to figure that out!

------
Personal: Outlandish Josh
Professional: Chapter Three

------
Personal: Outlandish Josh
Professional: Pantheon

By using argument handling code, this can be extended to use multiple taxonomy term names as arguments, something hardworking Views maintainer merlinofchaos says is otherwise not yet possible. This code snippet treats URLs of the form http://site.com/myview/Term1,Term2,Term3 as if they were entered as http://site.com/myview/1,2,3 (where Term1.tid = 1, etc). It splits the first argument on commas, and accepts either term names or tid's in the list. Anything not recognized as either a term name or number is ignored. Terms may be from any vocabulary; add a test for $this_term->vid if this isn't what you want (ie, if your term names appear in multiple vocabularies, but you only want to filter on some of those). As a bonus, the view's title will be set from the given term names, in this case as "Term1 - Term2 - Term3 | Site name". To use this, you should have just one argument for your view, of type "Taxonomy: Term ID", which defaults to "Display All Values", and with Option set to a number no less than the number of terms you intend to use at once in the URL. Use with the following argument handling code:

<?php
$new_title
= '';
if (!
$args[0]) return $args;
$new_arg0 = '';
$new_args = explode(',', $args[0]);
foreach (
$new_args as $this_arg) {
  if (
is_numeric($this_arg)) {
   
$new_arg0 .= $new_arg0 == '' ? $this_arg : ','.$this_arg;
  } else {
   
$these_terms = taxonomy_get_term_by_name($this_arg);
    if (
count($these_terms)) {
     
$new_title .= $new_title == '' ? $this_arg : ' - '.$this_arg;
    }
    foreach (
$these_terms as $this_term) {
     
$new_arg0 .= $new_arg0 == '' ? '' : ',';
     
$new_arg0 .= _taxonomy_get_tid_from_term($this_term);
    }
  }
}
if (
$new_title) {
 
$view->argument[0]['title'] = $new_title;
}
return array(
$new_arg0);
?>

It would be simple to extend this to use OR operators instead or AND, as in the previous comment. Note that this approach will not work with term names that contain a slash (/) or comma (,), and that the above code assumes no term names are numeric.

Tested with Drupal 4.7.5 (views.module 1.159.2.32 2007/01/22 02:13:01) and Drupal 5.3 (views.module 5.x-1.6).

openflows.com

Hey....

So that code didn't work for me. I made a similar one here:

http://groups.drupal.org/node/8500

Basically takes term names in the form termnam1/termnam2/termname3 and converts them to: termid1,termid2,termid3

This code, slightly modified and updated for views 2 can be found here : http://groups.drupal.org/node/8500#comment-269309

--
a_c_m
demotix.com

http://drupal.org/node/180138

Using Views Arguments with CCK Taxonomies doesn't work correctly, with %1 ending up Empty.

To use an argument in a Block View you will probably need to have to use a bit of PHP in the argument handling code. See http://drupal.org/node/83415.

In Views 2 (Drupal 6.x), Views does more of the heavy lifting for you and you don't generally need to use PHP in this way.

Can someone add a link to Views2 arguments style?

hai all'
is there a way to pass arguments to a exposed date filter (set to display content between two selected dates).
through URL.
help me.

Using Drupal 7

looking for the same answer. Trying to pass arguments from url into blocks.

I find it incredible hard to adapt this handbook page to an own use case, maybe because I seem to not fully understand the meaning of sentences like this: "The title specified for an argument is only used if 1) that argument is the last argument present. I believe that this is the behaviour I actually want (build the view's title from the second argument), but the view I have built seems to not work this way: First argument on Node ID with node id as default argument from URL, second argument on Term ID with term id as default argument from URL; both arguments are present, and I want the second argument as title, but the view just returns "%2" when the page is displayed (it doesn't replace the placeholder with the actual argument). Also I find it higly irritating that the views preview for the block does display proper results (arguments enteres: e.g. "18829/6603"), but not the rendered page with embedded block with nid 18829 and tid 6603. I am vaguely aware that (some?) arguments are not passed to blocks; because of that I'm trying to work with default arguments (which are imho supposed to work around this limitation).

Regarding the paragraph "How Views determines the title for our example view", with views 6.x-2.12 I'm getting exactly the opposite behaviour to what is described above; e.g., if a block title is configured, any argument title is overridden; if a views display title is configured, any argument title is overridden, etc.

Also I'm trying to understand the section "What if I want to specify only the SECOND argument, but not the first?", but even after reading it several times I don't understand it. The first paragraph says, I have to use the Wildcard and Wildcard Sub argument options, but it neither explains what I can enter into the Wildcard field except the prefilled "all", nor does it say if I have to modify the settings for the first or second argument for this. I have tried lots of variations, but couldn't get the results I would have expected; maybe this does not work for views blocks, either?

Maybe parts of this handbook page do not apply to more recent versions of Views anymore (user 'HongPong' tagged the handbook page on 04/04/2011 for Drupal 5); if this is the case, would someone capable be willing able to update this document for Views2/3?

Drupal 7.19
It seems to me that there is an implicit understanding that everyone reading these pages had a Drupal dictionary in their heads. For example, take the word argument. An argument is what you get from a teenager every time they are supposed to do their chores. An argument is information that is passed to a function.

When you say that, "Arguments are parts of the URL of a view that can be used to reduce the result-set." What does it mean? From that statement, I would assume that every setting in a view should show up in the URL of the view. I don't see all the settings from my view in the URL.

It would be great to have a clarification of the statement.