@rahulbile's http://drupal.org/project/civicrm_events implements a single FullCalendar display that will show CiviCRM Events, but that isn't a View so any filtering of the types of events you'd like to show has to be done in the module. Using the CiviCRM iCal feed has the same issue... it shows all public event. While CiviCRM Events are available in Views, the format of the date isn't the same as a "normal" Drupal date. I've started a patch to support CiviCRM Events, but I'm stuck at...

  if (isset($row->_field_data)) {
      $entity = $row->_field_data[$view->base_field]['entity'];
      $entity_type = $row->_field_data[$view->base_field]['entity_type'];
    }
    else {
      // This should never happen, but just in case.
      return $events;
    }

Can you offer any advice for accomplishing this?

Is this something you'd consider supporting?

Patch to follow..

CommentFileSizeAuthor
#2 civievents-1346246.patch2.13 KBkreynen
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented

It uses something other than Date module for it's fields?

kreynen’s picture

kreynen CreditAttribution: kreynen commented
FileSize
civievents-1346246.patch2.13 KB

Correct. In many cases, the CiviCRM Events aren't even stored in the same database. CiviCRM is designed to work with several CMS front ends, but Drupal is by far the most popular.

In this patch I've started taking the CiviCRM event data returned by the default CiviEvent view handler and reformatting to match a normal Drupal date field.

First I modified the fullcalendar_field_is_date() function so FullCalendar would recognize a CiviCRM date. Then I started working with fullcalendar_prepare_events() in theme.inc.

I think some variation of the fullcalendar_field_is_date() change would be required, but as I was working on this I started thinking the changes I was making in fullcalendar_prepare_events could actually be moved to a new module like civicrm_fullcalendar that would handle mimicking the structure of a date field.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented

It might be possible for you to write a views field handler that returns the expected data.
I just finished eliminating hard coded logic for stuff like that, I really don't want to add more back in. If CiviCRM used the drupal.org queues, I'd help on a feature request to implement this on their side...

I'm close to calling this won't fix, but I'll leave it open for a bit longer.

kreynen’s picture

kreynen CreditAttribution: kreynen commented

The Civi's dev team is likely to drop their CMS agnostic Jira workflow or drastically alter the existing CiviCRM Event view code. What I'm proposing is to create a new module to handle this. Something like the CiviCRM Events as Dates module.

I still think we'd need an exception added to fullcalendar_field_is_date(). I don't think we'd want these items fully mimicking Date fields since like gcal these items would not editable using the drag and drop method. But if the CiviCRM Events matched date array format, we wouldn't need any changes to fullcalendar_prepare_events.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented

These fields have their own Views handlers, correct? You really should be able to mock the data structure for a field that is required by fullcalendar_field_is_date().

$field->field_info is required by date_field_all_day(). It's just the result of field_info_field().

Then, mimicking the date module, define your handler with 'is date' => TRUE.

That should be enough.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Status: Active » Closed (won't fix)

I think this is best handled in a separate module. If that module then needs API changes for everything to work, please open an issue and I promise I'll be much more helpful than I was in this issue :)

rerooting’s picture

rerooting CreditAttribution: rerooting commented

I would love to see this working. Is theres a sandbox project anywhere one could jump on? This patch is not working against the current 7.x-2.x branch of fullcalendar (Civi 4.1.2) - theme.inc changes fail entirely. Theres a bunch of effort behind getting the calendar module working properly with CiviCRM 4.1.x but that doesnt seem to be working either!

kreynen’s picture

kreynen CreditAttribution: kreynen commented

Anyone looking for a solution to displaying CiviCRM Events in FullCalendar should give http://drupal.org/project/civicrm_multiday_event a try. After spending several hours trying to get this resolved by getting CiviCRM events to look like Drupal dates, I decided that it would be easier to go another direction and create CiviCRM Event from Drupal nodes and link the node and event.

sonicthoughts’s picture

sonicthoughts CreditAttribution: sonicthoughts commented
Issue summary: View changes
Status: Closed (won't fix) » Needs work

This is still not working. I don't see why this should be incompatible. What do we need to do for the field handler to integrate properly?

kreynen’s picture

kreynen CreditAttribution: kreynen commented

@sonicthoughts This was closed by the project's maintainer as 'won't fix' 3 years ago. Reopening issues like this with nothing new to contribute isn't helpful.

What do we need to do for the field handler to integrate properly?

Since you've posted to several issues I've started or contributed to and projects I maintained, I've went ahead and skimmed your posts on Drupal.org. You've described yourself as a site builder who does not want to struggle with the complexities of how things work under the hood. I would really encourage you to change the way you communicate with developers who are writing and sharing the code you are using.

Marking issues as 'needs work' and when you don't have the skills to be part of the 'we' doing the work is pretty obnoxious.

kreynen’s picture

kreynen CreditAttribution: kreynen commented
Status: Needs work » Closed (won't fix)