warning: Attempt to modify property of non-object in [..]\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 24.
File: date/includes/date_plugin_display_attachment.inc
Class: date_plugin_display_attachment
Method: date_plugin_display_attachment::options(&$display)
<?php
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;
}
?>
Called here:
File: views/includes/base.inc, line 57
Class: views_object
Method: views_object::set_default_options()
<?php
/**
* Set default options.
* For backward compatibility, it sends the options array; this is a
* feature that will likely disappear at some point.
*/
function set_default_options() {
$this->_set_option_defaults($this->options, $this->option_definition());
// Retained for complex defaults plus backward compatibility.
$this->options($this->options);
}
?>
Problems/Questions:
- Obviously the argument is an array, whereas the function assumes an object.
- Moreover, I get the idea the function is not intend to take $this->options as the argument.
- If the argument is supposed to be an object, then why the call by reference?
- Where is that function supposed to be called with an object?
The problem did not cause any error messages before I moved to PHP 5.3. But in this case, I think it's quite obvious that the error message (or warning) is justified.
Comment | File | Size | Author |
---|---|---|---|
#203 | includes_modules.inc-fix-call-by-ref.git_.patch | 840 bytes | regx |
#73 | date.5.3.patch | 1.41 KB | sun |
#30 | date-6.x-2.x-549884-30.patch | 1.4 KB | davidwatson |
#10 | date-6.x-2.x-fix_display_attachment_object-1.patch | 1.41 KB | thekevinday |
Comments
Comment #1
designerbrent CreditAttribution: designerbrent commentedsubscribing
Comment #2
arosemartin CreditAttribution: arosemartin commentedsubscribing
Comment #3
thekevinday CreditAttribution: thekevinday commentedThis problem happens to me when I run update.php.
Comment #4
izmeez CreditAttribution: izmeez commentedI encountered the same problem today while trying to bring a live site with Drupal 6.14 locally onto xampp 1.72 which is using PHP 5.3
I'll take a step back to an earlier version of xampp and see if it solves my problems.
Izzy
Comment #5
karimansu CreditAttribution: karimansu commentedSame here.
This is my first time with Drupal and i am getting the same error.
XAMPP 1.72 over windows here.
And i am getting this too:
warning: Parameter 1 to admin_menu_admin_menu() expected to be a reference, value given in F:\xampp\htdocs\drupal\includes\module.inc on line 471.
Comment #6
just_N CreditAttribution: just_N commentedThis is happening to me on both Drupal 6.13 and 6.14 running php 5.3.
Running apache and php through Snow Leopard.
Comment #7
Lars Vandergraaf CreditAttribution: Lars Vandergraaf commentedI get the following errors with 6.14. Modules installed: Core 6.14, CCK 6.x-2.5, Calendar 6.x-2.2, Date 6.x-2.4, Views 6.x-2.6. This is a XP OS and xampp 1.7.2 which includes PHP 5.3.
warning: Attempt to modify property of non-object in C:\xampp-win32-1.7.2\xampp\htdocs\drupal-6.14\modules\date\includes\date_plugin_display_attachment.inc on line 24.
(lines 24-31)
warning: Attempt to modify property of non-object in C:\xampp-win32-1.7.2\xampp\htdocs\drupal-6.14\modules\calendar\includes\calendar_plugin_display_page.inc on line 47.
(lines 47-55)
warning: Attempt to modify property of non-object in C:\xampp-win32-1.7.2\xampp\htdocs\drupal-6.14\modules\calendar\includes\calendar_plugin_display_block.inc on line 50.
(lines 50-58)
warning: Attempt to modify property of non-object in C:\xampp-win32-1.7.2\xampp\htdocs\drupal-6.14\modules\calendar\includes\calendar_plugin_display_attachment.inc on line 164.
(lines 164-167) 5 Times
If I toggle off calendar I only get the warning: Attempt to modify property of non-object in C:\xampp-win32-1.7.2\xampp\htdocs\drupal-6.14\modules\date\includes\date_plugin_display_attachment.inc on line 24.
(lines 24-31) which would indicate the date and view are not playing well together.
If I toggle off view and calendar, all errors go away as well as my cunning plan to include the ability to define events with a calendar.
PS. I have no skills at fishing, I live off the kindness of those that can fish.
Comment #8
izmeez CreditAttribution: izmeez commentedThe problem goes away with an earlier version of XAMPP with php 5.2.x
Also, if you are transferring data back and forth between test and live sites it was VERY important to make sure the xampp php version matches that on the live server.
Izzy
Comment #9
Lars Vandergraaf CreditAttribution: Lars Vandergraaf commentedDo you have a link for an earlier version of xampp with php 5.2.x?
Comment #10
thekevinday CreditAttribution: thekevinday commentedFor the time being I wrote a band-aid that just works around the warning.
This probably does not solve the problem, but on production systems it at least keeps things a little quieter until a proper solution is made.
all this patch does is wrap the problematic section in the following if condition:
Comment #11
izmeez CreditAttribution: izmeez commentedThe XAMPP page gives a link to all earlier versions, they are housed on SourceForge. Look at the release notes to decide which you want. http://sourceforge.net/projects/xampp/files/
I believe,
1.6.8 uses php 5.2.6
1.70 uses php 5.2.8
1.7.1 uses 5.2.9
1.7.2 uses 5.3
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedsubscribe
Comment #13
drasgardian CreditAttribution: drasgardian commentedsubscribing.
applied patch from #10 for the time being.
Comment #14
infojunkiesubscribe
Comment #15
davepoon CreditAttribution: davepoon commentedSame problem here.
I use acquia-drupal-1.2.16.5106, PHP5.3 and Zend Server CE.
Just subscribe this to wait for the update.
Comment #16
Martijn de Witsubscribe
The new PHP version is not only causing problems with Date...
I get errors with Admin and Views 2 !
I went back to PHP Version 5.2.9. Everything works fine now...
Comment #17
highfellow CreditAttribution: highfellow commentedsubscribing. The bug doesn't seem to break any calendar functions, so I'll try just applying patch #10.
Comment #18
Geoffrey-2 CreditAttribution: Geoffrey-2 commentedsubscribing
Comment #19
Sree CreditAttribution: Sree commentedsubscribing
Comment #20
vasikesubscribe
#10 works for me
Comment #22
Rosamunda CreditAttribution: Rosamunda commented+1!
Comment #23
W32 CreditAttribution: W32 commentedI also have this warning.
Apache/2.2.13 (Win32) PHP/5.3.0
Comment #24
W32 CreditAttribution: W32 commentedNo you should remove '&' in &$display argument.
In PHP 5.3 function must be: function options($display).
Comment #25
kentr CreditAttribution: kentr commented+1
Agree with W32 that just removing the ampersand may be sufficient. Appears to be general php 5.3 pass by reference problem.
Comment #26
kdhartstrom CreditAttribution: kdhartstrom commentedI am also running PHP 5.3 and getting the error. I tried removing the & ampersand from the options function and I'm still getting the error.
So my date_plugin_display_attachment.inc line 22 reads:
function options($display) {
and i still the following errors when I visit the modules page:
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 24.
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 25.
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 26.
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 28.
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 29.
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 30.
* warning: Attempt to modify property of non-object in /home/drupal/drupal/sites/all/modules/date/includes/date_plugin_display_attachment.inc on line 31.
Comment #27
thisgeek CreditAttribution: thisgeek commentedSimply removing the ampersand did not work for me. Instead, I assumed that $display is an array. I'm not sure why it is expected to be an object, but I think I must be missing something.
This is related to an issue with the calendar module: http://drupal.org/node/613528, http://drupal.org/node/587424
Comment #28
davidwatson CreditAttribution: davidwatson commentedConfirmed that removing the ampersand doesn't work. To clarify, PBR still works just fine, but passing variables by reference at runtime (calling foo(&$bar) rather than defining function foo(&$baz) and passing $bar) has been deprecated. See http://php.net/manual/en/language.references.pass.php.
Comment #29
davidwatson CreditAttribution: davidwatson commentedDid some more digging... To the best of my understanding, the set_default_options() method in views_object (that ultimately calls this) exists mostly for backwards compatibility, and it always deals with arrays - not objects. So I'd agree that the warning is justified, and would add that patch #10 may break the backwards compatibility the function affords - albeit in a way harmless to most environments. In theory, it should only be getting an array, so testing whether it's an object should always result in a failure, leaving some defaults unset. It seems a better solution would be to do something similar to the else block in #21, manipulating the array as it was originally intended.
Anyone more familiar with the codebase, please feel free to correct me if I'm completely off-base here. :]
Comment #30
davidwatson CreditAttribution: davidwatson commentedJust tested the following fix; everything appears to work as it should. I just submitted a similar patch for review on the Calendar issue queue (http://drupal.org/node/613528#comment-2250424) for those interested. Review and feedback welcome!
Comment #31
fuerst CreditAttribution: fuerst commentedPatch works. I double checked by looking in the Views code for the
options()
method. Only found one in the classviews_object
which is empty and does lack documentation of its parameters. But by looking around it seems usual for the$option
parameter to be an array, not an object.Comment #32
tnanek CreditAttribution: tnanek commentedWorks for me as well.
Comment #33
WSRyu CreditAttribution: WSRyu commentedNope, 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?
Comment #34
davidwatson CreditAttribution: davidwatson commentedWhat you have above is an issue with the calendar module, where you have already posted. Please be sure that you are posting in the right issue queue in the future.
Comment #35
misahs CreditAttribution: misahs commentedsubscribing
Comment #36
baldrick CreditAttribution: baldrick commentedPatch #30 works for me on IIS 6, PHP 5.3.1
Comment #37
baldrick CreditAttribution: baldrick commentedUps, not really working... got warning: Attempt to modify property of non-object in calendar_plugin_display_page.inc for admin/views
Applied the patch from http://drupal.org/node/613528
calendar-6.x-2.2-613528-5.patch
It seems ok now.
Comment #38
davidwatson CreditAttribution: davidwatson commentedThat's because if you look at the warning, it was from the calendar module, not date. ;]
I rolled both patches, they're intended to be used together if you're running calendar+date.
Comment #39
fractile81 CreditAttribution: fractile81 commented+1 to the patch in #30. I had this same problem, and this fixes it.
Comment #40
KarenS CreditAttribution: KarenS commentedThere 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.
Comment #41
donquixote CreditAttribution: donquixote commentedHi Karen, thanks for showing up!
I think this case is a bit different from the usual call-by-reference problems. The code we have here doesn't make much sense for PHP4 either.
Comment #42
KarenS CreditAttribution: KarenS commentedExcept that you removed the reference, which looks like it will break things in PHP4. I'm inching closer to just abandoning support for PHP 4 tho, for all it's many problems.
Yes I see that you changed it from an object to an array. That's why I asked about the Views version because at some point it was an object.
Comment #43
davidwatson CreditAttribution: davidwatson commentedThanks for the feedback, Karen!
These were tested using the latest Dev of Views 2, at least in my case. Admittedly I'm only just getting accustomed to the codebase, so it makes more sense knowing that this used to be an object at some point. Things are a bit hellish here too, but once I can steal a moment I'd be happy to run some more thorough tests on different environments and roll a new patch if necessary. That said, if anyone else could confirm one way or the other, I'd really prefer not to RTBC my own work. ;]
Comment #44
kcolbe CreditAttribution: kcolbe commentedSo what's wrong with the patch in block #21?
Comment #45
arlinsandbulte CreditAttribution: arlinsandbulte commentedChanged title to match related issue in the Calendar Module: #613528: PHP 5.3 issue - Attempt to modify property of non-object (Calendar Module)
Comment #46
donquixote CreditAttribution: donquixote commentedThe new title is less specific, but it's probably better for googling the error message.
On the other hand, changes in the issue title are never a nice thing for subscribed users. I am undecided. If others want to revert to the old title, feel free to do so.
Anyway: My issue tracker doesn't tell me which project an issue refers to, so I add the project name in the issue title. That is so long as we have the new title.
Comment #47
davidwatson CreditAttribution: davidwatson commentedI was operating under the assumption that an object would never result (it never did when testing Views 2), unaware that prior versions of Views behaved this way... before my time, I suppose. :] I'd think something like #21 would work, provided we be mindful of references and PHP 4 compatibility as Karen suggests.
I won't be able to touch this for another couple days, at least. If someone else wants to get the ball rolling with testing, I can help review when I'm free again.
Comment #48
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing
Comment #49
Coupon Code Swap CreditAttribution: Coupon Code Swap commented#30 works for me
Comment #50
veltechh CreditAttribution: veltechh commentedhow to install patch and which path i will copy patch files?
Comment #51
killua99 CreditAttribution: killua99 commented#30 works for me too.
Comment #52
EliseVanLooij CreditAttribution: EliseVanLooij commentedsubscribing
Comment #53
aenw CreditAttribution: aenw commentedsubscribing
Comment #54
tauno CreditAttribution: tauno commentedIt's not a direct fix, but it seems like making the changes needed for #698522: Make date compatible with both views 2 and views 3 might happen to resolve this issue (at least the specific code targeted in #30) since views_handler::option_definition() doesn't even take an argument.
Comment #55
vorbian CreditAttribution: vorbian commentedsubscribing
Comment #56
scrowder CreditAttribution: scrowder commentedSubscribing
Comment #57
humanoc CreditAttribution: humanoc commentedsubscribing
Comment #58
duntuk CreditAttribution: duntuk commentedsubscribing
Comment #59
kentr CreditAttribution: kentr commentedAdded tag for PHP 5.3 issue tracking.
Comment #60
humanoc CreditAttribution: humanoc commentedI had to downgrade to XAMPP 7.1 to avoid this error.
Comment #61
Dr Jay CreditAttribution: Dr Jay commentedsubscribing
Comment #62
killua99 CreditAttribution: killua99 commented#30 works for me too. But I didn't apply the patch, I re-write the code at line:
date/includes/date_plugin_display_attachment.inc -> 24
calendar/includes/calendar_plagin_display_page.inc -> 74
calendar/includes/calendar_plagin_display_block.inc -> 50
calendar/includes/calendar_plagin_display_attachment.inc -> 164
Like this;
Comment #63
davidwatson CreditAttribution: davidwatson commentedThe $display param in #30 (the patch I submitted) really should be passed by reference anyway; I have no idea why it's not, so I'll go ahead and blame some combination of caffeine and sleep deprivation. If I get a chance to re-roll it today, I'll do that, otherwise it'll probably be pushed off to a future sprint for me.
Comment #64
mukwenhac CreditAttribution: mukwenhac commented#62 Works for me.
Thanks and these changes have to be applied on every file for it to function!
Comment #65
cksachdev CreditAttribution: cksachdev commentedSame issue here.. how it can be resolved ?
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 24.
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 25.
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 26.
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 28.
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 29.
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 30.
* warning: Attempt to modify property of non-object in D:\xampp\xampp\htdocs\atrium\sites\all\modules\contrib\date\includes\date_plugin_display_attachment.inc on line 31.
Comment #66
Cherrybark CreditAttribution: Cherrybark commented#62 works here. Nice job and thanks for simply showing the code.
Comment #67
anthrocks CreditAttribution: anthrocks commentedsubscribing
Comment #68
kash99 CreditAttribution: kash99 commented#62 works like a charm
Comment #69
tpainton CreditAttribution: tpainton commentedPatch #30 solved for me.
Comment #70
AdrianB CreditAttribution: AdrianB commentedManual patch in #62 worked for me.
Comment #71
mikejonesok CreditAttribution: mikejonesok commentedThanks for the patch #30
Comment #72
yarco CreditAttribution: yarco commentedSame issue as #65 said after i delete a field which created by cck module.
But after wait a few time and then refresh the page, the error disappeared...
Comment #73
sun$options never seem to be an object anywhere.
Fixed the PBR in #30
Comment #74
iw CreditAttribution: iw commentedsubscribing
Comment #75
innerfly CreditAttribution: innerfly commented#73 work ok thanks
Comment #76
davidwatson CreditAttribution: davidwatson commentedThanks for the fix Sun! I was moved to another project not long ago, so this dropped off my radar for a bit.
Confirmed in PHP 5.3 (Views 2).
Comment #77
mikekern CreditAttribution: mikekern commentedThe patch gets rid of the errors for me, but when I try to go to Date and Time settings in site configuration, I get a blank page. The Apache error log shows segmentation fault (11) error messages every time. Any ideas?
Comment #78
mikekern CreditAttribution: mikekern commentedsubscribing
Comment #79
mcneill CreditAttribution: mcneill commentedSubscribing
Comment #80
roald CreditAttribution: roald commentedSubscribing
Comment #81
KarenS CreditAttribution: KarenS commentedShould be fixed with more comprehensive patch in #698522: Make date compatible with both views 2 and views 3.
Comment #82
craigperks CreditAttribution: craigperks commentedAt work we use version cotrol to work on projects and recently downloading a site from our live server I had a similar error. It turned out that the mod_rewrite within apache wasn't switched on. I turned it on, rebooted wamp and now it's fine.
Comment #83
b3liev3 CreditAttribution: b3liev3 commentedI applied the patch and it works.
Comment #84
b3liev3 CreditAttribution: b3liev3 commentedIt's the same with calendar too.
It's a PHP 5.3 issue. It's happening the same in several modules.
Comment #85
zilched CreditAttribution: zilched commented#62 worked for me. cheers
Comment #86
hawleyal CreditAttribution: hawleyal commentedIn what way was this fixed?
2.4 and dev still have the bug.
Shouldn't it only get fixed when actually committed?
-AH
Comment #87
hawleyal CreditAttribution: hawleyal commentedPatch in #73 works in 2.4.
Comment #88
Desmatt-1 CreditAttribution: Desmatt-1 commented# 62 is ok for WAMP 2.0i and Drupal 6.16
but the views-6.x-2.8 problem, of course, remains...finally worked around
Comment #89
danbrelsford CreditAttribution: danbrelsford commented#73 seems to work. Much obliged.
Comment #90
cantarella CreditAttribution: cantarella commentedI was having the same issue but #10 resolved it.
I see no more warning sign related to date_plugin_display_attachment.inc
Thank you!
Comment #91
chientai CreditAttribution: chientai commentedI follow the method of #62 except on the file date/includes/date_plugin_display_attachment.inc -> 24, I change the code
$display->display_options['style_plugin'] = 'calendar_nav';
to
$display->display_options['style_plugin'] = 'date_nav';
Everything seems ok, but when I want to modified "view", it shows a blank page. Is there anybody encountering this?
Comment #92
a5342346 CreditAttribution: a5342346 commentedsubscribing
Comment #93
webel CreditAttribution: webel commentedsubscribing
Comment #94
Sylvain_G CreditAttribution: Sylvain_G commentedSubscribe
Comment #95
jweberg CreditAttribution: jweberg commentedI'm running on the combination of Calendar+Date on two different servers. One has PHP 5.2 and the other PHP 5.3. No errors on the 5.2 server. Can we get an official patch to 5.3 or maybe a module update that would support both PHP versions?
Comment #96
sbefort CreditAttribution: sbefort commented#62 is a sweet 5-second fix.
Comment #97
aquila CreditAttribution: aquila commentedHaving the same issue, subscribing
Comment #98
semantric CreditAttribution: semantric commentedSame issue.
Comment #99
basil.shine CreditAttribution: basil.shine commentedI had the same problem and fixed it by editing admin_module.
in admin_menu.inc changed this:
to this
and this problem with date module disappeared.
Comment #100
bdmak CreditAttribution: bdmak commentedsubscribing
Comment #101
int CreditAttribution: int commentedIt give me the php5.3 error, so isn't fixed
Comment #102
ar-jan CreditAttribution: ar-jan commentedWhen I updated to the April 14 (I think) 6.x-2.x-dev version the issue seemed solved, but now that I updated to the latest (May 2) I'm getting the warnings again.
Comment #103
enkara CreditAttribution: enkara commentedsubscribing
Comment #104
stif CreditAttribution: stif commentedsubscribing
Comment #105
micksyu CreditAttribution: micksyu commentedsubscribing
Comment #106
ami7878 CreditAttribution: ami7878 commentedI also encountered this issue after upgrading to php5.3. This patch worked for me :)
Thanks.
Comment #107
n4rky CreditAttribution: n4rky commentedApart from the fact I'm an idiot who has *no clue* about PHP, #62 worked great for me.
Comment #108
Andrew Schulman CreditAttribution: Andrew Schulman commentedsubscribing
Comment #109
davidwatson CreditAttribution: davidwatson commentedPlease read the entire issue queue before changing the status, especially the fix linked to in #81. If you still have issues, please post the full error message with steps to duplicate the problem, and bear in mind that many similar modules can spit out similar errors. Otherwise, it's a bit tough for us to track down exactly what's causing it. :]
Comment #110
Reg CreditAttribution: Reg commentedSubscribing
Comment #111
Peng.Pif CreditAttribution: Peng.Pif commentedSubscribe.
Comment #112
Reg CreditAttribution: Reg commentedSorry, I changed the status before after a long night and missing a critical detail so I'm putting it back as fixed.
Comment #113
charlieman CreditAttribution: charlieman commentedsuscribing
Is #73 the definitive fix?
Comment #114
aaron.r.carlton CreditAttribution: aaron.r.carlton commentedSubscribing - #73 appeared to fix the issue for me. Looking forward to another release to address this issue.
Comment #115
phunster CreditAttribution: phunster commented#73 appears to have worked for me.
Thank you sun
Comment #116
wildel CreditAttribution: wildel commentedsubscribing
Comment #117
queenielow CreditAttribution: queenielow commented#62 works for me..
Thanks!
Comment #118
mjh2901 CreditAttribution: mjh2901 commentedSubscribing #99 worked for me.
Comment #119
eFeS CreditAttribution: eFeS commented#73 worked for me. Thanks!
Comment #120
FreeFox CreditAttribution: FreeFox commentedSubscribing
Comment #121
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing
Comment #122
elally CreditAttribution: elally commentedSubscribe
Comment #123
ducdebreme CreditAttribution: ducdebreme commentedpatch #73 worked for me
Comment #124
jcicolani CreditAttribution: jcicolani commentedsame problem here... the patches from #30 and #71 sis not resolve. This occurred after moving my modules from root/modules to root/site/all/modules and ran update.php.
XAMPP v.1.7.3
Windows 7
Drupal 6.16
Note: The patch worked when the Date module was in root/modules but did not work in root/sites/all/modules
Comment #125
jcicolani CreditAttribution: jcicolani commentedSolved... manually updated code in:
sites\all\modules\calendar\includes\calendar_plugin_display_attachment.inc
sites\all\modules\calendar\includes\calendar_plugin_display_block.inc
sites\all\modules\date\includes\date_plugin_display_attachment.inc
per fix in #62
Patch did not apply properly so I fat fingered it.
Comment #126
krsumani CreditAttribution: krsumani commentedFix #62 did not work. It's failing in the else block with the same messages
" warning: Attempt to modify property of non-object in"
I fixed the code the following way. The error message disappeared. Please comment if you see any problem with the fix. The following should be changed in all the files giving error.
Changed the php code "$display->display_options['inherit_argments'] = TRUE;" to "$display['inherit_argments'] = TRUE;".
Comment #127
kentr CreditAttribution: kentr commented@krsumani:
Given the other suggested fixes, I'm surprised if everything functioned correctly after the change you made... If not, use this instead:
Anyone know why this would suddenly appear on PHP 5.3?
Comment #128
colanSubscribe.
Comment #129
fuerst CreditAttribution: fuerst commentedI think many of you have shown their interest in this issue now by subscribing to it. To the next Subscribers: Please don't subscribe if you don't have something helpful to say. It is just annoying to have this issue popping up in my issue list just because another Subscriber stepped in. Thanks a lot in advance!
Comment #130
AdrianB CreditAttribution: AdrianB commented@fuerst #129: So you decides who should and should not subscribe to issues on d.o.?
The problem is not people subscribing, it's the system which does allow for any other way to subscribing to topics. It is very ease to get lost on issues and topics on d.o. and sometimes you find interesting issues and development that you what to keep a close eye on. Posting a comment is the only way to put an issue or a topic on your watch list. It's a well known problem and people are working on it afaik.
But in the meantime, I think it's rude to say to others that they have no right to subscribe and follow this issue just because you're annoyed.
Comment #131
fuerst CreditAttribution: fuerst commentedI appreciate your need to keep you informed about the progress on issues. I also see the information dust provided by subscriptions like described above as a problem. Here is why: every time someone just subscribes to track an issue a red flag will appear in the My issue list of every other subscriber. This will be multiplied by all issues where people are just subscribing. Do you think it is good practice to force people doing real work to manage that unnecessary information dust just because someone wants to track an issue in his My issue list? For me it is not. Why not managing your own list of issues using another system like a simple file, your personal Wiki or Blog or just Emails as long as drupal.org does not allow better tracking of issues? In my point of view it is more important to support module developers than to maintain your own My issue list. May be I'm wrong - then this is just another particle of the information dust..
Comment #132
donquixote CreditAttribution: donquixote commentedIf you know a good method that actually works, write a tutorial and post it somewhere. So far, I don't see any such alternative.
And btw, even core and contrib developers write "subscribe" posts.
Comment #133
arlinsandbulte CreditAttribution: arlinsandbulte commented@fuerst #129: Right now, adding a 'subscribe' comment is the only way for people to subscribe to issues they are interested in.
While I agree with AdrianB, I also feel your pain.
This subscribe issue is being addressed elsewhere:
#34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment
http://3281d.com/2009/03/27/death-to-subscribe-comments
You can and should continue this conversation over there.
Better yet, contribute to help that issue along.
Comment #134
Yusuf CreditAttribution: Yusuf commentedSubscribe.
Comment #135
Zagonetka CreditAttribution: Zagonetka commented#62 worked for me, thanks!!
cheers!
Comment #136
mari3.14 CreditAttribution: mari3.14 commented#73 worked for me, ta!
Cheerio!
Comment #137
arlinsandbulte CreditAttribution: arlinsandbulte commentedTo all who are having this problem and/or are following this issue:
This issue is FIXED in the -dev version of date!You do not need apply the patch, just install the -dev version if you are having this problem.
Comment #138
steggall CreditAttribution: steggall commentedHmmm, I installed the Dev. version of Date module (6.x-2.x-dev), ran update and I'm still getting the same error.
I've got PHP 5.3.2-1ubuntu4.2 with Suhosin-Patch (cli) (built: May 13 2010 20:03:45) running on Ubuntu server 10.04 LTS. Sigh...
warning: Attempt to modify property of non-object in
/var/www/drupal-6.17/sites/all/modules/calendar/includes/calendar_plugin_display_page.inc on line 47
Update: Sorry, I was getting the date_plugin_display_attachment errors too. After installing the 6.x-2.x-dev version of date and the calendar-6.x-2.2-613528-5.patch, I seem to be clear of both problems now...
-js
Comment #139
arlinsandbulte CreditAttribution: arlinsandbulte commented@steggall
The error you describe is from the Calendar module, not the Date module.
See this Calendar issue: #613528: PHP 5.3 issue - Attempt to modify property of non-object (Calendar Module)
Comment #140
stixes CreditAttribution: stixes commentedsubscribed. #30 worked a charm
Comment #141
tribe_of_dan CreditAttribution: tribe_of_dan commentedInstalling XAMPP 1.7.1 worked for me.
Comment #142
jeff.maes CreditAttribution: jeff.maes commented#30 worked for me!
I've used Eclipse to install the patch. There is a manual at http://drupal.org/patch/apply
Comment #143
guignonv CreditAttribution: guignonv commentedpatch #73 worked for me too.
Comment #144
afriend CreditAttribution: afriend commentedcode @62 worked for me!. thanks a lot.
just to note. no need to write "else" part of the code.
cheers!
Comment #145
klucid CreditAttribution: klucid commentedYes, the dev version worked for me! Thanks!
Comment #146
Sylvain_G CreditAttribution: Sylvain_G commented#137 nice job dude
Comment #147
Carlos Miranda Levy CreditAttribution: Carlos Miranda Levy commentedNonetheless, installing the dev version brings additional errors, requiring the following patches to be applied against dev:
http://drupal.org/node/518816#comment-3008038
http://drupal.org/node/518816#comment-3027232
(which actually is http://drupal.org/node/772180#comment-2904768 - but that thread has been marked as duplicate).
Comment #148
anionsuarez CreditAttribution: anionsuarez commentedManual patch in #62 worked for me too, thanks
Comment #149
glazer CreditAttribution: glazer commentedI was able to fix this by setting the timezone in the http://www.example.com/admin/settings/date-time page, which you can get to by going to Site Configuration->Date and time.
Comment #150
alxsvdr CreditAttribution: alxsvdr commentedI tried dev version, it didn't work. Then I applied #73 from sun and it's working fine. PHP 5.3.2 here. Thanks!
Comment #151
int CreditAttribution: int commentedI think that we need to review again if this is fixed or not.
Comment #152
youngros CreditAttribution: youngros commentedI have this issue with Prosepoint installed on Ubuntu 10.04 and php5.3 is the default php.
Perhaps I am missing something but I don't know how I am supposed to apply these patches, is there anything that tells you how please?
Comment #153
kentr CreditAttribution: kentr commented@youngros:
Drupal patches follow a standard "diff" format, for which the method of applying a patch to a set of files is also standard in the programming world.
Bottom line is that you need to use a common developer's patching tool, like the unix "patch" command. There are many tools out there - some systems have them built-in, some are more user-friendly, etc.
Search Drupal.org for the handbook page on applying patches, but if it's confusing or you can't find it, google for general information on how to apply patches on the system that you're using.
Comment #154
gfxguru CreditAttribution: gfxguru commentedsubscribe
Comment #155
foka CreditAttribution: foka commentedsubscribe
Comment #156
FiNeX CreditAttribution: FiNeX commentedsubscribe
Comment #157
felix_ugf CreditAttribution: felix_ugf commentedIt is simple just to go and modify the files they said that had warning change the
$display->display_options['row_plugin'] = '';
for a
$display['display_options']['row_plugin'] = '';
and that's it.. exactly the same what it said #21
Comment #158
felix_ugf CreditAttribution: felix_ugf commentedNow if after doing that you still getting a error something like this:
warning: Parameter 1 to admin_menu_admin_menu() expected to be a reference, value given in includes/module.inc on line 471.
then you can go ahead and look here... http://drupal.org/node/360605 the path php53_warnings.patch work for me...
Comment #159
agerson CreditAttribution: agerson commented+1
subscribe
Comment #160
ShutterFreak CreditAttribution: ShutterFreak commentedI had the same PHP5.3 errors on the Date module until I applied the patch in #73.
I assume the next official release of Date/Calendar will provide a fix for this issue.
Comment #161
lucascaro CreditAttribution: lucascaro commentedpatch still working in 6.x-2.4
Please include in the next release.
Comment #162
ukrdrupal CreditAttribution: ukrdrupal commentedInside the following file: date_plugin_display_attachment.inc
It says: "class date_plugin_display_attachment extends views_plugin_display_attachment"
I think most of you in this thread are focusing on the wrong file for the solution. The key is that the says that it extends "views_plugin_display_attachment".
I then did a find ./ -name views_plugin_display_attachment.inc and came up with the following path:
/modules/acquia/views/plugins/views_plugin_display_attachment.inc
I searched for &$. You can do this through pico or nano and just use a Ctrl W, type in &$ and find each one. Just delete the &'s.
This is what fixed it for me. I hope that this will help others.
What I would really like to see is some sort of top level Drupal fix. Is there no possibility for replacement (kind of like string replacement) for &$ to $ if Drupal detects that you are on PHP 5.3.x ?? This seems like the way to fix the whole software, including the plugins, without all of us having to hack away to get it all to work.
Is this possible?
Comment #163
KarenS CreditAttribution: KarenS commentedI have no clue what to do with this. First, it is not a patch. Second, it is not to be ported. Third, there are confusing comments above about whether or not it is already fixed.
For anyone who wants to make this into something I can do something with, start by using the latest -dev version of Date, which has a ton of fixes that are not in the official release. Testing this against the official release will do no good, I need to know if there is anything that needs to be done in the latest dev version.
Changing the version to make that more clear.
Comment #164
arlinsandbulte CreditAttribution: arlinsandbulte commentedIIRC, my comment in #137 was based on KarenS' comment in #81 as well as some quick testing I did back then.
I will redo the testing to confirm.
Comment #165
arlinsandbulte CreditAttribution: arlinsandbulte commentedUpdate: I was not able to reproduce the above errors in the DATE module (I did reproduce the Calendar module errors, but that is a different issue).
I tested using:
PHP 5.2.11 & 5.3.0 (using WAMP server) & Drupal 6.19 & Date 6.x-2.4 & CCK 6.x-2.8 & Views 6.x-2.11
In order for this issue to proceed, someone MUST PROVIDE A DETAILED METHOD TO REPRODUCE THE ERROR, preferably starting with a clean install of Drupal, CCK, & Date (and possibly Views & Calendar too).
There are almost NO details about how to reproduce the error in any of the comments above.
Comment #166
Epifrin CreditAttribution: Epifrin commentedI just got the same error upon enabling Views 6.X-2.11 while Date API 6.X-2.4 was already running. No CCK here.
- Drupal 6.19 on Apache/2.2.14 (Unix) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1 Server at localhost Port 80.
Comment #167
mikeytown2 CreditAttribution: mikeytown2 commentedtry the dev version of date
http://drupal.org/node/263344
Comment #168
ShutterFreak CreditAttribution: ShutterFreak commented@Epifrin - the Date module asks explicitly for installing CCK.
I just tested with a clean Drupal 6.19 (no optional submodules enabled or disabled here - it's a clean install), and the following modules only:
The PHP error messages seem to have disappeared now.
Comment #169
koyama CreditAttribution: koyama commentedUpgrading from Date 6.x-2.4 to Date 6.x-2.6 fixed the problem. Latest dev probably also works. As #81 says, no need for any patches.
(Windows XP, XAMPP 1.7.3 (PHP 5.3.1), Drupal 6.16, Date 6.x-2.6, Views 6.x-2.10)
Comment #170
arlinsandbulte CreditAttribution: arlinsandbulte commentedFixed accroding to #168 & #169
Comment #171
Andy B CreditAttribution: Andy B commentedsubscribe
Going to look at my versions of calendar, date and views. Will give an update after checking around.
Comment #172
Andy B CreditAttribution: Andy B commentedOk. Looks like even after upgrading to views 3 I have the same problem. Looks like downgrading to php5.2 did the trick. I don't think D6 was even suposted to work on php 5.3.
Comment #173
int CreditAttribution: int commented#172 don't fixed
Comment #174
Andy B CreditAttribution: Andy B commentedSetting status to review. Maybe the developer can answer the following questions which would help us figure out if date is really broken:
1. Was D6.X designed to work on php 5.3.X?
2. Based on the answer to question 1, was date designed to work with php 5.3.X?
3. Since I see irrelavent errors about date/calendar (attempted to modify property non-object) in lots of places in D6.19 [all in administrate]: Modules, Blocks, calendar views, date settings pages, taxonomy settings/pages. Could this possibly be a D6.X core bug instead? I couldn't imagine that calendar/date is causing taxonomy settings/pages, modules, blocks not related to the calendar/date to give this error.
Maybe the developer followed standard coding practice and D6.X didn't? Either way, somone is on the wrong page and it is either D6 core or 3-4 more modules.
Comment #175
KarenS CreditAttribution: KarenS commentedI made some fixes to the calendar views handlers and then backed up and made the same ones here. The patches above were not the right solution, but I think I have something now that should work.
Most of the fixes went in today, so you need a current cvs checkout of both date and calendar or wait until tomorrow to get the -dev tarball of both.
If there's still an issue after that, using latest -dev of both Date and Calendar, please start a new issue, this one is polluted by lots of confusion about what versions of everything are being used.
Comment #176
Strae CreditAttribution: Strae commentedThanks, using 6.x-2.x-dev Calendar module released yesterday (23 aug 2010) seem to work.
Comment #177
Andy B CreditAttribution: Andy B commentedIt did. Moved back to php5.3 without any problems with date.
Comment #178
glazer CreditAttribution: glazer commentedThe error messages went away for a minute but they came right back. Setting the timezone DID NOT fix the issue. Sorry for the false info.
Comment #179
Andy B CreditAttribution: Andy B commentedDo you have the latest dev version?
Comment #180
jmcclelland CreditAttribution: jmcclelland commentedOn a system running PHP 5.2.6.dfsg.1-1+lenny9 (debian lenny) the current stable calendar (6.x-2.2) and date (6.x-2.6) do not experience this problem.
However, those versions do produce this problem on a system running php 5.3.2-1 (debian squeeze).
Using 6.x-2.x-dev Calendar module released Aug 23 2010 works on php 5.3.2-1 and it doesn't seem to break anything on 5.2.6.dfsg.1-1+lenny9, so for me this problem is solved.
jamie
Comment #181
fm CreditAttribution: fm commentedI am confused. The latest -dev version as of right now appears to be dated August 14th, prior to Karen's commitment above. Where is the August 22nd (or 23rd?) tarball?
Comment #182
jmcclelland CreditAttribution: jmcclelland commentedWoops - I meant to say latest dev version August 22 (not 23). That's the latest dev version of the calendar module - maybe, fm, you are looking at the date module downloads?
jamie
Comment #183
fm CreditAttribution: fm commentedYes, I meant the date module; sorry for the lack of clarity.
I was responding to KarenS in #175 and am still hoping of an answer.
Comment #184
sunchaser CreditAttribution: sunchaser commented#137 worked for me !
Comment #185
Slovak CreditAttribution: Slovak commentedHad the same issue. Installed the 6.x-2.x-dev release from 2010-Aug-22 and the errors went away.
Comment #186
Setimika CreditAttribution: Setimika commented#30 applying the patch on the calendar issue works perfectly
http://drupal.org/node/613528
Comment #187
kendouglass CreditAttribution: kendouglass commentedHad the same issue.
Installed Calendar-6.x-2.x-dev [from 2010-Aug-22] and the errors went away.
Using PHP 5.3.3
Comment #189
geerlingguy CreditAttribution: geerlingguy commentedHad same error, same solution as #187 - hopefully we can get the -dev rolled into the main line soon, for those using 5.3.x.
Comment #190
micnap CreditAttribution: micnap commentedHad to apply the patch from #73 AND install the calendar-6.x-2.x-dev for all the errors to go away. PHP 5.3.2.
Mickey
Comment #191
diglo_umair CreditAttribution: diglo_umair commentedi am stuck with these errors.
can anybody help plz
warning: Attempt to modify property of non-object in D:\wamp\www\bilt\sites\all\modules\calendar\includes\calendar_plugin_display_page.inc on line 47.
warning: Attempt to modify property of non-object in D:\wamp\www\bilt\sites\all\modules\calendar\includes\calendar_plugin_display_page.inc on line 48.
warning: Attempt to modify property of non-object in D:\wamp\www\bilt\sites\all\modules\calendar\includes\calendar_plugin_display_page.inc on line 49.
warning: Attempt to modify property of non-object in D:\wamp\www\bilt\sites\all\modules\calendar\includes\calendar_plugin_display_page.inc on line 50.
Comment #192
ionmedia CreditAttribution: ionmedia commenteddev calendar and date fix my issue
Comment #193
geekgirlweb CreditAttribution: geekgirlweb commented+1 subscribing
Comment #194
geekgirlweb CreditAttribution: geekgirlweb commentedEven with the latest dev versions of calendar and date I still have the same error message.
Comment #195
jmcclelland CreditAttribution: jmcclelland commentedgamerxgirl: can you paste in the exact errors that you are getting? And, what version of PHP you are running? And, if possible, a link to the site? I just updated a site to both the dev versions of calendar and date on a server running php 5.2.6 and a development machine running php 5.3.3 and neither seem to exhibit this problem.
jamie
Comment #196
wjackson CreditAttribution: wjackson commentedI was having issues with calendar as well, and updating to the dev version fixed my issue!
Comment #197
aharown07 CreditAttribution: aharown07 commentedEncountered this problem when I moved my site to a server with PHP5.3.2-1ubuntu4.7ppa5~lucid1
(In my case, the errors were displaying for Calendar... have a page with a Views events calendar that uses Date & Date Repeat API for the nodes and for displaying date info in the View)
Updating the modules to Calendar 6x2.4 and Date 6x2.7 took care of it.
Comment #198
luf CreditAttribution: luf commentedWas able to duplicate, this issue does occur when PHP is upgraded from 5.2 or lower to 5.3 or higher.
The best way to solve this problem is to go into your website's available updates list and start updating your modules so that they understand the php 5.3+.
Updating Calander / Date module to the latest releases should solve this issue for anyone.
Enjoy.
Comment #199
Dave Cohen CreditAttribution: Dave Cohen commentedThanks sun for #73.
Posting in big bold letters that it is fixed in the .dev release is nice and all, but it would be nice to be told which patch was used to fix it. Since date.module is included in acquia's distribution, I don't plan to upgrade to .dev. Instead I'll just patch the version that comes with Acquia until the fix makes it's way through.
Comment #200
carn1x CreditAttribution: carn1x commentedsubscribe
Comment #201
cubeinspire CreditAttribution: cubeinspire commentedsubscribe
Comment #202
colanPlease stop "subscribe"ing as it is no longer necessary. Instead, click on the "Follow" button at the top of the issue.
I might add that there is nothing to subscribe to as the issue is closed (fixed). If you cannot upgrade to the dev version, look through the commit history to find the relevant commit, and use that as your patch. I agree that having to search for it is less than optimal, but we don't have an issue tracker (like ChiliProject) that automatically cross-references these. For issues I work on, I post a link directly to the commit(s) when I mark an issue as fixed, but not all maintainers do this. We should probably all start doing this as a best practice.
Comment #203
regx CreditAttribution: regx commentedWhy not just cast the variable to the type the module expects.
I had a similar issue with the taxonomyblock module
From watchdog:
Attempt to modify property of non-object in /var/www/mysite/public_html/sites/default/modules/taxonomyblocks/taxonomyblocks.module on line 616.
original code:
The code is expecting cache to be an object, but it is getting an array so I just cast the array into an object
fixed code:
The only difference is (object) which cast the array returned from get_cache into an object so $cache->data[$delta] doesn't cause the "Attempt to modify property of non-object" error.
I also noticed I was getting a bunch of the call by reference errors when switching to php 5.3.
I created a small patch to fix this issue globally for all modules. This is a git patch so just place it one dir up from your public_html dir and run git apply includes_modules.inc-fix-call-by-ref.git.patch
If you do not have git try patch -p1 < includes_modules.inc-fix-call-by-ref.git.patch
or just read the patchfile in a text editor and manually apply the changes.
It just adds an ampersand in 2 places.
Comment #204
SeanA CreditAttribution: SeanA commentedWhenever you get warnings like "Attempt to modify property of non-object...", you should be able to fix it by defining the object beforehand. First declare
then you can go ahead and do $thingy->stuff.