Forum Moderators: coopster
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]
[edit]
>> migration assistance coming soon
hehehe - joy :)
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!
IMO way better anyway.
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.
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.
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]
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.
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".
However if you are looking for portability/redistribution then <? is not a good idea!
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'.
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
dc
Should we discuss what means/implications of php6 Unicode it looks like the real scary part!
READ [news.php.net]
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.
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 :-(
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.
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.
InstallationPHP 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.
BAD NEWS: Does anyone know how I can upgrade libxml.a on Solaris 10 so I can upgrade to PHP5?
