PHP 5.3 issue - Attempt to modify property of non-object (Calendar Module)

+1!

+2

I'm currently trying a more robust fix for the related issue in the date module - as others have pointed out, I'm almost certain this only has to do with PHP 5.3.0 suddenly realizing that treating the passed array as an object makes little sense, and it just went unnoticed until now. :] If it works as expected, I'd be happy to roll a patch for review, since I need this fix for my own installs one way or the other.

Just tested the following; everything seems to be in order on my installs, running PHP 5.3.0. Review and feedback welcome!

Just applied it to 12 production sites and it has saved my skin. Thanks so much!
I also recommend setting the value of date.timezone in php.ini which gets rid of some of the php 5.3 error messages.

Please somebody explain how to apply this patch??
SHould I upload to my server and run it from somewhere?

Please let me know.
THank you.
Jag

Glad I could help, Andrew! :] Good call on the date.timezone issue; forgot to make a mention of that...

Jag, have a look at http://drupal.org/patch/apply for instructions on how to apply patches. If you do, let us know here how it works out for you!

Hey, thnx for the info, im also a new-user.
The patch will most likely not help me with this error would it?

An error occurred at /drupal-6_14/admin/build/views/ajax/display/date_browser/default/style_plugin.

I just ignore all the errors as mentioned above and continued building the calendar. When i go to
localhost/drupal-6_14/admin/build/views/edit/date_browser

and i want to change the Style, i get this error, actually with whatever i click...

An error occurred at /drupal-6_14/admin/build/views/ajax/config-item/date_browser/default/argument/date_argument.

Will the patch help? probably not as it only ignores the error right?
thnx for any help!

This patch works for me, though I haven't looked at the code itself.

All the patch does is treat the array as an array rather than an object, now enforced by PHP 5.3.0.

Someone else care to RTBC this?

The code looks good. (Have tested it as well). RTBC.

Nope, patch doesn´t work for me! this is the error i get upon clickin on save.

Parse error: parse error in C:\wamp\www\drupal-6_14\sites\all\modules\calendar\includes\calendar_plugin_display_page.inc on line 47

i edited the patch by hand and im pretty sure i did exactly as the patch mentioned.
any ideas?

The parse error above suggests that there's a missing semicolon or somesuch - that is, that the patch wasn't applied correctly. A quick Google will be able to tell you the common culprits. Please follow the steps at drupal.org/patch/apply, preferably using the command line (or similar). Applying patches manually is typically frowned upon, due to the human error that can result. If there is still a bug, I'd be happy to investigate.

Thanks!

Ran the patch and it worked great! Thanks

Hey c.ex,

thanks a lot, it does indeed work, sorry bout that! But i still get an error on my homepage:

An error occurred at /drupal-6_14/admin/build/views/ajax/display/date_browser/default/style_plugin.

Any ideas on that?

WSRyu -

Glad I could help! This patch was only intended to fix the above notices. I'd go ahead and create a new support ticket in the appropriate issue queue. The guide at http://drupal.org/node/314185 contains a lot of useful information on how to do this - it's easy to say there's something wrong, but being able to communicate exactly what the issue is (and how to duplicate it) makes life much easier on us devs.

HTH!

Thanks, the patch worked for me.

The patch worked for me too. But since I'm a novice at patching it took me a while to
figure out needing to create a directory "new_includes" and put the files there before
running the patch.

There are numerous issues like this all around Drupal. If you make this change, it may not work in PHP 4 and we're still supporting PHP4 in this version. This module is not the only one that has this problem, there are many others, including some core modules. PHP 5.3 may just be incompatible with code that tries to support PHP 4. And which version of Views are you testing against, Views 2 or Views 3?

If someone can thoroughly test that this won't break things in PHP 4, I'll consider it, but I don't have time to do that and I can't commit the change without that.

Thanks for giving this a once-over, Karen!

I tested this against Views 2. I'll see if I can't run some more thorough tests on different environments (Views 2/3, PHP 4/5) to confirm that nothing breaks, and I'd be happy to re-roll if that's what it takes. It will likely take me a bit, though, and I'd much prefer another set of eyes on this, so if someone else wants to take a stab then by all means!

I marked #587424: compatibility with php 5.3 as a duplicate of this issue.
That issue included a patch from drasgardian.
I am attaching that patch to this post in case anyone finds it useful here.

Patch in #22 needs work. What about the case in which it is an array? Some defaults will be left unset, no?

Subscribing.

I applied the above mentioned patch (#5) by hand.

As I have PHP 5.3 so have no need for compatibility with PHP4, I removed the '&' from the code. Correct me if I'm wrong but if you need PHP4 compatibility at any point I think you need to avoid that.

Anyway here is the manual way of applying the patch. Don't forget to backup the affected files before changing anything so that you can reverse the changes if it goes wrong.

In the calender module includes sub-folder ( includes/calendar_plugin_display_attachment.inc)

Where this code appears:

function options(&$display) {
     parent::options($display);
     $display->display_options['inherit_argments'] = TRUE;
     $display->display_options['inherit_filters'] = TRUE;
     $display->display_options['attachment_position'] = 'after';
     $display->display_options['calendar_type'] = $this->calendar_type();
   }  

Change it to:

function options($display) {
     parent::options($display);
     $display['display_options']['inherit_argments'] = TRUE;
     $display['display_options']['inherit_filters'] = TRUE;
     $display['display_options']['attachment_position'] = 'after';
     $display['display_options']['calendar_type'] = $this->calendar_type();
   }  

Also

In the same sub-folder (includes/calendar_plugin_display_block.inc)

Where this code appears:

   function options(&$display) {
     parent::options($display);
     $display->display_options['displays'] = array();
     $display->display_options['style_plugin'] = 'calendar_nav';
     $display->display_options['items_per_page'] = 0;
     $display->display_options['row_plugin'] = '';
     $display->display_options['defaults']['style_plugin'] = FALSE;
     $display->display_options['defaults']['style_options'] = FALSE;
     $display->display_options['defaults']['items_per_page'] = FALSE;
     $display->display_options['defaults']['row_plugin'] = FALSE;
     $display->display_options['defaults']['row_options'] = FALSE;
   }  

Change it to this:

   function options($display) {
     parent::options($display);
     $display['display_options']['displays'] = array();
     $display['display_options']['style_plugin'] = 'calendar_nav';
     $display['display_options']['items_per_page'] = 0;
     $display['display_options']['row_plugin'] = '';
     $display['display_options']['defaults']['style_plugin'] = FALSE;
     $display['display_options']['defaults']['style_options'] = FALSE;
     $display['display_options']['defaults']['items_per_page'] = FALSE;
     $display['display_options']['defaults']['row_plugin'] = FALSE;
     $display['display_options']['defaults']['row_options'] = FALSE;
   }

Lastly

In the same sub-folder (includes/calendar_plugin_display_page.inc)

Where this code appears:

   function options(&$display) {
     parent::options($display);
     $display->display_options['displays'] = array();
     $display->display_options['style_plugin'] = 'calendar_nav';
     $display->display_options['items_per_page'] = 0;
     $display->display_options['row_plugin'] = '';
     $display->display_options['defaults']['style_plugin'] = FALSE;
     $display->display_options['defaults']['style_options'] = FALSE;
     $display->display_options['defaults']['row_plugin'] = FALSE;
     $display->display_options['defaults']['row_options'] = FALSE;
     $display->display_options['defaults']['items_per_page'] = FALSE;
   }  

Replace it with this:

   function options($display) {
     parent::options($display);
     $display['display_options']['displays'] = array();
     $display['display_options']['style_plugin'] = 'calendar_nav';
     $display['display_options']['items_per_page'] = 0;
     $display['display_options']['row_plugin'] = '';
     $display['display_options']['defaults']['style_plugin'] = FALSE;
     $display['display_options']['defaults']['style_options'] = FALSE;
     $display['display_options']['defaults']['row_plugin'] = FALSE;
     $display['display_options']['defaults']['row_options'] = FALSE;
     $display['display_options']['defaults']['items_per_page'] = FALSE;
   }

I hope this helps anyone who cannot, for any reason, apply the patches in the normal way.

I applied the patches with the patch command (#5) and manually with the instructions in #26. I still get the following error: Attempt to modify property of non-object in /mysite.com/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 26. Grrr! Thanks for the patches but I seem to still have this problem.

Thanks for this patch.
After run the patch manually, it reduced the long list of errors in my Views screen.
There is still one error remaining, though. Do you have a patch or solution for this one too?:

Attempt to modify property of non-object in /customers/xx.nl/xx.nl/httpd.www/new/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 24

Thanks,

@ Buzzard

See Here: http://drupal.org/node/549884#comment-2250444 (#30)

What that patch does is in the date module it changes this file.

includes/date_plugin_display_attachment.inc

From this:

 function options(&$display) {
  parent::options($display);
     $display->display_options['style_plugin'] = 'date_nav';
     $display->display_options['items_per_page'] = 0;
     $display->display_options['row_plugin'] = '';
     //$display->display_options['defaults']['style_plugin'] = FALSE;
     $display->display_options['defaults']['style_options'] = FALSE;
     $display->display_options['defaults']['items_per_page'] = FALSE;
     $display->display_options['defaults']['row_plugin'] = FALSE;
     $display->display_options['defaults']['row_options'] = FALSE;
  } 

To this:

    function options($display) {
     $display['display_options']['style_plugin'] = 'date_nav';
     $display['display_options']['items_per_page'] = 0;
     $display['display_options']['row_plugin'] = '';
     //$display['display_options']['defaults']['style_plugin'] = FALSE;
     $display['display_options']['defaults']['style_options'] = FALSE;
     $display['display_options']['defaults']['items_per_page'] = FALSE;
     $display['display_options']['defaults']['row_plugin'] = FALSE;
     $display['display_options']['defaults']['row_options'] = FALSE;
   } 

That fixed it for me.

Yes, the additional correction in #29 fixed the error I was still having. Thanks, Ahqar!

tagged

Tried to apply the patch, got these errors:

mail:/home/larry/public_html/modules/calendar # patch < calendar-6.x-2.2-613528-5.patch
patching file calendar_plugin_display_attachment.inc
Hunk #1 FAILED at 161.
1 out of 1 hunk FAILED -- saving rejects to file calendar_plugin_display_attachment.inc.rej
patching file calendar_plugin_display_block.inc
Hunk #1 FAILED at 47.
1 out of 1 hunk FAILED -- saving rejects to file calendar_plugin_display_block.inc.rej
patching file calendar_plugin_display_page.inc
Hunk #1 FAILED at 44.
1 out of 1 hunk FAILED -- saving rejects to file calendar_plugin_display_page.inc.rej
mail:/home/larry/public_html/modules/calendar #

Sigh...... never mind. Helps if I actually look at which files I'm supposed to be patching. First time I've ever done this.... welcome to the curve, eh?

great! thanks!

Patch in #5 works with 2.2.

subscribe

Can I ask maintainer to put info here where the proper patch will be implemented in dev. Thank you.

Patch in #5 works with dev and 2.2

Issue is related to #698522: Make date compatible with both views 2 and views 3

patch in #5 worked for me. did it manually. Failed the first time, but the second time was the charm!

Great thanks c.ex

Although I appreciate the support folks, see Karen's response in #20, and my follow-up in #21. This hasn't been adequately tested in PHP 4 yet for it to be considered for inclusion in -dev, and it completely lacks testing for Views 3 from what I can tell. Apologies for the <strong>, but it seems a lot of people are scanning the issue and missing why it hasn't been committed yet.

Marking as CNR until tested and confirmed in the following environments:

PHP 5.3, Views 3
PHP 5.2, Views 3
PHP 4, Views 2
PHP 4, Views 3

Already confirmed using the following:

PHP 5.3, Views 2
PHP 5.2, Views 2

Things are starting to slow down a bit, so hopefully I can devote some attention here again in the very near future. Karen, if you think this should still be CNW still feel free to set it back, but the fact that it needs more testing before going one way or the other makes me wonder if CNR is a better fit.

Not sure if this is the same issue but here goes...:

After upgrading to latest dev versions for views 2, calendar 2 and date 2, I'm getting the following error whenever I look at a calendar view that has date nodes in the current view:

"Fatal error: Call to a member function advanced_render() on a non-object in ...\views\theme\theme.inc on line 225"

Calendar 6.x-2.x-dev (2010 April-1)
Date 6.x-2.x-dev (2010-Mar-26)
Views 6.x-2.x-dev (2010-Apr-07)
PHP Version: 5.2.9
MySQL: 5.1.33

Again, I only get this error if the calendar view has date nodes. For example, empty month view is fine, empty day view is fine, but any view that has even 1 date node produces this error.

Is my issue related?

UPDATE: This issue has been fixed. It was a bug in Views 2.9. Patch has been committed in latest release (Views 2.10). See this thread over at views: advanced_render() error when viewing calendar

NoDice: I don't think your errror is related to this issue (at least closely, it might be a distant relative) because your PHP version is 5.2, not 5.3.

Note: I modified the title to clarify which module this issue applies to (date has another issue with the same title).

@NoDice: I have your same config and am getting this error, but only since lasst night's security upgrade to Views 6.x-2.9.

Applied patch from #5, but "nodice".

Do we need another issue thread?

Following from KarenS at #20, found another reference (numerous issues?) but at least this one did not seem connected directly to the version of PHP, but to "the way custom fields are added to the "Search and reference" views" (via markus_petrux)

http://drupal.org/node/668554

I'm too chicken to try rolling Views back to 6.2.8 and see if Calendar springs to life again. Anyone else have trouble since update to 6.2.9?

@boabjohn and arlinsandbulte

UPDATE: My issue I mentioned earlier in this thread has been fixed (Views related).

My issue was related to Views 2.9. It was producing advanced_render() error when attempting to display calendar view with dates. I posted my issue over at Views and the critical bug has been fixed in latest Views 2.10. See this issue at Views for fix: advanced_render() error when viewing calendar

Thanks heaps for the pointer NoDice. All playing nicely on the same page now.

subscribing

Moved stuff from options() to options_definition() like what was applied for a similar issue (i.e. #698522: Make date compatible with both views 2 and views 3) in the Date module.

I'm only quasi-sure this is the way to go. Somebody step up and review it.

sorry my mistake, it works for me

Found a solution!*

just copy this code in the template.php of your theme.

set_error_handler('takpar_error_handler');

function takpar_error_handler($errno, $message, $filename, $line, $context) {
	$aBypass = array(
		'Attempt to modify property of non-object',
	);
	foreach ($aBypass as $sTerm) {
		if (false !== strpos($message, $sTerm)) {
			return;
		}
	}
	return drupal_error_handler($errno, $message, $filename, $line, $context);
}

You can define every disturbing error message in the $aBypass array.

other friends can make it available as a patch to drupal core.

subscribing

Subscribe

Patch from #5 works very well for php5.3. Thank you.

#51: I guess that solution is simply to circumvent printing out the error messages due to modifiying the theme. Am I right?

.

Patch #5 http://drupal.org/node/613528#comment-2250424 worked for me.
Thanks.

subscribing

Thanks for the help,
#26 / #5 worked for me on calendar-6.x-2.x-dev.

Subscribing. Patch revoke via #5 and CVS with DRUPAL-6--2.

Fully tested with Drupal 6.17 + Debian Squeeze + PHP 5.3.2-1 + calendar 6.x-2.x-dev.

Should we change this issue as RTBC?

subscribing

This patch def fixes the problem ( $display->display_options should be $display['display_options'] but also needs to be applied to the DATE module. I'm new to patching, but the current patch appears to ONLY fix the CALENDAR module. I ran it via Tortise (not a bad app!) and after still got same complaints from Drupal about the DATE includes.

At understandable risk, I did the patch to DATE via Ultraedit search and replace and no more messages from Drupal on this subject.

THANKS for the patch!

=Alan R.

I can confirm that #60 at least fixes the errors. Using PHP 5.3, Drupal (Pressflow) 6.16, Nginx, calendar 6.x-2.x-dev.

FYI: confirming patch worked here, too, for 6.x-2.x-dev

tried the patch with the following modules in place

calendar 6.x-2.2 AND 6.x-2.x-dev
date 6.x-2.4 AND 6.x-2.x-dev
views 6.x-2.11

and once I run the patch, the errors are gone, but the 'Views' page and the 'Modules' pages are both broken. All I get is an empty page for both of them. Anyone else get this or have any ideas?

disregard my previous post. I guess the patch did something strange with my permissions that I couldn't rectify. Instead I just went through and made the changes by hand, and it works fine now.

Patch in #60 worked for me as well. We have the same configuration as #65. Thanks for putting this out.

subscribe

Thank you. Finally got it working, but has to implement the patch manually. Now I can get some sleep :)

Like so many others had this problem when migrating to a site that had PHP 5.3.1 installed (as opposed to 5.2.x).
Just to say that the patch in #60 worked for me when applied to Calendar 6.x-2.2.
Confirming that the Date module needs a similar treatment.
Thank you hswong3i and all involved.

Refer to replies since #60, I would like to mark this issue as RTBC.

See my response back in #40, and Karen's before that. The reason this wasn't committed before was insufficient testing in the newest version of Views, and in PHP 4. From what I can tell, it hasn't received any additional testing on these fronts, and therefore is still CNR.

+1
subscribe

+1 subscribe

PLEASE! This issue is not only important to know for that procject. As you can see below there will be several modules that won't work correctly anymore with PHP 5.3.

GMAP: GMAP
Date: DATE
Calendar: CALENDAR
Administration Menu: ADMINISTRATION MENU

The reason is a change inside PHP 5.3 object and reference handling!

I've taken a look at module Views, it doesn't use $display as an array anywhere, so setting $display['display_options'] is futile.
I haven't debugged this, but my bet is that the code that triggers the warning is correct. I think it's another chunk of code that wrongfully uses $display as an array and passes it here.
I recommend using the patch in #22, not the ones that set the array

Patches from #5 and #22 failed for me. Applying #5 manually seems to solve the problem with PHP 5.3.3, Calendar 6.x-2.2 and Views 6.x-2.11.

I'm sorry, but I can't do PHP 4 testing.

#26 worked for me.

Tried first with #60, but then the view didn't display anything.

Deleted and copied back both Date (6.x.2-dev) and Calendar (6.x.2-dev) after failure to revert from patch #60.

PHP 5.3.2

I had the same problem with Drupal 6.17 and also now 6.19

Apache: : Apache/2.2.15 (Linux/SUSE)
PHP: PHP Version 5.3.2
Drupal: drupal-6.19.tar.gz
Modules:
date-6.x-2.4.tar.gz
calendar-6.x-2.2.tar.gz

Combining #29 (Calendar module) and #26 (date module) solved the problem for me.

Thank you,

thank you,

thank you.

To #5 - c.ex for finding the solution and creating the patch.

#26 - Ahqar for documenting it so i could apply it by hand when i couldn't actually make the patch work (user error)...

and to all you beautiful people who put in all this time and effort to fix the bugs.

Apache: Apache/2.2.14
PHP: PHP Version 5.3.1
Drupal: drupal-6.19
Module: date-6.x-2.4

status: up and running

Thank you

#5 worked beautifully

PHP 5.3.1
date 6.x-2.6
calendar 6.x-2.2

Thank you, thank you, thank you!

I looked at it as well, the parent function options() which is inherited all the way from the views_plugin class, never defines anything for $display as far as I can tell. Obviously, as OO programming dictates, you may 'inherit' the functionality all the way from the base class even while overloading its functionality. this is what the parent::options($display) is all about. The trouble is there is no definition of the function save on the level of the views_plugin function, and it is a stub.

I ran a few experiments, and if you just do

$var->name['key'] = "val";

On a new a variable there is no problem; but if this variable has been defined as say, an array

$var['key'] = "val";
$var->name['key'] = "val";

Produces an error. (Warning: Attempt to modify property of non-object in ... )

This indicates that somewhere in the execution the variable $display which is passed to the function is being defined as something other than an object; based on the fact that we do not get an error when we assume it is an array I'm going to say it is being defined as an array.

I hope that clears this up, code-wise. Someone who knows more than I about PHP may have deeper insights into this error, but my examination of the problem indicates that changing the reference from object properties to array keys is the proper solution.

My drupal 7 patch for this. Is alrdy using the array solution.

#885030: Bunch of warnings

There are several "solutions" around for this issue. As far as I understand it, there is only one, that is going into the right direction although many of them suppress the Problem.

#48 solves the problem by using the API of Views 2 and Views 3 (removing calls to deprecated function options(&$display) and replacing them by calls to option_definition(). #36 already pointed toward the right direction and linked a related issue.

The fix from #5 partly solves the problem for Views2, but answering #40: Views3 will not validate with the solutions from #5, #60, #22 and #83. If you want a Views2-only solution, #22 would be a good starting point, but you would need to add code for the case, that $display is not an object (basically keep the current code). But since that solution would be deprecated as soon as it is coded, I will not provide a patch.

To sum it up, I strongly support the patch from #48 which provides a long term solution for the problem and has the chance of being successfully tested in all environments named in #40.

#48 fixes the problem on php 5.3 and views 6.11.

it was patched of calendar-6.x-2.x-dev (jul 11).
to all other patching rookies like me: you are supposed to put the patch file in the calendar directory and run:
patch -p1 < 613528--views-compatibility.patch

I agree with everyone here who says that we should commit this into -dev ASAP.

Thanks. I used the command to patch the calendar module in drupal_commons-6.x-1.0 package.

In looking more closely, I think a different fix is needed. I committed changes to the dev version.

@KarenS: Thank you for the committed changes: i quickly tested the module and everything works smoothly and i was not able to detect errors.

I manually applied #26 to a published site to be sure I could revert, and it worked splendidly. Thank you all very much.

thanks.the patch is work for me.
i'm using manual patch and everything goes well.

Subscribing

Note: This issue is fixed in the -dev version according to Karen in #87. You do not need to apply a patch.
Please, use the dev version to verify the official fix.

I am running Drupal Commons v6.x-1.1 and have tried both the manual patch and updating to the dev version, and I still get all the errors quoted in #1.

Help!!

Thanks

Doh, I had left a backup of the original calendar module in place, deleting this has solved the problem.

Thanks again.

Phewf thanks for fixing this I can confirm that all the messages are now gonzo!

change directory to the includes directory in the calendar module directory:

sites/all/modules/contrib/calendar/includes

and execute the the patch there:

patch < calendar-6.x-2.2-xxxxxxxxxxx.patch

Thanks for taking the time to put in this information -- it saved me!

Thanks, calendar-6.x-2.x-dev.tar.gz resolved this issue for me.

Sub... waiting for an official release.

subscribing

Found this when seeing this error on drupal.hu, that we are updating to PHP 5.3. Looking forward to a stable release, thanks!

subscribing..

6.x-2.x-dev 2010-Nov-13
6.x-2.x-dev 2010-Oct-23

worked for me on:

PHP 5.3.0
MYSQL 5.1.37

subscribing

doesn't seem fixed to me, setting active again

dasjo:
Have you tried the -dev release? Everyone else has confirmed that this is fixed in the -dev.

If you still have the problem with the -dev, please provide detailed instructions on how this can be reproduced.

arlinsandbulte: sorry my fault :)

Thank you for the patch in #5, saved my neck on my company's intranet
hope this helps. this is my full report, the patch broke absolutely nothing
WEB SERVER: Apache/2.2.3 (Red Hat)

Drupal Version: 6.19

PHP VERSION: 5.3.3

DATABASE TYPE: mysql; VERSION: 5.1.52

MODULES

     Administration menu  (6.x-1.6; Status: enabled)

     Computed Field  (6.x-1.0-beta4; Status: enabled)
     Content Templates  (6.x-1.2; Status: enabled)
     Content  (6.x-2.8; Status: enabled)
     Content Copy  (6.x-2.8; Status: enabled)
     Content Permissions  (6.x-2.8; Status: enabled)
     Fieldgroup  (6.x-2.8; Status: enabled)
     FileField  (6.x-3.7; Status: enabled; Minimum PHP version required: 5.0)
     FileField Meta  (6.x-3.7; Status: disabled; Minimum PHP version required: 5.0)
     ImageField  (6.x-3.7; Status: enabled)
     Image crop  (6.x-1.0-rc2; Status: enabled)
     Node Reference  (6.x-2.8; Status: enabled)
     Node Reference URL Widget  (6.x-1.6; Status: enabled)
     Number  (6.x-2.8; Status: enabled)
     Option Widgets  (6.x-2.8; Status: enabled)
     Phone - CCK  (6.x-2.17; Status: enabled)
     Serial  (6.x-1.0-rc1; Status: enabled)
     Text  (6.x-2.8; Status: enabled)
     User Reference  (6.x-2.8; Status: enabled)

     Bulk Export  (6.x-1.8; Status: enabled)
     Chaos tools  (6.x-1.8; Status: enabled)
     Custom rulesets  (6.x-1.8; Status: enabled)
     Chaos Tools (CTools) AJAX Example  (6.x-1.8; Status: disabled)
     Custom content panes  (6.x-1.8; Status: enabled)
     Chaos Tools (CTools) Plugin Example  (6.x-1.8; Status: enabled)
     Page manager  (6.x-1.8; Status: enabled)
     Stylizer  (6.x-1.8; Status: enabled)
     Views content panes  (6.x-1.8; Status: enabled)

     Calendar  (6.x-2.2; Status: enabled)
     Calendar iCal  (6.x-2.2; Status: enabled)
     Date  (6.x-2.6; Status: enabled)
     Date API  (6.x-2.6; Status: enabled)
     Date Locale  (6.x-2.6; Status: disabled)
     Date PHP4  (6.x-2.6; Status: disabled)
     Date Popup  (6.x-2.6; Status: disabled)
     Date Repeat API  (6.x-2.6; Status: enabled)
     Date Timezone  (6.x-2.6; Status: enabled)
     Date Tools  (6.x-2.6; Status: enabled)
     Calendar Popup  (6.x-2.2; Status: enabled)

     Configuration State  (6.x-1.1; Status: enabled)
     Node import  (6.x-1.0-rc4; Status: enabled; Minimum PHP version required: 5)
     Path redirect generate  (6.x-1.0-rc1; Status: disabled)

     ImageAPI  (6.x-1.9; Status: enabled; Minimum PHP version required: 5.1)
     ImageAPI GD2  (6.x-1.9; Status: enabled)
     ImageAPI ImageMagick  (6.x-1.9; Status: enabled)
     ImageCache  (6.x-2.0-beta10; Status: enabled)
     ImageCache UI  (6.x-2.0-beta10; Status: disabled)

     Authentication  (6.x-1.0-beta2; Status: enabled; Minimum PHP version required: 5.0)
     Data  (6.x-1.0-beta2; Status: enabled)
     Groups  (6.x-1.0-beta2; Status: enabled)

     Embedded Audio Field  (6.x-2.3; Status: enabled)
     Embedded Media Field  (6.x-2.3; Status: enabled; Minimum PHP version required: 5.2)
     Embedded Image Field  (6.x-2.3; Status: enabled)
     Embedded Inline Media  (6.x-2.3; Status: enabled)
     Embedded Media Thumbnail  (6.x-2.3; Status: enabled)
     Embedded Video Field  (6.x-2.3; Status: enabled)
     Embedded Wave Field  (6.x-2.3; Status: enabled)
     Media: Archive  (6.x-1.0; Status: enabled)

     Advanced help  (6.x-1.2; Status: enabled)
     Backup and Migrate  (6.x-2.4; Status: enabled)
     Frequently Asked Questions  (6.x-1.12; Status: enabled)
     Global Redirect  (6.x-1.2; Status: enabled)
     Advanced help example  (6.x-1.2; Status: enabled)
     jCarousel  (6.x-1.1; Status: enabled)
     Libraries  (6.x-1.0-alpha1; Status: enabled)
     Lightbox2  (6.x-1.11; Status: enabled)
     Nice Menus  (6.x-2.1; Status: disabled)
     Page Title  (6.x-2.3; Status: enabled)
     Path redirect  (6.x-1.0-rc1; Status: enabled)
     Pathauto  (6.x-1.5; Status: enabled)
     Poormanscron  (6.x-2.2; Status: enabled)
     robots.txt  (6.x-1.2; Status: disabled)
     SEO Checklist  (6.x-3.0; Status: enabled)
     Site Documentation  (6.x-1.2; Status: enabled)
     Superfish  (6.x-1.6; Status: disabled)
     Token  (6.x-1.15; Status: enabled)
     TokenSTARTER  (6.x-1.15; Status: enabled)
     Token actions  (6.x-1.15; Status: enabled)
     IE Unlimited CSS Loader  (6.x-1.2; Status: enabled)
     Upload elements  (6.x-1.2; Status: enabled)
     User Import  (6.x-2.4; Status: enabled)

     Panels  (6.x-3.8; Status: enabled)
     Panels In-Place Editor  (6.x-3.8; Status: disabled)
     Mini panels  (6.x-3.8; Status: enabled)
     Panel nodes  (6.x-3.8; Status: enabled)

     Printer-friendly pages  (6.x-1.12; Status: enabled)
     Send by e-mail  (6.x-1.12; Status: enabled)
     PDF version  (6.x-1.12; Status: enabled)

     Rules  (6.x-1.3; Status: enabled; Minimum PHP version required: 5.1)
     Rules Administration UI  (6.x-1.3; Status: enabled)
     Rules Forms support  (6.x-1.3; Status: enabled)
     Rules Scheduler  (6.x-1.3; Status: enabled)
     Rules Simpletest  (6.x-1.3; Status: disabled)

     Ajax Load  (6.x-1.3; Status: enabled)
     Ajax load example  (6.x-1.3; Status: enabled)
     jQ  (6.x-1.2; Status: enabled)
     jQ Bridge  (6.x-1.2; Status: enabled)
     jQuery plugins  (6.x-1.10; Status: enabled)
     jQuery UI  (6.x-1.4; Status: enabled)
     jQuery Update  (6.x-2.0-alpha1; Status: enabled)
     Wysiwyg  (6.x-2.1; Status: enabled)

     Views  (6.x-2.11; Status: enabled)
     Views attach  (6.x-2.2; Status: enabled)
     Views exporter  (6.x-2.11; Status: enabled)
     Views Fluid Grid  (6.x-1.1; Status: enabled)
     Views Galleria  (6.x-1.x-dev; Status: enabled)
     Views Gallery  (6.x-1.3; Status: enabled)
     Views Gallery for Organic Groups  (6.x-1.3; Status: disabled)
     Views Rotator  (6.x-1.0-alpha2; Status: enabled)
     Views Showcase  (6.x-2.1; Status: enabled)
     Views Slideshow  (6.x-2.3; Status: enabled)
     Views Slideshow: Imageflow  (6.x-1.0-beta1; Status: enabled)
     Views Slideshow: SingleFrame  (6.x-2.3; Status: enabled)
     Views Slideshow: ThumbnailHover  (6.x-2.3; Status: enabled)
     Views UI  (6.x-2.11; Status: enabled)
     Views Carousel  (6.x-1.0; Status: enabled)

     Fivestar  (6.x-1.19; Status: enabled)
     Fivestar Comments  (6.x-1.19; Status: enabled)
     Voting API  (6.x-2.3; Status: enabled)

     Webform  (6.x-3.4; Status: enabled; Minimum PHP version required: 5.0)

     Galleria  (6.x-1.0; Status: enabled)

Patch from #5 worked for me, thanks! Is this going to be rolled into the calendar module so that next update will not break it again?

sobrien.808 yes, as this has been committed to dev it should come with the next release

@ sorbrien.808:
YES!
See my post in #93: http://drupal.org/node/613528#comment-3483232

Patch from #5 worked fine for my project, thanks a lot!
I'm waiting the next release of the module.

Worked for me too. Thank you.

issue has evaporated in the dev version. Thanks!

Thanks, man! The patch worked great!

Thanks! Works!

Any chance of cutting a new release with these php 5.3 fixes soon? It's been a year and a half since the last release.

@Jhon: if you're in a hurry you can use the latest -dev package or pull down the CSV branch :)

by the way: I think that the new huge features added could aim a new "official" release! :)

I avoid running -dev versions as I don't want to have to manage the bug-of-the-week on production sites. I'm more likely to backport select patches (like these 5.3 patches) to the release version to solve the specific issues I do have.

I think a year and a half is a bit long to go between Recommended Releases. I think we should have seen a 2.3 release by now or at least a 2.2.1 with patches from some "critical" bugs. I haven't been tracking the code base, but I could see this many months of effort adding enough to justify a 3.0 version bump.

both patches don't work for me - i get the "hunk failed" message (story of my life). subscribe!

See #945346: 6.x-2.3 Recommended release due date -- it has been a year and half since the last release because there haven't been any significant changes until the last few weeks.

add the more commonly used 'php5.3' tag.

Subscribe

Updating calendar module to latest 2.4 solve the problem

Subscribe

I am using:
Drupal 6.16
MySQL 5.1.49
PHP 5.3.3-7
Apache/2.2.16 (Debian)

Calendar 6.x-2.2
Date 6.x-2.x-dev
BeautyTips 6.x-2.0
Calendar Tooltips 6.x-1.7
Calendar iCal 6.x-2.2
Calendar Popup 6.x-2.2
Views 6.x-2.8

I solved that issue using #26 , but I want to update the module.

So, can anyone explain me the correct versions of the following modules?

Calendar
Date
BeautyTips
Calendar Tooltips
Calendar iCal
Calendar Popup
Views

Thanks!

The latest stable versions of Date & Calendar are PHP 5.3 compatible.
Date 6.x-2.7
Calendar 6.x-2.4

As for the rest of the modules, you can either test it yourself or ask in their respective issue queues.

hallelujah to comment #29

Big Thanks .. it Works great .. :))