Yeap I've seen the "There is an unfortunate bug in the upgrade path from event 5 to 6. Any help that helps to fix this is greatly appreciated." I'm not sure how deep the bug goes .. but I know that running Drupal 6.19, PostgreSQL 8.3.11 and Event 6.x-2.x-dev and even if I have an upcoming event, I'm told I don't.

I've started with a fresh install of drupal and the only non-core module enabled is Event.

After some digging I end up at event_database.pgsql.inc

I grabbed the select statement from line 121 and attempted to run it direct from psql ..

"SELECT n.nid, n.title, n.type, n.status, n.changed, e.event_start, e.event_end, e.timezone, e.has_time, e.has_end_date, extract('day' from event_start - '%s')*24 + cast(substring(cast(event_start - '%s' as varchar) from ' (..):') as integer) || substring(cast(event_start - '%s' as varchar) from ' ..(:..:..)') as time_left, 0 AS days_left FROM {node} n INNER JOIN {event} e ON n.nid = e.nid WHERE n.status = 1 AND (((e.event_start <> e.event_end) AND ('%s' >= e.event_start AND '%s' < e.event_end)) OR ((e.event_start = e.event_end) AND ('%s' <= e.event_start + '%d seconds')) OR e.event_start >= '%s') AND n.type IN ($placeholders) ORDER BY event_start;

Obviously there are some things that were passed to the sql that ended up being changed ..

{node} = node
{event} = event
'$s' = now()
$placeholders = 'event'
$d = 0

I swap out those so line 121 of event_database.pgsql.inc is ..

$query = "SELECT n.nid, n.title, n.type, n.status, n.changed, e.event_start, e.event_end, e.timezone, e.has_time, e.has_end_date, extract('day' from event_start - now())*24 + cast(substring(cast(event_start - now() as varchar) from ' (..):') as integer) || substring(cast(event_start - now() as varchar) from ' ..(:..:..)') as time_left, 0 AS days_left FROM node n INNER JOIN event e ON n.nid = e.nid WHERE n.status = 1 AND (((e.event_start <> e.event_end) AND (now() >= e.event_start AND now() < e.event_end)) OR ((e.event_start = e.event_end) AND (now() <= e.event_start + '0 seconds')) OR e.event_start >= now()) AND n.type IN ('event') ORDER BY event_start";

And then I get my upcoming event appearing. Next step find out which of those variables are causing the problem .. and then why .. and then how to fix it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ibeardslee’s picture

Update:
{node} = node
{event} = event
Although two cause problems when run from psql, they seem to be fine as {node} and {event} as part of the code.

%d = 0
Life would be so much easier if I did less typos. $d should have been %d in my original post. Returning '0 secconds' to '%d seconds' seems to work fine.

'%s' = now()
Another typo in the original post. It seems the '%s' seems to be ok in the php, compared to running directly via psql.

Leaving ..
$placeholders = 'event'
That causes problems .. further investigation to be done why $placeholders is not being converted to something useful.

ibeardslee’s picture

Temporary hack to get things going .. replacing $placeholders with 'event' .. n.type .. we are talking about events here .. dunno why other node types should appear in with the upcoming events.

Will try and investigate the what the ..

$placeholders = implode(',', array_fill(0, count($types), "'%s'"));

.. line is all about at a later stage.

grub3’s picture

I can confirm this issue under pgsql.

grub3’s picture

Just for information, '%s' = now() should never used as it is SQL. Php offers time() function, which is safe to use.

rbroberts’s picture

This appears to be present also in 5.x-2.x-dev. The problem is an incorrect number of arguments in the call to array_merge(). I'm attaching a patch against 5.x-2.x-dev, but it will probably apply to 6.x, too.

See also the patch in http://drupal.org/node/970330 for PostgreSQL.

rbroberts’s picture

Oops, last patch include a left-over error_log for diagnostics. I'm redoing this with that removed.
I'll also note that I added n.uid to the select clause for symmetry with the current MySQL query.

rbroberts’s picture

Because of some other stuff I had done in the code to be able to more easily read the queries, the line numbers were badly shifted in the earlier patch. Here is the same change, but done against the original 6.x-2.x-dev code.

rbroberts’s picture

I've done some more testing and discovered that the previous patches didn't quite get it. In particular, I took a short-cut on time_left vs days_left in the query that was mostly okay, and the regex in the time_left resulted in events with less than a day left (and having a specific time) showing up as "0 minutes" rather than however many minutes or hours were left.

The attached patch is against the distributed 6.x-2.x-dev 2007-Jul-11 code

Hey is anyone maintaining this code?

rbroberts’s picture

Status: Active » Needs review

Changed status to hopefully trigger action.

ibeardslee’s picture

Status: Needs review » Reviewed & tested by the community

That patch seems to fix the problem that triggered this Bug Report. I haven't seen any other issues manifest themselves since I applied that patch.

MadOp’s picture

Status: Reviewed & tested by the community » Needs review

Hi,
I am not sure how much this is related but I could find a better coincidence with the issue I am having:
I get the same "No upcoming events" message when I access the calendar in a multilingual site.

I had loaded the events and they were showing fine in the main language, when I added the second language and access that content events are ignored, "look" like it was loading an alternative empty calentdar.

Drupal 6.20 with latest event-6.x-2.x-dev.zip (2011-02-25) running on MySql

Thanks in advance.
MadOp

japerry’s picture

Status: Needs review » Closed (outdated)

Event for Drupal 8 is unrelated to older versions. If an issue similar to this one exists, please open a new issue with the 8.x branch.