Event views not working properly

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

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.

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.

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.

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

and the other one.

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 :)

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

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

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.

#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.

Yes! That did it, Krotty.

Thanks, everyone.

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

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.

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 :)

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.

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')
  );
}

Here is the patch, as promised.

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.

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...

***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.

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.

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!

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

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

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.

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.

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.

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).

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

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

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.

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.

Works for me. Thanks.

thanks, applied!

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

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.