This is the most wicked bug I've hunted down in a long while. It took its time, but finally I found what exact situation caused my site's cron to stop working and most pages to do the same. Any page that tried to load cron or show content related to certain nodes (with a given Views block, pretty much any page except admin pages) showed a totally blank white page. No HTML, nothing.

After playing back and forth from backup, I found out that this wasn't caused by Feeds that I had been experimenting with - not exactly. I was attempting to set up a feed parser that creates nodes based on a feed, and sets the date field of the node by REGEXing it from the feed's description field that included other information as well. As this wasn't working yet, Feeds imported nodes and saved the rest of the description in the date field as well.

With Date 7.x-2.0-alpha4, this was not a problem. Everything functioned as if the date field was empty. After updating to 7.x-2.0-alpha5, the white page of death ate cron and non-admin pages of the site. After deleting the imported nodes that had garbage in the date field, everything returned to normal.

Alpha4 seemed to ignore the field value if it wasn't in the correct format. In alpha5 no warning is given; instead cron and the pages that try to show this field fail in the most nondescript way. I feel some checks should be in place to graciously handle incorrectly formatted data in the date field and give the site admin a warning if appropriate.

Comments

karens’s picture

karens commented
Category: bug » support

Unless you provide a way to replicate the situation, there is nothing I can do with this. If you import values into date fields (or any other kind of fields), you need to validate the information you import. That has always been true. So the fact that you forced invalid data into those fields is not really a bug in date, nor Date's problem at all. But if you can provide an example of what kinds of changes in Date would help, I can look at it.

karens’s picture

karens commented
Status: Active » Postponed (maintainer needs more info)
Daedalon’s picture

Daedalon commented

I believe the problem of how Date 7.x-2.0-alpha5 crashes from erroneous data in the date field is replicated when you:

  1. have a View that displays date field information. In my case it was a field with a repeat option and there were both start and end dates.
  2. have non-date data in the field. In this case it included big and small alphanumeric characters and the following: /@- .,:

The cause of the problem might be the non-date characters, overlong string or something else about this non-date data. The problem is how this erroneous data is handled in alpha5: it causes a white-page-of-death on all the pages attempting to view this data and doesn't leave anything in the error log. It also caused cron to fail with a white-page-of-death, for which I have no clue why, and which poses both an inconvenience and a security problem as it's harder to track updates without cron. It also made Date field data the last on the list of suspects.

The solution would be to validate the date field data before handling it further and returning an error and/or ignoring the field if the data is erroneous. Alpha4 ignored the erroneous field, but didn't leave anything in the error log. That was preferable to the behavior of alpha5 in this regard.

I personally am now aware of the above and would waste no time solving it if it occurred on my client's site, but I want to help the rest of the community not to have to spend days tracking such a mysterious error in the future. If there's any additional information that might help you in handling this issue, don't hesitate letting me know.

karens’s picture

karens commented

There is plenty of validation if you enter data in the UI. I can't even replicate what might happen if invalid data is in there because there is no way to get it there. Tell me how you got this invalid data into those fields.

Daedalon’s picture

Daedalon commented

Through another plugin, Feeds. Details in the second paragraph of the first post. There's nothing apparent to improve in Date's validation of data when entering it through Date. Instead when retrieving the data, alpha5 is more fragile in regard to what is saved there than alpha4, which ignored invalid data instead of choking on it. A validation check when retrieving the data or simply reverting this behavior back to as it was in alpha4 would solve this type of problem.

Invalid data in a plugin's field shouldn't have the plugin kill cron and all of the site except admin panel - or even that if a View was trying to show that field also there - without at least letting the siteadmin know what's wrong through an error message. Regardless of how the data got there in the first place, the fallback of when the field data can't be handled normally is currently improvable. Something like this pseudo-code might do it:

if (!handle($data)) { // If data handling fails here, throw an error message and stop handling it further
  error_message("Date field data is invalid and cannot be handled normally. Please check the data of field ".$field." of node ".$nid);
  return false;
}

This needs to be done before the part that chokes on invalid data and causes the white-page-of-death for Views and cron with incorrect data.

Daedalon’s picture

Daedalon commented
Status: Postponed (maintainer needs more info) » Active

Setting active as further info was provided for review.

Daedalon’s picture

Daedalon commented
Issue summary: View changes

Clarified the message.