Creating a new issue as suggested by #1075896: Re-work Views arguments

It would be great if we could get filters for the date module that look / work like the filters for Node dates with granularity for date, day, week, month, year, and year+month.

CommentFileSizeAuthor
#3 screen.png17.02 KBm4olivei
need_more_args.png30.19 KBjenlampton
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rickvug’s picture

Sub. Exact same issue here.

rickvug’s picture

It turns out that I didn't have date_views turned on so I didn't see all options. I can now get a view working with arguments such as my_view/2011-05-22 where I can drill down to my_view/2011-05 and my_view/2011. However I'd much prefer the ability to structure this as my_view/2011/05/22 instead as the "hackability" of the URL is much more apparent to users when I have a node URL alias such as articles/2011/05/22/article-title.

m4olivei’s picture

FileSize
17.02 KB

For the contextual filter you used, are you using a Date field on your node? I'd like to filter the nodes in the result by year, where the year comes from the last part of the url, eg:

/about/news/2011

I add the contextual filter titled 'Date: Date (node)' and then on the configuration screen I'm not seeing the field (a date field on my content type) I want to use listed under 'Date field(s)' (see screenshot).

m4olivei’s picture

Just updated date, views and ctools to the latest dev versions and everything worked correctly.

KarenS’s picture

Status: Active » Fixed

The date filter already has a way to set granularity for day, year, month, etc. They are not separate arguments, they are settings on a single argument. The options for the node are much more limited than the date options, I don't want to 'regress' to those just so they look the same. As a matter of fact, you can use the Date argument for node dates as well as field dates, and get the benefit of all the additional functionality on node dates.

The argument can not use slashes, a single argument cannot look like '2011/12/10', because slashes are used by Views to separate arguments. That is built into the way Views works, nothing I can do about that. There is a lot of flexibility in those arguments though, you use arguments like 2011-01--2011-12 to get a date range from Jan to Dec of 2011, or @--P1M to get a range from now to 1 month from now, etc. There is some documentation of those option in the Date's Advanced Help.

jenlampton’s picture

Category: task » support

Thanks Karen.

So can you reproduce the 2011/12/10 URL structure by adding the single date argument three times, instead? I was unable to figure out how to make that happen (and my URL structure can't be changed) but I'll fiddle with it some more and see if I can figure it out. Maybe I forgot the date views module, or something else silly ;)

goodale’s picture

I would also be interested in using slashes. It's a bit inconsistent to be able to structure blog entries like blog/yyyy/mm but not to be able to do the same with events. I am hoping that I'm missing something and it is possible; I tried setting the argument a couple of times, but that didn't seem to help.

Would it be possible to add a selector to add something like a PHP date format (or one of the ones defined on the admin screens) to match on? That would give maximum flexibility.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jenlampton’s picture

Slashes denote multiple arguments: http://example.com/viewpath/arg1/arg2, so you could have your first arg (yyyy) be a 4-digit year, and the second (mm) be a two-digit month.

redndahead’s picture

I was also in need of the news/2011/11 format and here is what I discovered in case people are interested.

If you add a date field as a contextual filter it will be looking for yyyy. So far so good
If you add another date field as a contextual filter it will be looking for yyyy-mm so that doesn't quite work for us. Here is how I got this to work.

1) On the second date filter check the box "Specify validation criteria"
2) Under Validator choose php code.
3) Add this php code

$handler->argument = $handler->view->args[0] . '-' . $argument;
if ($argument > 0 && $argument < 13) {
  return TRUE;
}
return FALSE;

Hopefully this will help someone else.

jenlampton’s picture

Category: support » feature
Status: Closed (fixed) » Active

I'm going to re-open this issue.

The original request was for contextual filters for date that have the same granularity as node updated date (see screenshot above) and since it doesn't look like that's been done, I think this request is still valid.

spgd01’s picture

I would like this feature for Drupal 6.x as well.

#10 did not work for me

Also if 2011/11 is enabled then 2011-11 must be disabled or we will have duplicate content at the two urls.

spgd01’s picture

Any thoughts on making this happen?

spgd01’s picture

Category: feature » bug

For 6.x it looks like I can't even use 2012/2012-02 to display events of just February. I have to use:
2012-02/2012-02

If I use 2012/2012-02 as an argument then It displays all events from the year 2012 not events just from February. Also views will not create the "2012-02/2012-02" Argument format automatically

This needs to be addressed as a bug I believe.

If I create blocks with summary lists for year and month, the resulting arguments created by views and date are 2012/2012-02 which do not work. I cannot create a block that breaks down from year view to month view to day view that creates the proper arguments for the date "2012-02" format. The navigation does not work and there in no filtration on the resulting page. All values are shown instead.

I do not see a way of creating a block to list year, then month once clicked, using the date "2012-02" argument format.

So not only does the "2012-02" format break hackability of the urls it also is not used by views to create to proper arguments for "date module". Multiply views arguments wants to create "2012/02" formats not "2012-02/2012-02" formats.

KarenS’s picture

Category: bug » feature

This is not a bug report, it is a feature request. It is not a 'bug' that Date decided to handle things differently from Views. I personally don't like format that omits the dashes, it is much harder to read.

kingbbq’s picture

I was in need of the event/2011/11/15 - I migrated from Drupal 5 to 7, and google still tries to spider old URL.

1) On the second date filter check the box "Specify validation criteria"
2) Under Validator choose php code.
3) Add this php code

$url = explode('/',$_GET['q']);
$date = $url[1].'-'.$url[2].'-'.$url[3];

$handler->argument = $date;
return TRUE;

It grabs the URL Parts and translated into a views-readable date format.

jrglasgow’s picture

I had this as a requirement for a client as well and this is the code I used for the PHP validation criteria.

<?php
if ($argument == $view->args[0]) {

  if (empty($view->args[1])) {
    // we need a date range for the month
    $date = date('Y-m-d', mktime(0, 0, 0, 1, 1, $view->args[0])) . '--' . date('Y-m-d', mktime(0, 0, 0, 12, 31, $view->args[0]));
    $handler->validated_title = date('Y', mktime(0, 0, 0, 1, 1, $view->args[0]));
  }
  else if (empty($view->args[2])) {
    // we need a date range for the day
    $date = date('Y-m-d', mktime(0, 0, 0, $view->args[1], 1, $view->args[0])) . '--' . date('Y-m-d', mktime(0, 0, 0, $view->args[1], date('t', mktime(0, 0, 0, $view->args[1], 15, $view->args[0])), $view->args[0]));
    $handler->validated_title = date('F Y', mktime(0, 0, 0, $view->args[1], 1, $view->args[0]));
  }
  else {
    // we have arguments for year/month/day
    $date = implode('-', $view->args);
  }
  $handler->argument = $date;
  return TRUE;
}
else {
  return false;
}

?>

If you use this ignore the <?php and ?>

This has the virtue of not using $_GET['q'] so the page you are on doesn't matter and it works on the View edit page in the preview whereas the $_GET['q'] doesn't.

luco’s picture

@KarenS how much work is involved in creating custom contextual filters?

something like in the token system.

luco’s picture

@KarenS I understand you put a lot of effort on developing and maintaining Date module. it's a great module - one of the few that always come to mind on fresh installs - and I'm grateful for it.

having said that (and I don't mean to come across as rude) but I think you go a long way to maintain features that people end up not using, all the while discarding others as stuff you "don't like" or that you consider a "regress" without thinking twice.

now I'm not saying you should disregard certain features, but there is a lot of community request for something like a single date part views argument. I've seen others ask around for something like that since as early as 2008.

plus we all know it's feasible and I for one would happily write a Date submodule to handle that - if I could already. so why not just go ahead and do it, instead of wasting time arguing here on D.O.? I mean, it's not like you asked for more complete use case scenarios before ruling that off.

and frankly, have you honestly never been stuck asking for something you weren't capable of accomplishing yourself in any open source community, and being questioned over its utility? how did that make you feel?

David_Rothstein’s picture

@luco, I don't see why you think anything has been "discarded" in this issue??... The issue is open as a feature request for anyone who wants to implement it.

In the meantime, I found it possible to get this working by configuring a single date argument on the view (with granularity equal to the smallest value you need to be able to filter down to, e.g. day if you want the URL to filter down to day), then adding a hook_url_inbound_alter() implementation along these lines (code would be slightly different for a view at a different URL; mine is at "blog/...."):

/**
 * Implements hook_url_inbound_alter().
 */
function MYMODULE_url_inbound_alter(&$path, $original_path, $path_language) {
  // Allow paths like "blog/2013/08" and "blog/2013/08/15" to be treated like
  // "blog/2013-08" and "blog/2013-08-15" so that they can work as a date
  // argument in the blog listing view.
  $args = arg(NULL, $path);
  if ($args[0] == 'blog') {
    $date_args = array_slice($args, 1);
    if ($date_args && $date_args == array_filter($date_args, 'is_numeric')) {
      $path = 'blog/' . implode('-', $date_args);
    }
  }
}

Maybe this will be helpful for others as another method to achieve this using code.

luco’s picture

@David_Rothstein,

sorry, I expressed myself poorly: what I meant is, if KarenS doesn't want to fulfill a certain feature request, she can simply ignore it - or even mark as "won't fix" if it's in the issue queue of a module maintained by her.

the problem is when we ask for a certain feature that we'd like to see, or need, and have to put up with a reply like "you don't need that, here's this other thing instead" which doesn't satisfy a certain use case scenario.

it's uncalled for, especially since no one (myself included) questioned the quality of her work or the generosity of her contribution.

anyway, I'd like to take the opportunity to invite everyone to try out the TARDIS module I wrote. it takes year and month arguments, and you can use it to build several blocks and pages with lists of nodes filtered by type. it's got other features as well, so please give it a try and let me know what you think. :)

arh1’s picture

@David_Rothstein: your code in #20 works well for me -- thanks!

Can anyone lend any insight into how to create the view/display that would provide these URLs, though? In my case, I'm trying to generate a list of distinct year-months with links like yyyy/mm (which can then be interpreted by the code in #20 above and handled by the content-listing view). If I use the "Date: Date (node)" contextual filter, I can't figure out how to generate the distinct year-months, but if I use the "Content: Created year + month" contextual filter, I can't figure out how to override the yyyymm-style links (mucking with hook_views_pre_render w/o success yet).

David_Rothstein’s picture

Glad it helped!

In our situation we used the standard contextual filter associated with the date field (i.e., I think the same as your "Content: Created year + month") but so far at least haven't had to worry about the yyyymm-style links since we're generating those links on our own elsewhere, not having them output anywhere as part of the view.

The best place to alter them in the view might depend exactly where the view is rendering them, so unfortunately I don't have any good advice on that myself.