WSOD with PHP versions 4.x, 5.0, & 5.1 when the Date_PHP4 module is enabled.

Try the 2010-Aug-14 -dev version of Date once it becomes available.
A change made here (http://drupal.org/node/802046) was rolled back due to some critical errors (although it was not a wsod, as you report, so your issue might be different).

A wsod can be from any error, so it is possibly this error. If you can get to your logs you can check, but as Arlin says, try the latest code to see if that takes care of things.

I just rolled a new 2.x-2.6 release. Please try that one.

I updated from Date 2.4 to 2.6 without issue.
Drupal 6.19
PHP 5.2.11

What data type are your fields? I was using "Date"

@bettibio:
What is the Date Field type that your are using?
When you created the date field, you had a choice of Date, Datetime, or Datestamp.

Are you using PHP4 or PHP5? I am guessing PHP4. If so, I know what the problem is and it will only affect people using PHP4. We added a check for a valid date object and PHP4 has no idea of date objects. Running on PHP 4 is highly discouraged, there are numerous problems with PHP4. But so far we have not said we won't support it, so I need to check.

Aha! Yep, I can confirm that the update to Date 2.6 results in a wsod with the same error noted in #6 *when using a PHP version less than 5.2 & with the PHP4 module enabled*.

Starting with a PHP 5.1.6 / Apache 2.0.58 server:
Installing Drupal 6.19 & Date 2.4 (& enabling the PHP4 submodule of date), all seems OK. I added a date field to story & created a new story node.
Then, after update to Date 2.6 wsod and same error message is displayed.

So, looks like Karen is exactly right and this will only affect those using the PHP4 module.

Personally, I am in favor of dropping support for PHP4. It has been a source of many problems and could simplify support greatly. Those who still need to use PHP4 would just be limited to use Date 2.4 or earlier.
BUT, others like bettibio might disagree, and I can respect that.

(just a thought: maybe we could add a Date 3.x branch that drops PHP4. That way, the 2.x branch could continue to support PHP4 with limited bug-fix only support... just thinking out loud.)

Cross-post...

And to clarify the PHP4 thing a little (it is sort of misleading):
Actually, the issue is not PHP4, but rather anything before PHP5.2.

If you are using a version of PHP earlier than 5.2, the PHP4 module should be enabled to provide some wrapper date functions missing in those versions.

So, as I confirmed above, the root cause of your wsod issue *IS* your version of PHP.
The easiest fix for this issue right now would be to update your version of PHP to 5.2 (at least from the date module maintainer's viewpoint :-). I am using PHP 5.2.11.
Or, perhaps, a solution can be found to satisfy both older & newer versions of PHP (you'll have to wait for a patch & commit & release)

I'm going to flag this as a PHP version issue.

Another confirmation, running PHP 5.1.6 with the PHP 4 module enabled. WSODs on any of my calendar views.

Ditto on PHP 5.1.6. 6.x-2.4 works but 2.6 gives me a WSOD.

Subscribing.
Same issue with running under PHP 5.1.6 and PHP 4 enabled.

Rolling back to version 6.x-2.4 for now until a solution becomes available.

In the meantime, is it possible to add a note to the project description that builds over 2.4 require 5.2 or higher?

Renaming for clarification.

Note, if you are running PHP5.2+ Date 6.2.6 should work properly (without the date_php4 module, which should be disabled).

I'm kinda curious as to why the major version wasn't bumped up when the jquery ui library became mandatory. 6.x-2.4 could have been "legacy support" for us unfortunate souls stuck on older versions of php and 6.x-3.0(& 3.1) could have continued on. Certainly would have given me pause before updating. You don't expect major changes like this from a patch version.

I have had this same problem with a pair of "date_make_date" and "date_format_date" functions.

The function "date_create" in date_php4.inc (called from "date_make_date") creates a date object of class "StdClass", while the function "date_format_date" in date_api.module requires a date object to have a class of "DateTime".

If you cannot upgrade to PHP 5.2 (which I can't), the problem can be resolved by commenting out the test on lines 655 to 657 of date_api.module. While this is not good practice, it does allow continued operation, and should not have any additional side effects as the DateTime class does not exist prior to PHP 5.2 (I guess it could be defined if PHP 5.0 or 5.1 are being used).

I can't thank you enough for your post. Fantastically simple solution!

Cheers,
Andrew

Thanks jlscott, that worked great. A more permanent solution would be to have it check the php version as well, something like:

if (phpversion() >= 5.2 && get_Class($date) != 'DateTime') {
  $date = new DateTime($date);
}

Just chiming in with more thanks jlscott...

Our server admin isn't quite ready to upgrade to PHP 5.2 for whatever reason, so this will work!

Here is a quick patch I made implementing #24.
This is probably not the technically correct way of fixing this error, but let's see if it works.

We are experiencing the same problem. We're running a stock RHEL 5.x system, with php 5.1.6.

As far as I've been able to determine, the WSOD is triggered only on our sites that are defining content types with Date CCK fields. The problem disappears after reverting to Date 2.4.

subscribing .... exactly the same problem as justindavis on my current projet with php 5.1.6
after enabling the module with php4 comp , loadind admin/settings/date-time gives a WSOD

Thank you jlscott. You really save my day.

Subscribing

#26 works around the problem for PHP 5.1.6 on RHEL and Date PHP4 module enabled.

Subscribing. #26 worked for me as well.

I can confirm the problem on 5.1 at centos.

I'm not really sure about the proposed patch, since the usual way to deal with functions/classes not defined on a previous version is to define them on the legacy code, I mean on data_php4.

Marking as need work since I think that should be the way to fix it. Please correct me if I'm wrong.

At the php.net doc page there are some snippets trying to provide simple DateTime class for php < 5.2, I paste here one of them to avoid forgetting to check it.

if (!class_exists('DateTime')) {
class DateTime {
    public $date;
   
    public function __construct($date) {
        $this->date = strtotime($date);
    }
   
    public function setTimeZone($timezone) {
        return;
    }
   
    private function __getDate() {
        return date(DATE_ATOM, $this->date);   
    }
   
    public function modify($multiplier) {
        $this->date = strtotime($this->__getDate() . ' ' . $multiplier);
    }
   
    public function format($format) {
        return date($format, $this->date);
    }
}
}

I added the code from #33 to date_api.module (right after the "define" section at the beginning) and it appears to work correctly for me (I got my calendar back). Sorry I just have time to report it's working (no patch). :-S

Got:
Drupal 6.19
PHP 5.1.6
Apache/2.0.52 (CentOS)

Thanks for trying it.

Moving again to php4 module component, since that's the place where we need to fix it, since recent versions already have the DateTime class

This still needs work, but I attaching this to remember e where to start again.

I had a problem with datetime in PHP 4.3.10-16, so I had to return to release 6.x-2.4 of the module as suggested and everything worked fine again. Thx a lot to bettibio.

subscribing

#33 works for me as well! Thanks!

Working in same environment as #34, and I just added the code from #33 and can also report it to be working. No more WSOD on calender. No more WSOD on node pages (with cck date fields) and node lists (ie taxonomy pages). Thank you all very much.

I posted #39, and indeed I had no more WSOD, but all my dates were being formatted as 12/31/1969 - but the underlying data was correct. I did a little hunting around and it seemed that the data was being sent to the date_format_date function in the date_api.module. That function does the following check:

  if (get_Class($date) != 'DateTime') {
    $date = new DateTime($date);
  }

With the date_php4 module the DateTime class is not used, but rather just a standard object class. The class definition provided here in #33 does not work in this scenario. The date_php4 module appears to create the object with the necessary elements to produce the date. I changed the check in the code above to also check for the date_php4 module and I get no WSOD and my dates are now being formatted properly.

  if (module_exists('date_php4') == FALSE) {
    if (get_Class($date) != 'DateTime') {
      $date = new DateTime($date);
    }
  }

I was also able to remove the class def provided by #33 from the code. Not sure where else the DateTime object may be instantiated, need to research that more, but right now, everything seems to be working properly with just the additional if statement.

Confirm #40!

I had the same issue, all dates where 1/1/1970. With the fix from #40 all is good again.
should be supply a patch for this?

Same scenario than #34 and worked for me!
Thank's for all.

subscribe...

subscribe

subscribe

#40 worked perfect for me!
thanks

I couldn't create a node of a specific type (including date fileds).

The #34 was the solution.

Thanks.

+1 Pasting #34 worked ugg bad hack

#34 works in my obsolete provider!

Server: Drupal 6.19 + PHP 5.1.6 + MySQL 5.0.77

Confirmed that combining #33 and #40 worked for me (commenting out #33 after implementing #40 still left me with a WSOD).

• Drupal 6.19
• PHP 5.1.6
• MySQL 5.0.45
• Date 6.x-2.x-dev Nov 29 2010

Subscribing.

subscribing

#40 worked for me. Thanks.
Drupal 6.20 (fresh install)
MySQL 5.0.83
PHP 5.1.3RC4-dev (on restrictive website host (free.fr))

Fixed differently. We just need to use the available wrapper function date_make_date() which properly adapts to either PHP4 or PHP5.