It doesn't look like there is an issue for this, yet, so I'm creating one so there's a "paper trail". Event views does not work with V2 due to the change in how dates are handled. cassj is working on the problem.

Michelle

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

Michelle’s picture

Update... cassj can't work on this as she is busy with her PhD. Is anyone able to get this working?

Michelle

TheFazz’s picture

i recently updated my "event" module to 5.x-2.x-dev version (from 1.x-dev version).

in doing so, i get problems in viewing event nodes using the "views" module... "views" module is unable to pick the right event date and instead picking 1 Jan 1970. you can see the views working (or not working) here, or go to this link:

http://club.my-kart.org/comingevents

appreciate the help here.

alternatively, how to i downgrade back to 1.x-dev version given that the 2.x-dev version had upgraded the database tables already?

fazz

Michelle’s picture

Considering this issue is about how views don't work with V2 of event, I'm not sure what more you're wanting?

As to downgrading, I wouldn't recommend it as all your dates would be messed up. If you want to go back to V1, you'll need to restore your tables from a backup.

Michelle

TheFazz’s picture

Title: Event views not working » Event V2 not working properly

I believe it is the V2 that is not working with Views. there has not been any major change to Views..... but when Event-V2 was installed, it caused a number of errors... including Views. in fact, there is an error message issued prior to login.

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'HAVING (event_start >= '2007-07-01 00:00:00' AND event_start <= '2007-07-31 23:5' at line 1 query: SELECT DISTINCT(n.nid), n.uid, n.title, n.type, e.event_start, e.event_start AS event_start_orig, e.event_end, e.event_end AS event_end_orig, e.timezone, tz.offset AS offset, tz.offset_dst AS offset_dst, tz.dst_region, tz.is_dst, e.event_start - INTERVAL IF(tz.is_dst, tz.offset_dst, tz.offset) HOUR_SECOND AS event_start_utc, e.event_end - INTERVAL IF(tz.is_dst, tz.offset_dst, tz.offset) HOUR_SECOND AS event_end_utc, e.event_start - INTERVAL IF(tz.is_dst, tz.offset_dst, tz.offset) HOUR_SECOND + INTERVAL 0 SECOND AS event_start_user, e.event_end - INTERVAL IF(tz.is_dst, tz.offset_dst, tz.offset) HOUR_SECOND + INTERVAL 0 SECOND AS event_end_user, e.event_start - INTERVAL IF(tz.is_dst, tz.offset_dst, tz.offset) HOUR_SECOND + INTERVAL 28800 SECOND AS e in /home/mykart/public_html/drupal5/includes/database.mysql.inc on line 172.

Michelle’s picture

Title: Event V2 not working properly » Event views not working properly
Component: Code » Event Views

Please don't take the important part out of my title. It's the event views module that is not working.

Michelle

TheFazz’s picture

sorry. shall i create another issue for event V2 not working... it is not just the views. but it causes an ugly error message before login. i suppose this is a symptom of something else that is wrong with event V2.

Michelle’s picture

Event V2 is still in active development. There are a lot of issues with it. I don't remember seeing that error filed as an issue, so please do make an issue for it.

Michelle

kevin francis’s picture

FileSize
2.05 KB

Made a patch to correct the problem by implementing views_handler_date_*_iso() functions that rely on event_format_date() instead of format_date().

Now views.module interprets the new ISO date format properly. Tested and patched against drupal-5.2, views-5.x-1.6 and event-5.x-2.x-dev.

Michelle’s picture

There used to be two patches... One for event.module and one for event_views.module. This one looks like it's for event_views. Is the other one not needed anymore? I tried applying this to event_views and there was no errors but still no luck getting the default view "event_select" to work.

Michelle

killes@www.drop.org’s picture

Status: Active » Needs review
FileSize
1.09 KB

here are the two patches Frnacis sent to me in the mail.

killes@www.drop.org’s picture

and the other one.

KarenS’s picture

I have not tested the patches, just looked at them, but here are my comments:

1) I wonder about putting the handlers into event.module instead of event_views.module. All other things related to views are in the other file and I can't see any reason for this. (Unless there is some thought that these handlers would be used elsewhere).

2) This method looks like the right way to get the date displayed properly, but doesn't address getting filters and arguments and sorts working, which will be much more complicated. But it's a start :)

killes@www.drop.org’s picture

Status: Needs review » Needs work

I agree with both things you said, Karen. I've committed the two patches to event_views.module, so they get some exercise.

bluecobalt’s picture

i pulled event_views.module out of cvs, and its still showing Dec 31 1969 for me.

kevin francis’s picture

I'll test the code more thoroughly and address any functionality I missed testing/patching earlier. Hopefully by the end of today I'll have a complete patch for review.

Krotty’s picture

#14 submitted by bluecobalt on August 24, 2007 - 01:39
i pulled event_views.module out of cvs, and its still showing Dec 31 1969 for me.

You must change field handler in table view_tablefield from 'views_handler_field_date_*' to 'views_handler_field_date_*_iso' for existent event records.

bluecobalt’s picture

Yes! That did it, Krotty.

Thanks, everyone.

kevin francis’s picture

Just in case anyone is anxiously awaiting this patch, I'll be finishing it by Sunday. Sorry for the delays.

KarenS’s picture

I'm not sure you need a patch. Any time you change the way Views works, you also need to go into Views and repair any views that used that code. So when you pull up your view, you will see a field or filter with no name (that's the one that used the old code) and you must delete that broken item and put in the new version of the field or filter. Then save your view.

I didn't think of this implication when I reviewed the code earlier, so sorry about that, but again, no patch needed, just edit your view and save it and all should be well.

Michelle’s picture

Karen - The view that is broken is one of the default ones that comes with views, so saying edit and resave doesn't work in that case. Sure, you can "add" it to edit it but that's going to be confusing to new people if a default view doesn't work out of the box.

In addition, I re-did one of my event views the other day to add a filter on "now" and that doesn't work, so there's definitely something more wrong.

Michelle

KarenS’s picture

Right, the default view must be fixed, I missed that.

The comment above talked about making changes to tables via a patch, so I was afraid someone was trying to make a patch to alter the tables directly.

And I never thought this was the complete solution to fixing views, there is lots of work yet to be done. In retrospect, my comment was confusing, so sorry about that. I'll keep quiet now :)

Michelle’s picture

Karen - No need to keep quiet. Your input is valuable. I think the confusion was with krotty and bluecolbalt's side discussion which, afaik, has nothing to do with Kevin's patch. Kevin is working on getting event_views working with the date format change, not making a patch to change one field in a table. Hope that makes more sense now.

Michelle

bluecobalt’s picture

Actually Michelle, the discussion between krotty and myself is directly related to this thread.

The changes made to event_views.module don't have any effect, until you change field handler in table view_tablefield from 'views_handler_field_date_*' to 'views_handler_field_date_*_iso' for existent event records. Once this is done, it works fine, however, I have found that if I change the view and resave it, it erases the "_iso" from the field handler and I have to manually change it again.

This obviously needs to be addressed.

westwesterson’s picture

i dont have time to make a patch right now, but i got the fields to work properly once I added this code and changed the handlers on event_start (ln 58) and event_close (ln 65) from views_handler_field_dates() to views_handler_field_dates_iso().

 /**
 * Provide a list of all standard supported iso date output handlers.
 */
function views_handler_field_dates_iso() {
  return array(
    'views_handler_field_date_small_iso'  => t('As Short Date'),
    'views_handler_field_date_iso'        => t('As Medium Date'),
    'views_handler_field_date_large_iso'  => t('As Long Date'),
    'views_handler_field_date_custom_iso' => t('As Custom Date'),
    'views_handler_field_since_iso'       => t('As Time Ago')
  );
}
westwesterson’s picture

FileSize
1.74 KB

Here is the patch, as promised.

Mac Clemmens’s picture

I'm still having difficulty with the "Event: Start Date" filter when I put "now" in place of the date. Are the new handlers able to process this and other strtotime() expressions?

BTW nice work on the patch, westwesterson! :) It did the trick for me.

Mac Clemmens’s picture

Could the culprit be line 195?

function event_views_handler_filter_timestamp($op, $filter, $filterinfo, &$query) {
  $value = $filter['value'] == 'now' ? "***CURRENT_TIME***" : strtotime($filter['value']);
  
  $field = $filter['field'];
  if ($filterinfo['from_unixtime']) {
    $field = "from_UNIXTIME($field)";
  }
  $query->add_where("%s %s (%s + %d)", $field, $filter['operator'], $value, $filter['options']);
  $query->ensure_table('event');
}

The query
$query->add_where("%s %s (%s + %d)", $field, $filter['operator'], $value, $filter['options']);

gets executed with these values:
$query->add_where("event.event_start > (***CURRENT_TIME*** + 1)");

What is ***CURRENT_TIME*** and is it getting interpreted into ISO format? Right now it seems like it's getting translated to zero or Dec 1970...

KarenS’s picture

***CURRENT TIME*** is a views runtime substitution. See views_views_query_substitutions(). The problem is views is turning it into a timestamp which doesn't work here. You may have to define a different runtime substitution that will create a datetime value instead of a timestamp.

KarenS’s picture

Do something like this (I'm not where I can test this):

/**
 * Substitute current time; this works with cached queries.
 */
function event_views_views_query_substitutions($view) {
  global $user;
  return array('***CURRENT_DATETIME***' => gmdate('Y-m-d H:i', time()));
}

The use '***CURRENT DATETIME***' instead of '***CURRENT TIME***' in your code.

Mac Clemmens’s picture

The problem is that now isn't working... I tried a handful of combinations, but the "Event Start / Event End" date filters just don't seem to want to work. Right now, I'm trying "Event: Start Date" "Is Greater Than" "now" and it just shows me all events. This would only be logical if "now" was interpreted as zero or equivalent. Any ideas for a patch or quick fix? Thanks!

KarenS’s picture

I'll try to look at this tonight. Can't do it now, my computer battery is just about to give out :)

Mac Clemmens’s picture

Yikes! No problem. Thank you so much for your help and your great work on these modules.

KarenS’s picture

Status: Needs work » Needs review
FileSize
9.07 KB

Here's a lot of the changes that are needed. Not tested yet, but the code is getting close to where it should be. The following are added/changed:

1) The previous addition of views_handler_field_date_iso() etc should not be using the views namespace. That functions used originally are the ones created by Views, which assume that dates are timestamps. We have to create a different version for Event Views that treats dates as datetime values. Since these are Event Views functions, they need the Event Views namespace.

2) We had to create an Event Views version of views_views_query_substitutions(), since that substitutes in a timestamp, not a datetime value. So event_views_views_query_substitutions() was created. We use ***CURRENT_DATETIME*** instead of ***CURRENT_TIME***, which is the Views version that will create a timestamp. The 'now' filter uses this to do a runtime substitution of the current time in the filter.

3) We had to create a datetime version of views_handler_filter_timestamp() since we no longer want a timestamp.

4) We had to get rid of from_UNIXTIME($field) in the filter query, since we don't have a timestamp any more.

I'm not completely sure I found all the places that are assuming a timestamp instead of datetime field, but that's what you need to look for. Also anything that is standard Views date handling needs a substitution, since Views date handling is based on timestamp dates.

westwesterson’s picture

just curious, but shouldn't this datetime handling go into the views module, so that other projects can potentially use datetime instead of timestamp too? It's great that this development is going on in event views, but it just seems like something that would be useful to every module, not just event views. That's just my 2 cents though. I think this development is great. And your right, it should have the event views namespace, just gave it the same namespace as the other handlers, it really should all be changed to event_views if it stays in this module.

KarenS’s picture

At this point, there are no modules other than the event module using datetime fields. The Date module will probably add it in, but the Date module has to have its own Views handlers anyway. Plus if you try to get it into Views, this module won't work until if/when Views gets patched, and that might be further delayed because Earl is working on Views 2.

So I would keep the handlers in this module and use the Event Views namespace.

westwesterson’s picture

After further review of the code, (since this still doesn't work) I'm wondering if this has to do with the use of strtotime on line 195 which returns a unix timestamp if not set to now. (now is still not working either).

westwesterson’s picture

FileSize
9.78 KB

upgrade to KarenS's patch to change forgotten ***CURRENT_TIME*** to ***CURRENT_DATETIME*** for the default view. Hopefully this saves potential problems later.

altparty’s picture

I tested the patch. Everything's fine except the 'now' option.

altparty’s picture

I have to restate my conclusion...
Using the filter for 'event start date' doesn't work. It results in 'no events found'.
I would be very thankfull if someone finds the resolution to this problem.

anarcat’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
6.05 KB

I have worked a bit on this patch to make it work with "now". Not sure I used the right approach... but It Works Here.

Note that I have removed the whitespace diffs from the patch.

I'm putting this as ready to committed because I reviewed the patch and it works.

altparty’s picture

Works for me. Thanks.

Gerhard Killesreiter’s picture

Status: Reviewed & tested by the community » Fixed

thanks, applied!

anarcat’s picture

I confirm the fix is in the latest tarball. Thanks!

Anonymous’s picture

Status: Fixed » Closed (fixed)

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

HiredGuns’s picture

Component: Event Views » Code

FYI

When I applied this patch to 5.x-2.x-dev, the patches broke the module. After banging my head against the wall for all of the day, I installed the 5.x-2.x-dev version of http://drupal.org/project/event_views. This cleared it up for me. I would try the above first, but you might find my solution helpful.