News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

SMF2 and PHP5.5 - deprecated warning

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

Previous topic - Next topic

digger

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
Colin B
Former Spammer, Customize, & Support Team Member

ziycon

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

digger

#3
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. :P
Colin B
Former Spammer, Customize, & Support Team Member

ziycon

You go for shadow82x, your the one that replicated it :)

shadow82x

Colin B
Former Spammer, Customize, & Support Team Member

Daniel15

+1 - Confirmed by me as well.

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
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!

DSystem

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


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)
Colin B
Former Spammer, Customize, & Support Team Member

hjf288

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

emanuele



Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

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

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. :P


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

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

#18
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.
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.

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.

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

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

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.

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

Arantor


margarett

Yes, you should, as 2.0.7 takes care of compatibility with PHP5.5
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

dan4ever

Thanx..
And Thanx for the update!!!

/Dan
/Dan Olsson, Webmaster at https://www.guldforum.se

Advertisement: