PDA

View Full Version : Upgrade to 3.8.4, but still deprecated messages


Karel Souffriau
Tue 11th Aug '09, 6:24pm
Hi,

I've just upgraded vBulletin to 3.8.4, but I'am still getting deprecated messages:

http://tweakers.net/ext/f/PwWjo3IaU6m5E0tFAlV7gu2d/full.png

And the same errors in private.php (when opening privé messages).

Andy Huang
Tue 11th Aug '09, 8:34pm
That's odd. Please post the exact error for private.php, and any other place you're noticing this, so I can check them out...

Andy Huang
Wed 12th Aug '09, 12:07am
I am unable to reproduce this on my php 5.3.0 development environments (Windows XP + Apache + PHP 5.3.0 and Linux + Apache + PHP 5.3.0).

Please check your php settings to make sure that error_reporting is not marked as a disabled function or alike, as we need to use that to override the notice messages. Additionally, please provide the exact procedures that you were following which caused the message to trigger, so we can do further tests on our test bed.

Thanks.

Karel Souffriau
Wed 12th Aug '09, 4:34am
That's odd. Please post the exact error for private.php, and any other place you're noticing this, so I can check them out...

Deprecated: Assigning the return value of new by reference is deprecated in /var/www/.../private.php on line 147

And on line 1524, 1527, 1639, 1642, 1738, 1741 and 2100.

Karel Souffriau
Wed 12th Aug '09, 4:48am
I am unable to reproduce this on my php 5.3.0 development environments (Windows XP + Apache + PHP 5.3.0 and Linux + Apache + PHP 5.3.0).

Please check your php settings to make sure that error_reporting is not marked as a disabled function or alike, as we need to use that to override the notice messages. Additionally, please provide the exact procedures that you were following which caused the message to trigger, so we can do further tests on our test bed.

Thanks.

Gonna check my php.ini

The strange thing is, I'm getting this messages only when opening the page for the first time. After that, I can refresh the page 1000x without getting any deprecated messages.

Andy Huang
Wed 12th Aug '09, 8:21am
I'm guessing there's some cache thing setup on your server which was still caching the 3.8.3 code or something. Please do let me know if you find any way to reproduce this problem though.

Karel Souffriau
Wed 12th Aug '09, 11:48am
Hmm, that's possible. We're using xdebug, maybe this is the cause of our problem.

I keep you updated.

SecondV
Fri 14th Aug '09, 8:34pm
Same thing was happening to me, however I cleared APC (cache) and everything's fine! :)

SecondV
Fri 14th Aug '09, 8:54pm
take that back, still happening in some places for eg:



[14-Aug-2009 19:50:12] PHP Deprecated: Assigning the return value of new by reference is deprecated in /home/*/member.php on line 353
[14-Aug-2009 19:51:33] PHP Deprecated: Assigning the return value of new by reference is deprecated in /home/*usercp.php on line 126
[14-Aug-2009 19:51:36] PHP Deprecated: Assigning the return value of new by reference is deprecated in /home/*/profile.php on line 733
[14-Aug-2009 19:51:47] PHP Deprecated: Assigning the return value of new by reference is deprecated in /home/*/private.php on line 147

eg, line 147 in private.php is:

$bbcode_parser =& new vB_BbCodeParser($vbulletin, fetch_tag_list());
=& new - is the problem.

Andy Huang
Sat 15th Aug '09, 6:41pm
=& new is not the problem... well it is and it isn't.
It is what will trigger the deprecated message, but the message is not suppose to come up because it should be disabled by the error handling procedures.

If you are not seeing the messages on screen, but are seeing them in the error logs, then it is caused by a bug in PHP 5.3.0: http://bugs.php.net/bug.php?id=48843 which we can't do anything about.

If you are seeing them on screen, then it may be something else, such as a caching problem.

dieselpowered
Thu 8th Oct '09, 3:20am
I was receiving the following error:

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 55

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 107

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 111

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 119

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 130

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 134

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 142

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 211

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/init.php on line 389

Deprecated: Assigning the return value of new by reference is deprecated in /xxxx/xxxx/xxxx/forum/includes/class_core.php on line 2552I ended up removing the '&" where it was '=&' and the problem went away. 3.8.4, PHP 5.3.0.

Dilly
Thu 8th Oct '09, 3:31am
I was receiving the following error:

I am receiving this error when clicking on Manage Tabs in AdminCP...any thoughts?
I ended up removing the '&" where it was '=&' and the problem went away. 3.8.4, PHP 5.3.0.
Re-read the last post. It's a poor man's fix.

dieselpowered
Thu 8th Oct '09, 3:43am
Thanks for the response Dilly, I did actually read that and still receive those errors...error reporting is on in the PHP.ini so I am not sure what is going on. The only successful way to get those errors to go away was to remove the "&"

Any other ideas?

PitchouneN64ngc
Thu 8th Oct '09, 6:30am
Wait for PHP 5.3.1? Or update to PHP 5.3.1RC1? :)

dieselpowered
Thu 8th Oct '09, 12:20pm
True, maybe just leave the file edits in place until a new PHP version is released.

digitalpoint
Sun 11th Oct '09, 2:22am
I was also seeing the issue, but for whatever bizarre reason it seemed to only be happening the first time the file was accessed after Apache was restarted (maybe something weird with that file when it's not being hit on the caching system or something?)

I didn't (don't) care all that much though since it only happens once (after httpd2 restart) and only for admin (me), so not like anyone else sees it.

PitchouneN64ngc
Tue 3rd Nov '09, 9:21am
Ok i checked a little, and it seems with 3.8.4, i have again these messages but in error_log file. If error messages appears in forum, it should be because your PHP configuration have "display_errors = On;".

But these errors make my error_file 91MB! There isn't any other fix we could have for 3.8.5?

smokey
Sun 17th Jan '10, 8:16pm
Yes same here. 3.8.4 PL2 and PHP 5.3.1 does not fix the issue. Getting it on usercp.php, showthread.php, group.php, private.php, login.php, etc... My scripts are not cached. Error Logs growing way to fast, im talking several gb a day (which hiding the error with display_errors will not stop the logs issue). Error still occurred with hooks disabled.

Thought this was supposed to be fixed in 3.8.4?? I updated my 3.8.4 files with a latest download from today, still showing error!

I do not like the fact i need to turn off error reporting in the php.ini, vhost, or htaccess to simply "hide the problem". We need this fixed. Having to update all my files to fix the bug really isn't the best use of my time. This is something that needs to be fixed for everyone. All I noted was the change to error_reporting(); which did not solve anything. It may hide it for some, but not others which may be related to php itself. All and all that just hides the problem and still dumps the log no matter what. =& is the problem...

Can you provide a separate download for php4 users? I mean all do respect, php4 reached EOL in 2007. PHP 5 has been out for 6 years now. Anyone using 4 really should upgrade, there really is no excuse at this point for running version 4. Those needing it for old scripts should run side by side like we did with php3 back in the day.

Linux Machine 2.6.18-164.9.1.el5 x64
Apache 2.0.63
PHP 5.3.1
vB: 3.8.4PL2

I am a developer and need my errors on in php.ini. For those who do not want to disable server wide, put this in the vhost or .htaccess file the problem site:


php_flag display_errors offI don't plan on keeping that there especially as it does not solve the issue with my error_log. I hope we have an answer by 3.8.5. Not ready to make a jump to 4 yet, have a lot to do to get there.

Thank you.

smiggy
Mon 18th Jan '10, 1:29pm
Yes same here. 3.8.4 PL2 and PHP 5.3.1 does not fix the issue. Getting it on usercp.php, showthread.php, group.php, private.php, login.php, etc... My scripts are not cached. Error Logs growing way to fast, im talking several gb a day (which hiding the error with display_errors will not stop the logs issue). Error still occurred with hooks disabled.

Thought this was supposed to be fixed in 3.8.4?? I updated my 3.8.4 files with a latest download from today, still showing error!

I do not like the fact i need to turn off error reporting in the php.ini, vhost, or htaccess to simply "hide the problem". We need this fixed. Having to update all my files to fix the bug really isn't the best use of my time. This is something that needs to be fixed for everyone. All I noted was the change to error_reporting(); which did not solve anything. It may hide it for some, but not others which may be related to php itself. All and all that just hides the problem and still dumps the log no matter what. =& is the problem...

Can you provide a separate download for php4 users? I mean all do respect, php4 reached EOL in 2007. PHP 5 has been out for 6 years now. Anyone using 4 really should upgrade, there really is no excuse at this point for running version 4. Those needing it for old scripts should run side by side like we did with php3 back in the day.

Linux Machine 2.6.18-164.9.1.el5 x64
Apache 2.0.63
PHP 5.3.1
vB: 3.8.4PL2

I am a developer and need my errors on in php.ini. For those who do not want to disable server wide, put this in the vhost or .htaccess file the problem site:


php_flag display_errors offI don't plan on keeping that there. I hope we have an answer by 3.8.5. Not ready to make a jump to 4 yet, have a lot to do to get there.

Thank you.

Me too.

frak36
Thu 21st Jan '10, 10:32pm
had exact same problem 15 minutes ago.
Change =& to =
On the lines error gave you

digitalpoint
Thu 21st Jan '10, 11:55pm
Why are we not removing the "=&" from the code at this point? It's depreciated, the minimum required version of PHP supports the "correct" way to do it, and it seems fixing the actual syntax used would be far easier than just ignoring and trying to suppress the errors.

SecondV
Fri 22nd Jan '10, 2:07pm
Indeed, I don't know why this hasn't been taken care of by now if you're requiring a version of PHP where this is no longer necessary.

SecondV
Fri 22nd Jan '10, 2:08pm
This needs to be addressed, petitioning for it to be "Confirmed"

Andrew Elkins
Fri 22nd Jan '10, 7:14pm
3.8.4 code was written for an older version of php (php4) and you are running a more up-to-date version (PHP 5.3) where this is now deprecated. This is required in php4 so it will not be "fixed." However if you want to stop the warnings change:
in admincp/options.php
ln 1150:

$db_alter =& new vB_Database_Alter_MySQL($db);

to

$db_alter = new vB_Database_Alter_MySQL($db);


Also on line: 1185

$db_alter =& new vB_Database_Alter_MySQL($db);
to

$db_alter = new vB_Database_Alter_MySQL($db);

That should fix your issue.

PitchouneN64ngc
Fri 22nd Jan '10, 7:22pm
Just a little addition: you must to change ALL '=&' to '=' in ALL files for ALL use of this ONLY if you are on PHP 5.3. With that, ALL messages gone.

Andrew Elkins
Fri 22nd Jan '10, 7:31pm
Just a little addition: you must to change ALL '=&' to '=' in ALL files for ALL use of this ONLY if you are on PHP 5.3. With that, ALL messages gone.
Correct, Thanks for adding the clarification.

digitalpoint
Fri 22nd Jan '10, 7:34pm
I wasn't suggesting change the code in 3.8.x, but why don't we do away with it in 4.x? The minimum required version of PHP works fine with the new (proper) way of doing it. It just seems more logical to fix the root of the problem, vs. instead coming up with ways to suppress the errors.

Edit: Nevermind... I stand corrected. I just grepped for "=& new" in vB4, and there is none, so it was already done. I'm shutting up now. :)

smokey
Fri 22nd Jan '10, 7:48pm
3.8.4 code was written for an older version of php (php4) and you are running a more up-to-date version (PHP 5.3) where this is now deprecated. This is required in php4 so it will not be "fixed." However if you want to stop the warnings change:

That should fix your issue.

That doesn't work for me. I'm to busy to change that line. Why not have php 4 users edit their code? Like I said, it reached EOL 2 years ago. Or better yet, why not make it compatible for everyone (see an example of how below) as you promised when we bought our licenses. It's not compatible with 5.3 when you're using deprecated code. Why should we (the ones who are up to date) have to change our files? There are other ways around it, rewrite it or provide a separate download for php4. I am managing 10 copies of vb 3.8.4. There is absolutley no way I am editing all those files. This needs to be addressed by vBulletin.

I am paying my subscription fee's for my accounts for a reason. To keep receiving new "working" upgrades. So basically what you're telling us is we are SOL? I am not getting what I pay for now by having to make my own changes. I am not ready to upgrade to 4 and 3.8 is still active. Like I said, I want an answer by 3.8.5.

Here's a suggestion, why not do something like this:


if (strnatcmp(phpversion(),'5.3.0') >= 0) {
$bbcode_parser = new vB_BbCodeParser($vbulletin, fetch_tag_list());
} else {
$bbcode_parser =& new vB_BbCodeParser($vbulletin, fetch_tag_list());
}
Did not test but it should work. You see where I'm going with this? There are other ways than just "hiding the error". We are not getting our moneys worth when you just "hide the error". Please fix!

EDIT: after thinking about it, that probably won't work. It's still going parse the entire thing. There's other ways around it, guess just change up the class so = works as expected in 4.

Andrew Elkins
Fri 22nd Jan '10, 8:45pm
I wasn't suggesting change the code in 3.8.x, but why don't we do away with it in 4.x? The minimum required version of PHP works fine with the new (proper) way of doing it. It just seems more logical to fix the root of the problem, vs. instead coming up with ways to suppress the errors.

Edit: Nevermind... I stand corrected. I just grepped for "=& new" in vB4, and there is none, so it was already done. I'm shutting up now. :)
:)


That doesn't work for me. I am managing 10 copies of vb 3.8.4. There is absolutley no way I am editing all those files. This needs to be addressed by vBulletin.

I am paying my subscription fee's for my accounts for a reason. To keep receiving new "working" upgrades. So basically what you're telling us is we are SOL? I am not getting what I pay for now by having to make my own changes. I am not ready to upgrade to 4 and 3.8 is still active. Like I said, I want an answer by 3.8.5.

Did not test but it should work. You see where I'm going with this? There are other ways than just "hiding the error". We are not getting our moneys worth when you just "hide the error". Please fix!
I understand your concern when you own 10 boards. I'll bring it up for discussion for 3.8.5

smiggy
Fri 22nd Jan '10, 10:11pm
Andrew, any idea when 3.8.5 will be released?

Many of us have been awaiting some sort of announcement about it for months now.

Andrew Elkins
Mon 25th Jan '10, 4:42pm
It was delayed since vb4 had an "all hands on deck" approach leading up to its release. As far a more specific date in releasing 3.8.5, I don't have a solid date to give you. I'll try and determine a general date for you.

smiggy
Mon 25th Jan '10, 8:43pm
I got a PM reply once from Ray Morgan before he left telling me there will be an announcement about it just right after vB 4 would hit gold as to when the 3.8 maintenance releases will be reinstated and that was more than a month ago. The fact you announced recently you still intend to support it with bug fixes etc is adding more salt to the wound for those who renewed their owned licenses not too long ago after being told a while ago from the old-timers that maintenance releases will always be around every 2 months.

Andy Huang was once appointed to fix 3.8 bugs but according to Floris he is now busy with school so that leaves who? The 3.8x bug tracker has been dead as a barren e-wasteland.

It really is a kick in the teeth and there is no way I am going to cough out another $175 just to dowload maintenance releases after my license expires. Sorry to vent but a decision has to be made ASAP and I think I speak on behalf of many. I really wish the old developers were still around.

smokey
Sun 31st Jan '10, 11:42pm
Time for an update?

smiggy
Mon 1st Feb '10, 2:36pm
Good luck.

Andrew said he'll try getting a general date for us and that was over a week ago now.

They'll let us know when they can be bothered.

Andrew Elkins
Mon 1st Feb '10, 2:53pm
Hi all,

For 3.8.5 we've got a developer focused on getting 3.8.5 fixed up and ready to release. That said, we'll have a far more solid date on when he will have it completed within the next week. So for now I don't have a specific date to give you.

Andrew

smiggy
Mon 1st Feb '10, 4:12pm
Andrew, do you mind me asking which developer it is? Just curious...

Andrew Elkins
Mon 1st Feb '10, 6:58pm
Andrew, do you mind me asking which developer it is? Just curious... While there is a primary developer on 3.8.5 this doesn't mean that no other developers will have input or provide bug fixes. I'd rather not single out one developer when there will still be other developers involved. I hope you understand.

Andrew

smiggy
Tue 2nd Feb '10, 1:30pm
Maybe this deserves an official announcement. Doubt all 3.8x series will be checking this bug report.

I'm sure many will be really happy.

Kevin Sours
Wed 3rd Feb '10, 12:51pm
In doing some research what's happening is that php is throwing the deprecation warnings on the parse pass rather than at runtime. This means that the warnings are thrown before the error_reporting call runs (which is set to suppress these warnings). If you supress these warnigns in the ini file (or a .htaccess file that modifies the php configuration), then that should solve the problem (unlike turning off display_errors this will remove them from log files as well). To do this change the error reporting like to :

error_reporting = E_ALL ^ E_DEPRECATED

smiggy
Wed 3rd Feb '10, 1:18pm
OK, but the question will this still be fixed in the 3.8.5 release?

Andrew Elkins
Wed 3rd Feb '10, 2:25pm
Yes this is getting addressed for 3.8.5.

smiggy
Wed 3rd Feb '10, 3:53pm
Fantastic.

Good to see bugs being finally at last for the 3.8 series. Brings back memories of Mike, Scott and Kier! :D

Andrew Elkins
Thu 4th Feb '10, 12:09pm
Fantastic.

Good to see bugs being finally at last for the 3.8 series. Brings back memories of Mike, Scott and Kier! :D Yeah, I'm excited to be able to get an update to the 3.8.x series out. It's been a long wait!

smiggy
Thu 4th Feb '10, 1:33pm
Likewise.

Did you know work with any of the original developers?

Andrew Elkins
Fri 5th Feb '10, 12:40pm
I work with Freddie Bingham, his expirence with vBulletin is invaluable not to mention a nice guy as well. As far as the other original devs I was ramping up when they were departing so my interaction with them was very limited. They were very knowledgeable of vBulletin and I'm sure it would have been nice to work along side them as well.

smiggy
Sun 7th Feb '10, 10:19am
I think Freddie is the only old-timer left from the early days.

I hope the 3.8.5 release is around the corner. You might want to consider appointing another developer because there is a huge back-log of Unconfirmed bug reports for 3.8.

Andrew Elkins
Mon 8th Feb '10, 4:05pm
For those that are interested, I posted an update on the status of 3.8.5 (http://www.vbulletin.com/forum/showthread.php?340878-Update-vBulletin-3.8.5-Status) in the Announcement Forum.

smiggy
Mon 8th Feb '10, 4:11pm
Super! I am well excited now. :D

I knew my persistence in bugging all the staff would pay off eventually.

Is Xiaoyu solely responsible for all the 3.8 bug fixes? Not seen any other developers reply to the bug reports.

Andrew Elkins
Mon 8th Feb '10, 4:24pm
I suppose you've figured it out, but yes Xiaoyu is the primary developer working on 3.8.5. Other developers have/may provide input but he is leading the effort to get 3.8.5 ready for release.

smiggy
Mon 8th Feb '10, 4:49pm
Would that include this particular bug?

It says it's been assigned to you and David?

Andrew Elkins
Mon 8th Feb '10, 5:02pm
Xiaoyu is well aware of this bug, assigning it to him for record keeping sake.

smiggy
Mon 22nd Feb '10, 4:13pm
I hope this bug gets fixed before release?

Xiaoyu
Mon 22nd Feb '10, 10:37pm
Fixed in 3.8.5

smiggy
Fri 26th Feb '10, 12:20pm
Good to see this bug has been fixed.

Xiaoyu, are anymore bugs going to be fixed in 3.8? Been quiet for a while.

msensenbach
Wed 3rd Mar '10, 6:52pm
This appears to be fixed in 3.8.5. If the messages still appear after you upgrade to 3.8.5, please petition this bug.

smokey
Sun 7th Mar '10, 10:59pm
Great! Do we have a approx. date for the release of 3.8.5?

Darkshenron
Mon 8th Mar '10, 10:24am
Great! Do we have a approx. date for the release of 3.8.5?
You can find the latest info on this here (http://www.vbulletin.com/forum/showthread.php?340878-Update-vBulletin-3.8.5-Status). :)

smiggy
Mon 8th Mar '10, 12:10pm
That update is old and we're already past early March so that thread should be updated.

Plus the number of bugs fixed in 3.8.5 is considerably low to what I was originally hoping.

Darkshenron
Mon 8th Mar '10, 2:35pm
There are 23 bugs marked as fixed for 3.8.5. 20 of them are marked as Fixed (Closed), that means the QA has confirmed these bugs to be fixed, while 3 are still marked as Fixed (Pending). Assuming that the three remaining Fixed (Pending) bugs don't have any other issue, and will be confirmed to be indeed fixed by QA, I suppose that 3.8.5 should be out within this week. But this is just my guess. :)

smiggy
Wed 10th Mar '10, 2:46pm
Can one of the devs please update the announcement to when 3.8.5 will be released? :D

PitchouneN64ngc
Wed 10th Mar '10, 3:30pm
Each time there is a new release, an announcement is made.

Andrew Elkins
Wed 10th Mar '10, 4:35pm
We will be making an announcement within a day or two.

smiggy
Wed 10th Mar '10, 4:45pm
I also have a side question.

Is this going to be the LAST 3.8 maintenance release? If so it might be worth post-poning because there are still loads of bugs to be fixed reported from months back.

PitchouneN64ngc
Wed 10th Mar '10, 4:52pm
I saw a bug on 3.8.5 which was marked fixed for next release... Maybe yes, maybe no :)

smiggy
Wed 10th Mar '10, 5:48pm
I prefer to Andrew to comment on this, thanks! :)

Paul M
Wed 10th Mar '10, 5:55pm
There is no reason at all to think that 3.8.5 will be the last release - it is still a supported version.

smiggy
Thu 11th Mar '10, 9:27pm
According to Don, 27 bugs have been fixed but only 23 are listed in thread.

Which are the other 4 bugs?

Mystics
Fri 12th Mar '10, 5:12am
Those are private issues (not public visible).

Andrew Elkins
Fri 12th Mar '10, 2:29pm
I also have a side question.

Is this going to be the LAST 3.8 maintenance release? If so it might be worth post-poning because there are still loads of bugs to be fixed reported from months back. This package was ready to get out, so there was no reason to delay releasing it further. We plan to go through the current bugs on the 3.8.x to see how impacting the issues are and then we'll go from there.

If you feel so inclined to help create a list of 20 or so "must have" fixes we would be more than happy to go over those as well. I won't commit to fixing the 20 you list but it certainly will help us get started.

Thanks