homepage Welcome to WebmasterWorld Guest from 54.163.70.249
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
PHP 4 end of life announcement
RonPK




msg:3393824
 3:41 pm on Jul 13, 2007 (gmt 0)

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

www.php.net [php.net]

 

coopster




msg:3393830
 3:43 pm on Jul 13, 2007 (gmt 0)

Looks like lots of opportunities for migration assistance coming soon! Thanks for the heads up, RonPK.

eelixduppy




msg:3393831
 3:43 pm on Jul 13, 2007 (gmt 0)

'bout time php 4 came to an end ;) Anyone serious about php development should be using 5 by now.

[edit]
>> migration assistance coming soon

hehehe - joy :)

RonPK




msg:3393838
 3:51 pm on Jul 13, 2007 (gmt 0)

Most virtual hosting providers that I know still only provide PHP 4. If they decide to upgrade, there might indeed be lots of work ahead.

henry0




msg:3394085
 7:18 pm on Jul 13, 2007 (gmt 0)

Hehe
>> migration assistance coming soon :)

And totally agree with RonPK
I know hosts the are (today but tomorrow will be the same) scared by what will happen

Most sites using "borrowed pieces" will fail and will not come back to life.
Then we will not speak of assistance but of funeral

great topic for Friday 13th!

JohnCanyon




msg:3394267
 1:04 am on Jul 14, 2007 (gmt 0)

Well, thats definitely one way to get people finally moved over to PHP5. I have been switching my projects to PHP5 for some time now.

IMO way better anyway.

timwestla




msg:3394270
 1:09 am on Jul 14, 2007 (gmt 0)

Please use the rest of this year to make your application suitable to run on PHP 5.

As if anyone has only one application...

sigh...

hopefully the conversion is not too painful.

UserFriendly




msg:3395020
 10:40 am on Jul 15, 2007 (gmt 0)

Most virtual hosting providers that I know still only provide PHP 4. If they decide to upgrade, there might indeed be lots of work ahead.

I'm with one of those providers. I keep mailing them to tell them they should be offering PHP 5 already, and they just dribble on about the current platform (which is certainly not the latest version of PHP 4) being stable, and the trouble that a move to PHP 5 would cause.

I'm looking for another web host that has their reputation for customer service (because they are good) but without their apparent terror for change.

vincevincevince




msg:3395029
 10:57 am on Jul 15, 2007 (gmt 0)

Apart from minor changes to the OO model, most PHP4 stuff works fine on PHP5... at least... for the functions I use. I imagine that if you are writing PHP3 stuff now and relying on support for depreciated methods in PHP4, then PHP5 might cause problems.

Habtom




msg:3395034
 11:09 am on Jul 15, 2007 (gmt 0)

At least I know those two might affect me.

There are some new reserved keywords.

ip2long() now returns FALSE when an invalid IP address is passed as argument to the function, and no longer -1.

Backward Incompatible Changes [php.net]

httpwebwitch




msg:3395208
 5:24 pm on Jul 15, 2007 (gmt 0)

wasn't there an issue with mysql_ commands in php5?
my servers are all still php4. i have no excuse not to upgrade. thanks for the alert

keenax




msg:3395226
 5:45 pm on Jul 15, 2007 (gmt 0)

Php5 has some serious problems regarding arrays.
For example I made a script who takes results from msn with api and sometimes you get this error with php5:

Fatal error: Cannot use string offset as an array ...

In php4 the same error won't happen. This error It's about the multilevel arrays.

The error is met in the following line of code:


$url1=strip_tags(trim($result['Responses']['SourceResponse']['Results'][$i]['Title']));

So basically this is a long multilevel array.

cmarshall




msg:3395276
 7:53 pm on Jul 15, 2007 (gmt 0)

but without their apparent terror for change.

Ain't no setch animule. An ISP, is, without exception, EXTREMELY adverse to change.

If your ISP likes to monkey with the latest tech; be afraid. VERY afraid.

They'll upgrade, half of them will screw it up, and the other half won't but will be forced to listen to hundreds of raving lunatics blaming them for "breaking the Internet."

I've been writing PHP5-compatible code for a long time. I run it on my development machine, but deploy on a couple of ISPs, one of which still runs PHP4.

I had to go hunting for an ISP that not only ran PHP5, but did so with the default options (namely, --with-xsl [us2.php.net]). Even the small percentage of ISPs that ran PHP5 had turned off most of the new features, so it was actually weaker than PHP4.

The single biggest problem that PHP 5 will present will be that it no longer accepts "<?" as a PHP code section delimiter. It now requires "<?php".

henry0




msg:3395330
 9:51 pm on Jul 15, 2007 (gmt 0)

You are indeed correct
but:
If you manage your server you may turn <? on.
Then there will be no problem.

However if you are looking for portability/redistribution then <? is not a good idea!

vincevincevince




msg:3395425
 1:12 am on Jul 16, 2007 (gmt 0)

With PHP6 in the pipeline, I'm hardly suprised that PHP4 is reaching end-of-life. Make sure you are aware of what changes in PHP6 [php.net] so that you can get your scripts ready for PHP6 at the same time - saving you the effort when PHP5 reaches end-of-life.

On the other hand, expect your ISPs to offer PHP4 for at least another year or two, end-of-life or not. Many will only upgrade when a very serious security flaw is found in PHP4 and there is no patch for it - such is the nature of many cowboys in the industry.

Suffice to say, any ISP worth hosting with will have had a test machine running PHP5 for some time for testing and will be absolutely prepared to roll it out to the production servers. If they don't, then it is probably time you find another ISP.

From the webmaster side - do consider downloading PHP 5 and installing it on a local machine (even your own machine) - installing your site (add a /etc/hosts entry to 127.0.01) - and fixing it now, offline, and away from those who might exploit errors, holes and debugging statements if you do it 'live'.

Habtom




msg:3395520
 5:15 am on Jul 16, 2007 (gmt 0)

vincevincevince

Thanks for the link.

PHP6 is having register_globals completely off.

2.1 register_globals
Issue: Register globals are the source of many application's security problems and cause a constant grief.

Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.

Conclusions:

We are going to remove the functionality.
We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting


dreamcatcher




msg:3395577
 6:34 am on Jul 16, 2007 (gmt 0)

Interesting they are removing the Safe Mode feature too.

dc

henry0




msg:3395697
 11:29 am on Jul 16, 2007 (gmt 0)

Same with Magic quotes

Should we discuss what means/implications of php6 Unicode it looks like the real scary part!
READ [news.php.net]

amznVibe




msg:3395900
 3:35 pm on Jul 16, 2007 (gmt 0)

Yah know, if php 5 is so much better, why is it slower in every benchmark comparison
against php 4, usually by a significant amount?

cmarshall




msg:3395908
 3:44 pm on Jul 16, 2007 (gmt 0)

Yah know, if php 5 is so much better, why is it slower in every benchmark comparison
against php 4, usually by a significant amount?

Probably because they are adding layers of abstraction.

Their XSLT processor absolutely blows away PHP 4's.

amznVibe




msg:3395958
 4:21 pm on Jul 16, 2007 (gmt 0)

Yeah but why should XSLT processing be native?
Shouldn't it be a library like GD that can be complied into any version?

Part of PHP's performance perception is in how it interfaces to apache.
You should see it with LiteSpeed's SAPI - instant 20% speed gain.
Add eaccelerator and it's speed is blistering.

I really don't like the idea of taking a step backward with php5's slowdown :-(

cmarshall




msg:3395964
 4:25 pm on Jul 16, 2007 (gmt 0)

Actually, that's what PHP 5 does. They use libxslt, and have a built-in native connection to it.

4 used Saxon (by default -I think you could use other processors), which is good, but I think it's Java-based. libxslt is C. I think that 4's connection was fairly indirect, and sort of a lash-up.

In any case, there is a considerable speed difference. 4 would be unusable for my workflow.

coopster




msg:3396417
 1:01 am on Jul 17, 2007 (gmt 0)

Yeah but why should XSLT processing be native?

As mentioned, native is not a bad thing. Quite the contrary usually. And it doesn't mean it is enabled by default, mind you. As a matter of fact, often times it is not, as in the case of XSLT. You still have to enable it.

Installation

PHP 5 includes the XSL extension by default and can be enabled by adding the argument --with-xsl[=DIR] to your configure line. DIR is the libxslt installation directory.

Note: This extension has been moved to the PECL repository and is no longer bundled with PHP as of PHP 5.0.0.

Note: If you need xslt support with PHP 5 you can use the XSL extension.

Resources:
[php.net...]

Back to native though, ... think about the database extensions that have been compiled into PHP such as MySQL, Postgresql and Oracle. It is often much speedier when built in. However, even when not, you have to get your configuration correct when it comes to performance. For example, I have worked on iSeries (IBM AS400 systems) installations where the Linux ODBC driver outperforms many other database drivers after tweaking the interface connections and configuration. Actually, I was astounded by the performance! I remember wondering when IBM would provide C API interfaces to PHP but after doing my homework and tweaking the interface I was quite surprised by the ODBC results.

why is it slower in every benchmark comparison
against php 4, usually by a significant amount?

Can you provide some independent results from an authoritative site? Feel free to sticky me or one of the other mods if you have a questionable resource. We are very interested in the findings and discussion on this topic. Thanks.

mattfox




msg:3396666
 6:17 am on Jul 17, 2007 (gmt 0)

I think it's a good news.

chuckstarks




msg:3397450
 8:57 pm on Jul 17, 2007 (gmt 0)

This is both GOOD NEWS and BAD NEWS. GOOD NEWS, PHP5 is better than PHP4.

BAD NEWS: Does anyone know how I can upgrade libxml.a on Solaris 10 so I can upgrade to PHP5?

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved