daterange doesn't work with Views 1.6 - filters form is malformed

I have also had trouble with the beta: http://drupal.org/node/141358
The 5.x-1.4 code from april is working on views 1.5, so clearly a value that was there before is now missing.
Does anyone know if this is still present in the dev version from june?
Help is appreciated.

All i could find is this code, on daterange.module:

function _daterange_form_alter_views_filters(&$form) {
  // fill in dates for preset operators
  // NOTE: this needs to be done again because $filter isn't passed by argument
  // in views_handler_filter_between_date
  foreach ($form as $name => $field) {
    if (substr($name, 0, 6) == 'filter') {
      if (isset($field['date1']['#daterange'])) {
        $index = drupal_substr($name, 6);

$index is needed for the form to work properly, but the "note" throws some light on it.
It looks that the names of the exposed filters have changed, so perhaps all that is need is in the forms api.

I've added this little line in my module (my daterange is the first filter):

<?php
$form['filter0']['#tree'] = TRUE;
?>

I guess this line can and should go in daterange.module.

The Views 1.6 official release is out now, and this problem still persists. Is anyone working on a patch for daterange?

I'd love to benefit from the rest of the updates made between views 1.5 and 1.6 but I need the daterange filters to work, so I backed down to views 1.5. I really miss those tabs!

Jen

I'll try to get do it today/sometime this week.

subscribing

subscribing as well.

subscribing as well.
thanks

We also need to fix up the javascript to use the newly created DOM object once the #tree is introduced. I've bumped this to "critical", but I'll stop giving estimates on when it will be fixed -- hopefully soon.

subscribing....

I'm not really familiar with the CCK/Views API but I've come up with a hack that makes daterange.module work for me with Views 1.6. I also don't know JS at all so I haven't fixed daterange.js. This patch works for me, except that after submitting the form both date fields are displayed regardless of whether that makes sense for the selected search operator. In the case of operators such as 'within the past X', the two fields are displayed with the appropriate values, but for 'before' and 'after' the second field is displayed with whatever was in it before, possibly some garbage value which is likely to confuse users. I believe this can be fixed by somehow invoking dateopOnChange() via addLoadEvent() but I couldn't get it working (as I said, I don't know JS).

At any rate, everything else is working for me now.

Hmm, you're patch file isn't standard. I can't tell which lines were added and/or deleted. Can you reupload it using the See Creating Patches documentation? I've got a big part of this done, maybe we both have different pieces done, and when we combine our two, it will be complete.

Thanks for the tip on preferred patch formats, douggreen. Here's a better patch, which also fixes some problems with the last patch I submitted. In particular, default values for date1 and date2 are now displayed correctly. I haven't been able to break this in my own testing, although the issue I mentioned before re: daterange.js still applies.

hello,
I try this patch,but I got this error

warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in C:\AppServ\www\aaa\sites\all\modules\daterange\daterange.module on line 204.

thank you very much.

nobody1225, I've made a small change to the patch which will hopefully resolve your problem.

However, I should note that this patch is still a quick hack and may well break your site. I've accordingly changed the status of this issue to 'patch (code needs work)' to indicate more clearly that it's by no means ready for production. It was meant more in the spirit of helping douggreen and other developers brainstorm possible approaches to this problem. (That said, it's working for me.)

cool.
this patch is ok.
thank you very much.

I've combined the latest patch, with my jscript changes, and checked it in. Please checkout the latest dev branch and make sure it works.

I'm still getting htmlspecialchar warnings when this is used within a views_filterblock. But I'm not sure if the problem is with daterange or VFB.

I've discovered a serious error with my patch; it assumes the daterange filter is the first filter in the form. I've attached a small patch against the latest dev branch which doesn't make this assumption. It works for me but I haven't actually tested the JS changes (since I'm no longer allowing the user to chose the filter operator); sorry.

FWIW I'm using this via views_filterblock and see no warnings from htmlspecialchar or anything else.

I committed something very similar to mvc's last suggestion. I haven't tested it. I'll mark the ticket as fixed once someone tests and confirms that it works.

I tried to install both the stable and the dev version of daterange together with views 1.6 and this is my feedback on using daterange as an exposed filtered with unlocked operator:

* old version - the range search doesn't work, but the two from/to fields are filled correctly when I choose, for example 'within a week'
* new version - the range search does work, but the from/to fields are not filled anymore, so the 'within a week'-like searches do not generate the correct ranges anymore.

a new version which correctly fills in the fields should do the job

Can you refresh your page and test again, because I think this is working for me. I ask you to refresh your page because there was a change in the javascript file that might not have downloaded to your browser.

Got the 12Oct version and tried as suggested. It almost works. If I choose within a week and submit the form, I get the form back with the range fields filled (but wrong results) - If I click submit again, then the range fields trigger the correct results. I guess the field range could be filled by js on the client side before submitting the form.

Apologies. I had some weird problem loading javascript (as you predicted) from the modules directory. I fixed it and everything seems to be working. Cheers!

I'm closing this ticket. A new version is now available! Thanks everyone!