smallbeer - you’re right. Looks like they changed the strtotime() function with PHP 5 (it used to return -1 on a bad date). Should work with PHP 5 now as well - let me know if you still don’t see errors.
Sue - oops. I should have that fixed now as well.
New version 1.2.1 in the original post.
You’re correct though Sue - I’m not doing anything with the calendar itself, just modifying the date before it gets entered. If you manually enter a similar date, it should display the same issue - that would be a good test. It might be worth starting a thread in tech support for this issue?
I’m a tad slow I think. What exactly are we supposed to enter in the settings fields?
By default you don’t have to use any of the settings at all - it works on all date fields in the system. The settings are for behavior different than the default behavior.
By default, if no year is given in a date field, the current year is used (2007 right now). By default, if no time is given in a date field, 12:01 AM is used. Otherwise it just uses whatever you put into the field.
The settings are for changing that default behavior. If you want to force a future date for a certain field, put the field name you’d like to force into the future in the “Thinking Long Term? (force future date)” field. For example, say you have a field named ‘application_deadline’ that should always be a date in the future. You put that field name in the “Thinking Long Term” setting field. Then if someone enters either no year, or a previous year, it will change that year to the upcoming year. If today is March 25, 2007, and someone enters March 26, 2007 then it leaves it alone - but if they put March 26, 2005, the resulting date would be March 26, 2007.
Any field name you put in “punctual to a fault” will be forced to use 12:01 AM for the time, no matter what time is actually entered.
Any field name you put in “disastrously late” will be forced to use 11:59 PM for the time, no matter what time is actually entered.
Any field name you put in “fashionably late” will use whatever time is entered into that field, but if no time is entered, will use 11:59 PM (remember the default behavior is to use 12:01 AM).
Does that make sense? None of them are mandatory settings - but if you want a certain field to behave differently than normal, that’s what they’re there for.
Hmmm, I’m getting the same error Sue identified a few posts back I think. It seems to only happen when trying to update the expiration_date field; changing the entry_date works fine.
DEA are you using the newest version? 1.2.2?
Could you give the exact error? Are you sure it is the same?:
Notice: Undefined variable: date_fields in /path/to/blind_date on line ???
Thanks 😊
Hey there, here it is:
Notice: Uninitialized string offset: 0 in /var/www/vhosts/domain.com/httpdocs/system/extensions/ext.blind_date.php on line 95
Notice: Uninitialized string offset: 0 in /var/www/vhosts/domain.com/httpdocs/system/extensions/ext.blind_date.php on line 96
Notice: Uninitialized string offset: 0 in /var/www/vhosts/domain.comom/httpdocs/system/extensions/ext.blind_date.php on line 97
Notice: Uninitialized string offset: 0 in /var/www/vhosts/domain.com/httpdocs/system/extensions/ext.blind_date.php on line 98
Warning: Cannot modify header information - headers already sent by (output started at /var/www/vhosts/domain.com/httpdocs/system/extensions/ext.blind_date.php:95) in /var/www/vhosts/domain.com/httpdocs/system/core/core.functions.php on line 296
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.