SMF2 and PHP5.5 - deprecated warning

[digger]

Code Select Expand

8192: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead
File: /var/www/clients/client3/web5/web/Sources/Load.php(183) : runtime-created function
Line: 3

[shadow82x]

Where do you get that warning? I get no noticeable errors on PHP 5.5.0beta3

[ziycon]

digger, if you could give more information as to where and when this occurs please we can look into it?

[digger]

I see this warnings in the forum error log since php was upgraded to 5.5.0

[shadow82x]

Confirmed on SMF 2.0.4 and 2.1 alpha. I'll probably submit an issue to Git later tonight, unless you want to ziycon.

[ziycon]

You go for shadow82x, your the one that replicated it

[shadow82x]

https://github.com/SimpleMachines/SMF2.1/issues/459

[Daniel15]

+1 - Confirmed by me as well.

Code Select Expand


2013/06/24 21:10:30 [error] 30274#0: *4045380 FastCGI sent in stderr: "PHP message: PHP Deprecated:  preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /var/www/smfshop.com/forum/Sources/Load.php(183) : runtime-created function on line 3" while reading response header from upstream, client: xx.xxx.xxx.xx, server: smfshop.com


[DSystem]

There is already a solution for this bug? I am having the same problem.

Code Select Expand


http://eletronicabr.com/index.php?action=admin;area=logs;sa=errorlog;desc
8192: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead
Arquivo: /home/forumbr/domains/eletronicabr.com/public_html/Sources/Load.php(183) : runtime-created function
Linha: 3


[shadow82x]

https://github.com/SimpleMachines/SMF2.1/pull/548/commits

It's resolution in SMF2.1 however I don't believe that fix can be applied to 2.0. (I could be wrong)

[hjf288]

I backported Spuds fixes at one point, I will try doing this one when I get time

[emanuele]

https://github.com/SimpleMachines/SMF2.1/issues/459

https://github.com/SimpleMachines/SMF2.1/pull/548/commits

It's resolution in SMF2.1 however I don't believe that fix can be applied to 2.0. (I could be wrong)

and:
https://github.com/SimpleMachines/SMF2.1/pull/570

[DSystem]

Would not have how to disable this error in function error_handler (Errors.php) of SMF?

So it is not filling the error logs, while not fixing this problem.

[Arantor]

Change index.php:

Code (find) Select Expand

error_reporting(defined('E_STRICT') ? E_ALL | E_STRICT : E_ALL);

Code (replace) Select Expand

$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)

[DSystem]

Tried this change. Most didn't work, still generating the error logs.

My forum is a dedicated server. And I was the one that put the PHP 5.5. to have more performance, more if you have a lot of bugs I'll put an older version.

[Arantor]

Interesting, as that change worked for me locally.

But SMF does not properly work on PHP 5.5 and won't for some time. SMF 2.1 does, but it is unlikely that the changes will be backported to 2.0 any time soon.

[emanuele]

There is the intention to create a patch to fix SMF (both 1.1 and 2.0) to work with php 5.5.

Someone wanted it to be included in the latest release (2.0.5), though since the security fixes were already long overdue at the end good sense prevailed and the compatibility will be worked on at some point by someone.

[Arantor]

Unless that's going to happen by the time 2.1 enters RC status, I wouldn't worry about 1.1. It's already 7 years old, far beyond its expected lifetime and frankly it's about time it was itself deprecated.

Right now 1.1 is in strict maintenance only land, 2.0 is in a similar place but right now it's the current stable version, 1.1 can't even claim that.

[DSystem]

I tried to disable these errors in php.ini. But also did not work.

Disabled the error logs on the Panel of smf and I'll wait for this update to the next update of SMF 2.0.6 

Well that would be better a MOD with these changes, to take all the incompatibilities before joining in SMF.

[VCRulez]

Any updates on the PHP 5.5 compatibility?

[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.

[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.

[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.

[ziycon]

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.

[Arantor]

They're quite big on keeping backwards compatibility, though.

[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)

[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 Expand


  // 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 Expand


  // 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?

Code Select Expand


  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.

[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.

[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.

[dan4ever]

Change index.php:

Code (find) Select Expand

error_reporting(defined('E_STRICT') ? E_ALL | E_STRICT : E_ALL);

Code (replace) Select Expand

$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???

[Arantor]

If you like.

[margarett]

Yes, you should, as 2.0.7 takes care of compatibility with PHP5.5

[dan4ever]

Thanx..
And Thanx for the update!!!

/Dan