Using arguments with Views 2

One of the most powerful features of Views is the ability to define arguments. Arguments provide an easy way to modify the behavior of a view based on portions of the URL.

Getting started

We'll start with a quick example. Let's say you want to create a page that shows recent forum topics by a particular user. This is simple to do in Views. We create a new node view then add a filter for Node:type = forum and a filter for Node:User posted or commented. This second filter gets set to whatever user you want to make the list for and our view ends up looking something like this:

So you're probably thinking that's not particularly rad, and you'd be right. To replicate this kind of list for all of your site's users you'd have to create a View for each user. It would be much better if we only had to make a single View that was smart enough to figure out which user you wanted to show content for. This is where arguments come in really handy.

Adding an argument

Let's add an argument to our View to make it work for all of our users. First thing we need to do is add a wildcard to the path under page settings. We'll do this by changing the path from forum_posts to forum_posts/%. With a wildcard in the path this means the same View page will be invoked for www.centurionwebdev.com/forum_posts/, www.centurionwebdev.com/forum_posts/10, or any other value you'd care to place in the URL after forum_posts.

Next we add two arguments. The first is Global: NULL. So you're wondering what's up with the null argument. It doesn't do anything. This is true to a point. What it's actually doing is acting as a spacer. Since our wildcard is the 2nd segment (forward slashes divide drupal paths into discreet values returned by arg(0), arg(1), etc) of the path we drop a spacer in to cover the forum_posts segment of the path.

Next we add the "Node: User posted or commented" argument. This argument limits the nodes listed to items that have either been created by or commented on by a specific user. Views checks the 2nd URL segment (where our wildcard is) for a valid UID and if it finds one it shows content. This argument makes the Node: user posted or commented filter unnecessary so it's ok to remove it now.

Validate your input!

One important thing to keep in mind here is Views (by default) doesn't care if the 2nd URL segment is a valid UID, a string of random characters, or a URL encoded copy of the original formula for Coca Cola. To keep a lid on things it's always a good idea to configure the validator options to provide sanity checks on your arguments before they get to the database. This counts as filtering user input and is a cardinal rule of any secure web app.

Update: Mike at All the Pages Are My Days has provided a good example of using Views php validator which he's using to generate archives.

One cool thing that Views does is allow you to preview the output of a view with whatever arguments you would like to test. At this point if you put forum_posts/ (this being your UID) in the arguments field and click on the preview button you should see some forum nodes listed (assuming you've created some).

So now we have this page that automagically lists forum posts when a valid UID is passed as part of the URL. That's ok I guess but it would be a lot cooler if this was part of a user's profile display instead of a separate page. Let's make that happen.

Arguments and blocks

Once again we edit our View. This time we're going to add a Block display. This creates a block on the block administration page. This way we can place the block in a side rail and set it to only show up on user profile pages.

But not so fast, there's a problem. Blocks can't see the arguments. This might be because they don't have a path assigned to them, or it could be some other issue that prevents it but either way arguments supplied via the URL aren't directly available to a View block. So what now?

Fortunately the developer that works on Views is a particularly farsighed individual who has already provided us with a workaround: default values.

There is a configuration option for each argument that tells the View how to behave if that argument isn't present. Even better, one of the options is to provide a default value for an argument that's missing.

There are several options available here but the one we want is PHP code. This is perfect since Drupal provides a function that will reliably output the value we're after: arg(). Since arguments are passed as part of the URL, and in this instance our argument is always in the same place we can simply return arg(1) and get what we're after.

Since we only need this for the block display it's a good idea to use the override button to save this configuration change. This way it is only applied to the block display.

Wrap up

To finish up our View all we need to do is add a filter for node published = true and one for content type and we're done. Save the View and you should now be able to place the block in a block region and set the visibility so it only displays on user profile pages. Congratulations, you've just added a nifty content display feature to your user profiles with no module coding required.

Update:

For those of you interested in getting arguments to work with Views block display there's a better way to do this. No more hand-coding PHP inside your View. It's cleaner, it's MUCH faster, and it's insanely powerful. Props to Seth Cohn for presenting on this during UnCon in San Francisco.