Posted by pandikamal on July 23, 2012 at 5:54am
10 followers
| Project: | Date |
| Version: | 7.x-2.x-dev |
| Component: | Date API |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
hi,
i'm getting the following error and also its broken my site.
Fatal error: Call to a member function getName() on a non-object in E:\wamp\www\drupal7\sites\all\modules\date\date_api\date_api.module on line 278
Comments
#1
There is no way to do anything with a random error message and no information about how to reproduce. There is no such error on a clean install, so you have some other module enabled that is causing this, probably.
Do all the usual debugging steps -- try it on a clean install, if you can't reproduce it there it is some other module. Add other modules to the clean install to try to identify which one triggers the problem. Try the dev version and see if that takes care of the problem. If so, it's already fixed.
#2
No response. Closing.
#3
This happens whenever I programmatically create a DateObject.
#4
This is probably the same error I am getting: Fatal error: Call to a member function getName() on a non-object in /home/barriear/dev/public_html/sites/all/modules/date/date_api/date_api.module on line 286 (the line number is slightly higher)
In my setup I have selected the date contextual filter, and the error happens if I configure the filter 'Dates to compare' to 'Only this field'.
I do have an 'End date' for the field in question that is optional and can be NULL. I am not sure if this is the source of the problem.
#5
Per #3, "This happens whenever I programmatically create a DateObject." Not enough information to reproduce the problem. There are dozens of possible ways you might create a date object and values you might try to put into it, no idea what you tried to do.
Per #4, "configure the filter 'Dates to compare' to 'Only this field'" apparently refers to some filter I've never seen that is not a part of this package. If you have a problem using another module, you should report an error there. If that's not it I need more information about what that filter is.
Either way, none of the reports here have information that would make it possible for me to reproduce the error, nor is there any error on a clean install using only the Date module, as far as I can see.
#6
In the sentence that you quoted, a bit earlier I say this: "I have selected the date contextual filter". The quote you are refering to is talking about the configuration options of that filter. Upon investigating this further I now realize that I had made the mistake. The issue belongs to a different module that is also of your authorship: 'Calendar'. I will close this issue and post it in that queue. Again, thanks for your time to take to investigate this.
#7
Small update. I can't seem to reproduce the error with a clean install, so it'll take a bit more digging to explain what's been done to cause the issue. Suffice it to say that it happens at least some of the time, and if that's the case, we can be sure that there is 'something' to resolve. That said, time is obviously a valuable commodity, so I will do what I can to weed this out. All in all, I believe the problem lies somewhere within the calendar module.
#8
Sorry, I too can not specify the steps to replicate. It shows up occasionally when doing AJAX calls on non-date fields.
We have a massive complex system and of the 50 + times I have saved this particular content type, the issue has only arisen once for me, but AJAX errors have also been reported by the client.
Anyways, there is a logical error here:
<?php
// If this tz was given as just an offset or the timezone
// was invalid, we need to do some tweaking.
if (!$this->getTimezone() || !preg_match('/[a-zA-Z]/', $this->getTimezone()->getName())) {
// If the timezone name is an offset and the original
// $tz has a name, use it. This happens if you pass in
// a date string with an offset along with a specific timezone name.
if (!preg_match('/[a-zA-Z]/', $this->getTimezone()->getName()) && preg_match('/[a-zA-Z]/', $tz->getName())) {
$this->setTimezone($tz);
}
// If we get this far, we have no information about the timezone name,
// but we will get undefined index errors without any name.
else {
$this->setTimezone(new DateTimeZone("UTC"));
$this->errors['timezone'] = t('No valid timezone name was provided.');
}
}
?>
ie.
!$this->getTimezone()is followed directly by$this->getTimezone()->getName().So I guess this should be as either $this->getTimezone() is NULL and the second test has already failed:
<?phpif (preg_match('/[a-zA-Z]/', $tz->getName())) {
$this->setTimezone($tz);
}
?>
?>
#9
I wonder if the Migrate Tests should be dropped until someone can get these working again...
#10
lol, I have managed to trace this slightly better. It appears to be a '#limit_validation_errors' error and date repeat element #element_validate is triggering and all hell lets loose... well, some notices are thrown followed by a fatal error. (edit: I's laughing as '#limit_validation_errors' has been causing me a bit of grief in miscellaneous modules over the last couple months...)
To replicate (I haven't tried a clean install)
Note, I just tested using different time components with the same date component; From "2013-05-20 11:00 PM" to "2013-05-20 12:30 PM".
Warning: date_timezone_set(): The DateTime object has not been correctly initialized by its constructor in date_repeat_build_dates() (line 426 of sites\all\modules\date\date_repeat_field\date_repeat_field.module).Which would be followed by a fatal error if it wasn't for the above patch.
A couple of dpms() here showed that the validated date values were a mix of strings, an array and a DateTime object and this is where I stopped debugging as I would not have a clue where the values are being set, nor what values are correct. Having three different date structures appeared wrong.
<?php$item = drupal_array_get_nested_value($form_state['values'], $element['#parents'], $input_exists);
$input = drupal_array_get_nested_value($form_state['input'], $element['#parents'], $input_exists);
dpm($item);
dpm($input);
?>
The position of the fatal error is way down the list of notices, about the second last.
[edit] Forgot to mention that file_ajax_upload() was the page callback that triggered the notices, (an image field remove button)
#11
I got the same error message when trying to export a calendar with the date_ical module. (The calendar was using a custom date field, which I *think* is important for this bug.)
Anyways: The patch in #8 solved the problem for me. Yay!
I'm not sure that this one test is enough to mark RTBC, but I'm giving it a try.
#12
Alan D.'s patch (#8) is correct: we are constructing a date and its timezone, so acting upon $this->getTimezone() is inappropriate here.
I have a very simple test. The first line below is OK, the second line gives the error. (OK, it might not be in date_api's normal timerange....)
$date = new DateObject('23:00');$date = new DateObject('24:00');
In this case, the $tz timezone is set in line 210:
elseif (empty($tz)) {$tz = date_default_timezone_object();
}
#13
patch #8 works for me perfectly!
#14
There are 4 rtbtc's so far for this simple patch that prevents a fatal PHP error in multiple different use cases.
Maintainers?
#15
The first time I read through #8 I could see that it would fix the fatal error, but it wasn't obvious to me if it was the correct fix or merely deleting the code that was causing the symptoms, whatever the consequences.
Taking a closer look I can see that it is in fact the correct fix, but I don't think the comments explained what was happening very clearly. I've attached a new patch which makes the same changes, but replaces the comments in this section. To me they key point is that the outer if() detects incomplete data, and the contents do their best to complete that data.
Hopefully this makes the patch easier to review so we can get it committed.