I am using the date_repeat_rrule field in a form in a module I'm writing. Upon form submission, the following occurs:

Fatal error: Cannot unset string offsets in date_api_ical.inc on line 579

When the 3 unset() are commented out, an if() following after causes this:

Fatal error: Cannot use string offset as an array in date_api_ical.inc on line 592

Timezone is -7 GMT (PDT) Vancouver, Canada. Using all defaults.

This seems to be caused by date_repeat_rrule_validate() assuming that the form values are in a tree, trying to access the non-existent key 'rrule' in its parent field, and then passing this empty variable to date_api_ical_build_rrule().

In my case, changing line 232 of date_repeat_form.inc to $item = $form_values; solves the problem.

CommentFileSizeAuthor
#9 date.repeat.patch1.1 KBAnonymous (not verified)
#8 date_repeat_rc5.patch1.07 KBfrenkx
#5 date_repeat.patch1.39 KBdwees
#2 date_repeat_errors-2.patch3.8 KBc.lam
#1 date_repeat_errors.patch3.07 KBc.lam

Comments

c.lam’s picture

c.lam commented
Status: Active » Needs review
StatusFileSize
new date_repeat_errors.patch3.07 KB

I made a patch that should account for either setting of #tree. (so, not just a 1-line change like my original solution)

It also fixes another problem I encountered, where upon form submission, _date_repeat_rrule_process() runs date_api_ical_build_rrule($element['#value']), but date_repeat_merge() doesn't perform the necessary changes to ensure that date_api_ical_build_rrule($element['#value']) gets all the values it expects, causing errors. This situation only occurs when the form that is using the date_repeat_rrule field fails its own validation, causing the form to be redisplayed.

Please review to make sure I'm on the right track. Thanks!

c.lam’s picture

c.lam commented
StatusFileSize
new date_repeat_errors-2.patch3.8 KB

This patch is the same as above, but with a fix for a typo in repeat exceptions, and a fix to keep EXDATEs together in their own array (right now, each EXDATE entry is just floating around in $form_state['values']).

kreynen’s picture

kreynen commented

I applied this patch to the latest release of Date (6.x-2.0-beta4) and it resolved the problem I had with the Bookings API.

Since c.lam maintains Bookings API, I'm assuming that's where he sees the problem as well. Are there any other modules are using date_repeat that I could test the patch with?

karens’s picture

karens commented

The Date module uses it, so we need to be sure it doesn't break that. The Event Repeat module may implement it in the future, but hasn't yet. We definitely need to be sure it will work correctly as an API. My only question is why the 'date' index isn't set to begin with, if the merge isn't creating the right results I want to fix that.

Other than that there are some minor Drupal coding style issues -- we put the 'else' part of a if/else on a separate line and all indents are exactly two spaces. And I like to avoid abbreviated variables like $v -- it makes maintenance harder - make it a complete descriptive name like $value.

I'll do some testing later today.

dwees’s picture

dwees commented
StatusFileSize
new date_repeat.patch1.39 KB

Here's a simplified version of this patch which seems to fix the issue with the BookingsAPI module.

Dave

marisco’s picture

marisco commented

I tried applying the patch in #2 to Date 6.x-2.0-rc4, and this is the result:

$ patch -p0 < date_repeat_errors-2.patch
patching file date_repeat/date_repeat_form.inc
Hunk #1 FAILED at 56.
Hunk #2 succeeded at 113 (offset 2 lines).
Hunk #3 succeeded at 161 (offset 2 lines).
Hunk #4 FAILED at 223.
Hunk #5 FAILED at 247.
3 out of 5 hunks FAILED -- saving rejects to file date_repeat/date_repeat_form.inc.rej

Is an updated patch necessary for Bookings API functionality?

Thanks!

dwees’s picture

dwees commented

Well test it out and see if it works. It is possible that this functionality has been included in the most recent version of the Date module. Unfortunately in this area the environment you are in makes a big difference to the functioning of these modules because local server timezones, etc...

frenkx’s picture

frenkx commented
StatusFileSize
new date_repeat_rc5.patch1.07 KB

The same problem still occurs in date-6.x-2.0-rc5. I created a new patch file that resolves the problem with the module Public Bookings (http://drupal.org/project/publicbookings) for me.

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new date.repeat.patch1.1 KB

This patch is not committed so far - are there any issues with it? (Reattached against 6.x-2.1) To the best of my knowledge Bookings API should ATM not need this patch anymore, but it still seems sensible to me.

Anonymous’s picture

Anonymous (not verified) commented

Is there any problem with this patch?

karens’s picture

karens commented
Status: Needs review » Postponed (maintainer needs more info)

I need an example of a way that the current code creates problems so I can assess whether or not it's still needed. The code has been massively changed since this was first posted and you said that the Bookings module doesn't need it, so I need more information to tell if there is any reason for it now, with an example of how to reproduce a problem.

arlinsandbulte’s picture

arlinsandbulte commented

@KarenS et. al.
Is this still valid?
Looks like Karen has requested additional information which no one has provided.....

arlinsandbulte’s picture

arlinsandbulte commented
Status: Postponed (maintainer needs more info) » Fixed

Status has been at "postponed (maintainer needs more info)" for 21 weeks with no one giving any additional info as requested by Karen...
I am going to mark this as fixed.....

Status: Fixed » Closed (fixed)

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