SMF2 and PHP5.5 - deprecated warning

Started by digger, June 23, 2013, 06:29:54 PM

Previous topic - Next topic

Arantor

SMF 2.1 is as far as we know compatible. The changes are, unfortunately, quite extensive and making a patch for 2.0.x is both difficult and time consuming. Right now the main development effort is in 2.1 getting sorted out and pushed towards a public beta - and once that's out we can take a bit of time away (while people are trying 2.1) to fix stuff like this for 2.0. It would, interestingly, be one of the few times when a 2.0.x update would actually be released for a non security issue.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

vivien

For information, Ubuntu server 13.10 (released stable version yesterday) offers only PHP 5.5

SMF 2.0.6 will add the PHP 5.5 compatibility?

margarett

Please, read the post before yours... That's still the current state for this issue...

edit: SMF and PHP 5.5 are compatible. It's just that annoying warning about a deprecated PHP function.
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Arantor

Correct, it is a warning about something due to be removed (but has not yet been removed) - deprecated means 'it's going away, get it in order'.

The scale of changes to support PHP 5.5 is quite surprising, and far beyond what we would normally push in an incremental update. More importantly, we do have a patch in progress for this issue, but we will almost certainly release it as a patch on its own for those who need it. Mostly because the testing required is non-trivial, since it has security concerns we have to be crazy thorough about it.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

ziycon

Quote from: Arantor on October 18, 2013, 07:57:08 AM
The scale of changes to support PHP 5.5 is quite surprising, and far beyond what we would normally push in an incremental update. More importantly, we do have a patch in progress for this issue, but we will almost certainly release it as a patch on its own for those who need it. Mostly because the testing required is non-trivial, since it has security concerns we have to be crazy thorough about it.
I can vouch for this, working on a small enough application and moving it from PHP 4 to PHP 5, a nightmare! 5.5 kicked me in the teeth today regarding call-time pass-by-refernce support being removed.

Daniel15

The only way to truly improve the language is to remove things that are ugly. Honestly I wish they'd remove more than they do.
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

Arantor

They're quite big on keeping backwards compatibility, though.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

iksa

Any estimate on when the fixing mod for 2.0 would be available?

Arantor

When it's been fully tested and we're satisfied that the security implications are not an issue (since some of the changes in question have *direct* security implications)
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

scripple

The patch that Arantor posted earlier will stop the "E_DEPRECATED" errors from being posted to server logs, but it doesn't stop them from filling up the error log in SMF itself.  Here's a patch to stop them from showing up there as well.  Note that all this does is silence the errors not fix the source of them.

Change Sources/Errors.php

Code (find) Select

  // Ignore errors if we're ignoring them or they are strict notices from PHP 5 (which cannot be solved without breaking PHP 4.)
  if (error_reporting() == 0 || (defined('E_STRICT') && $error_level == E_STRICT && (empty($modSettings['enableErrorLogging']) || $modSettings['enableErrorLogging'] != 2)))
    return;


Code (replace) Select

  // Ignore errors if we're ignoring them or they are strict notices from PHP 5 (which cannot be solved without breaking PHP 4.)
  if (error_reporting() == 0 || (defined('E_STRICT') && $error_level == E_STRICT && (empty($modSettings['enableErrorLogging']) || $modSettings['enableErrorLogging'] != 2)))
    return;
  // Disable PHP 5.5 "DEPRECATED"  errors from filling the forum error logs
  if (defined('E_DEPRECATED') && $error_level == E_DEPRECATED)
    return;

DSystem

scripple. Thank you very much for the solution. Tested and approved.

I had given up on solving. Welcome to SMF.

scripple

You're welcome dsystem.

To the SMF staff, I wonder why the error_handler function is hard coded instead of respecting the error_reporting settings.  Should the error_handler exit code at the top be the following?


  if (!(error_reporting() & $error_level) || (defined('E_STRICT') && $error_level == E_STRICT && (empty($modSettings['enableErrorLogging']) || $modSettings['enableErrorLogging'] != 2)))
    return;



Then the error log in SMF would respect any disabling of error types via error_reporting() that the forum sets in index.php or anywhere else.

Arantor

First of all, no-one who wrote that code is still around. I'm only inferring based on what limited information I can find about it.

Doing it that way would make sense, but I can't help but think there was a reason why it was not done that way to start with. I do know that E_STRICT was handled the way it was because we were still keeping PHP < 5.0 compatibility, and I can't help wondering if there wasn't some reason attached to that. I'm wary of making a change like that without understanding if there wasn't some edge case the original devs knew about that I don't.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

scripple

Yeah I was asking about known edge cases and that's why my fix is the first one I posted not the second.

vivien

Any estimate on when the fixing mod for 2.0 would be available ?

Happy holidays season !

Mike Bobbitt

I've taken all the steps in this thread and still have an SMF error log filling up with warnings (80,000 in 4 days). I've added the following line to my httpd.conf and that seems to be working:

php_admin_value error_reporting 22519

This simply overrides the PHP error code at the server or virtualhost level to exclude deprecated and notice level errors.

Oldiesmann

You don't want to exclude "E_NOTICE" errors, as those are errors that can have an effect on the functionality of your forum - undefined variables, undefined array indices, etc.

Unfortunately, as has been previously stated, the sheer number of changes and the fact that they have security implications are preventing us from being able to push this out quickly. Once we've had plenty of time to test it and ensure that it doesn't cause security problems, we will release the patch.
Michael Eshom
Christian Metal Fans

scripple

Are you using SSI.php?  It has it's own $ssi_error_reporting that also needs to be fixed, although I think this only affects the server log not the SMF log.  I figure it's worth noting it's existence in this thread for completeness.

Arantor

I'm going to move this to fixed... there is a patch currently in final testing for 2.0 that fixes PHP 5.5 compatibility and will be released soon. 2.1 is fixed across the board as far as we know.
Perhaps it would have been better if I'd simply never bothered. Y'all clearly would be less unhappy that way.

dan4ever

Quote from: Sir Cumber-Patcher on August 16, 2013, 09:15:03 AM
Change index.php:

Code (find) Select
error_reporting(defined('E_STRICT') ? E_ALL | E_STRICT : E_ALL);

Code (replace) Select
$reporting = E_ALL;
if (defined('E_STRICT'))
$reporting |= E_STRICT;
if (defined('E_DEPRECATED'))
$reporting &= ~E_DEPRECATED;
error_reporting($reporting);


(Yes, I could have made it into one line but it'd be ugly because it would need another set of inline ternary expressions)

It would be better to fix them but fixing them is a very large job. I'd also wonder why your host is pushing out 5.5 already since it's only just really been launched... 5.4 is also still out there (and still active)

HI, am I supposed to take this away when upgrade to 2.0.7???
/Dan Olsson, Webmaster at https://www.guldforum.se

Advertisement: