PHP 5.3. EE uses ereg instead of the faster preg_match, the former of which has been declared deprecated and now throws an E_DEPRECATED notice.
In addition there are some issues with references and values being generated when you use extensions!
Basically it amount to not being able to use extensions.
My host is going to switch to 5.3 in a few days, so something needs to be done quick.
Why is your host updating that quickly? That seems wildly irresponsible. Respectable hosts will not force a server technology upgrade on you within days of its release. PHP 5.3 won’t even get picked up in major commercially supported server distros for months, perhaps a year or more.
Regardless, you can avoid the E_DEPRECATED errors by changing the error_reporting() level. The code will still function just fine. On the extensions issue, the PHP team decided to make some non-backwards compatible changes with this release, and we’ll arrange to accommodate that in a future build. We’re not jumping to the ticks of their clock, as the history of PHP’s 5.x releases have shown that we’d be chasing a moving target until at least x.x.1.
They’re updating this quickly because php 5.3 has been tested like crazy for the past year. Its very stable. In addition, the devs have been warning for months now to test applications with 5.3 before its released.
Who is your host? I can guarantee you that the lion’s share will look at adopting the also-just-released 5.2.10 before they look at 5.3. Hosts don’t make changes because the programming team of a server-side scripting language tell them to. The PHP Team proclaimed PHP 4 dead two years ago, but the majority a large number of* of the commercially supported hosting market still offers PHP 4 by default.
And I’m not calling into question 5.3’s stability or benefit, but we’d be foolish to consider it as static given the development history of PHP and dot-oh releases.
But thank you for reporting, I have it earmarked to look at soon, and as I mentioned, will be addressed in a future build.
* Edit: there aren’t current statistics available to support the use of the word “majority” even though that was the case at the time of the last widely published statistics. They are a few months stale, so I’ll give the benefit of the doubt that perhaps the balance has turned in favor of PHP 5 finally, although 5.2+ is still the smallest wedge.
My host is idologic.com. But regardless, I, and I suspect many others, want to turn their personal environments into 5.3. So in order to do that, I have to pull off tricks like install 5.2 as a cgi, or run two different version of apache. Would be much simpler if I didn’t have to do that.
EDIT - As an aside I went to that host you mentioned and they say on their site that you can use either 4.4.x or 5 on your server and that you can do this on a directory by directory basis using .htaccess. Could you not just get ExpressionEngine running on 4.4.x for now until it works with 5.3? I don’t think there will be any major benefits to running it on 5.3 would there Derek?
Avi Block - 02 July 2009 09:49 AM
My host is idologic.com. But regardless, I, and I suspect many others, want to turn their personal environments into 5.3.
Nope not me, not until it’s been real world tested a lot more than it has been. Like anything that’s new it needs a lot of testing and whilst there may not be anything wrong with it (I’m sure there will be some things somewhere ) for a host to force something that new on everyone is definitely a little irresponsible as Derek has said.
I must admit the other day I was trying to use a new PHP function which is only available in 5.3 and didn’t realise but managed to fix my code to work in older versions. Personally though it’s like anything such as new operating system versions, I always wait a while until it’s been tested by others first and most of the bugs have been ironed out
I’m sure that the team though will get it working in a future build as Derek mentioned above though. If they say they will do something then they always do and my hats are totally off to them in that respect
EDIT - As an aside I went to that host you mentioned and they say on their site that you can use either 4.4.x or 5 on your server and that you can do this on a directory by directory basis using .htaccess. Could you not just get ExpressionEngine running on 4.4.x for now until it works with 5.3? I don’t think there will be any major benefits to running it on 5.3 would there Derek?
In my particular case I can’t because I have some custom extensions running which require PHP 5.
Mark Bowen - 02 July 2009 10:03 AM
Nope not me, not until it’s been real world tested a lot more than it has been. Like anything that’s new it needs a lot of testing and whilst there may not be anything wrong with it (I’m sure there will be some things somewhere wink ) for a host to force something that new on everyone is definitely a little irresponsible as Derek has said.
PHP 5.3 has been in development for two years. It has 73.2% code coverage. We have been warned to test our software with it for the past year. They even delayed it another week just to make sure everything was stable.
I can understand a reluctance to move from 4 to 5. Back in those days, unit testing was barely heard of. Nowadays its the norm.
I can hardly imagine anything that you would do in PHP would run in to the few bugs minor bugs left.
Avi, I repeat, I’m not questioning 5.3’s stability or quality, but rather the permanence of implementation of any of the backward incompatible changes and implementation of new features, as well as whether or not adjustments we make to accommodate would continue to work. You can choose to trust that they won’t change behaviors when moving to x.x.1, but actions are louder than words and history tells me to wait and see.
But, since your host is trudging forward, this should let you continue to use EE in that environment for now.
/system/core/core.system.php line 217 change to:
error_reporting(E_ALL & ~E_DEPRECATED);
/system/core/core.extensions.php around line 115 modify:
if (sizeof($args) == 1) { $args = array($which, ''); }
if (version_compare(PHP_VERSION, '5.3') >= 0) { foreach ($args as $k => $v) { $args[$k] =& $args[$k]; } }
if (version_compare(PHP_VERSION, '5.3') >= 0) { foreach ($args as $k => $v) { $args[$k] =& $args[$k]; } }
You’ll also need to make sure that date.timezone is set in your php.ini or via .htaccess to the correct time zone for your server, or you’ll have tons of warning level errors for date/time localization.
Thanks for your reply.
There’s one item you left out which is as a result of “The behaviour of functions with by-reference parameters called by value has changed. Where previously the function would accept the by-value argument, a warning is now emitted and all by-ref parameters are set to NULL.”
Therefore on line 278 (after you add that other stuff in) of core.extensions.php should be:
It did not seem to have any impact on how extension hooks provide parameters or on how the methods received them, presumably since the args are already references. Do you have a sample of a hook usage that would trigger this warning?
Yeah, my testing showed that PHP 5.3 accepted them all by reference regardless of by-reference declaration, since they are reassigned as reference in the caller. Please let me know if you find otherwise. I believe the issue arrises if you declare by-reference parameters and use values in call_user_func*.
The error message you’re reporting is a bit confusing. First, it’s an error where the $FNS->redirect() function cannot send a header because PHP has already begun serving output. The line where the output began is an eregi() call in the database drive, which indicates to me that your deprecation errors are not being hidden.
You were correct in that I turned on E_DEPRECATED in the session initialization, but not globally. Touché Mr. Jones, you’ve won this round but the day will yet be mine!
However, enabling the CP jQuery extension still turns the screen a beautiful white. There is no error logged to the console or screen unfortunately.
White screens in PHP are either crashes (if under CGI) or hidden PHP errors. I’m still not convinced that you have errors properly enabled, since that operation is not one that would lead to a memory-crushing CGI crash.
) for a host to force something that new on everyone is definitely a little irresponsible as Derek has said.
