PHP 5.2.0 is finally out!

iBlog - Ilia Alshanetsky

Quicksearch

Calendar

Syndicate This Blog

Comments

Friday, November 3. 2006

Posted by Ilia Alshanetsky in PHP

Comments (34)
Trackbacks (0)

After an extremely long (IMO) release cycle the final version of PHP 5.2.0 was finally released yesterday morning. There are many new features, speed improvements and a fair number of security changes. You can read the official release announcement for a quick summary of the major changes and the specifics can be found in a very long and somewhat boring to read changelog

The bottom line is that all users of PHP 5.x should definitely upgrade and for 4.x users need to seriously start thinking about migrating as well, since we've finally got a 5 release that not only is feature complete but is also faster or at the minimum performs at the same speed as PHP 4.4.

Big thanks to all the contributors who made patches, reported bugs and ran tests to hopefully make a solid release.

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Rene Leonhardt on :

Congratulations, this release is very important on the way to PHP 6.

I hope that from now on more ISPs will migrate to PHP 5, it is about time!

But this seems to depend mainly on the big forum and blog software developers like phpBB, administrators should test the current development releases as soon as possible.

By the way, good to see that you fixed the curl 7.16 bug.
I only hope that I can find the right configure to avoid the new segmentation faults caused by install-pear-installer soon.

Keep up the good work,
René

Ilia Alshanetsky on :

The libcurl thing is fixed in CVS, looking it what happened it certainly looks like a regression in libcurl. The changelog does not mention the password callback being gone and yet constants used to control it are no longer there.

Patrick Lee on :

This is great news! I agree with Rene that the major OSS developers like phpBB, WordPress, Joomla, osCommerce, zenCart, etc. need to embrace PHP 5.x before it will really take off. They need to follow the lead of MediaWiki which has dropped support for PHP 4.x in its newest releases (but maintained legacy support). Solid support from frameworks like CakePHP would also help.

Onward and upward to PHP 6!

Ilia Alshanetsky on :

Majority of those packages already run on PHP5, although they do not use php5 specific reasons for compatibility purposes. Majority of users still run PHP 4 for now, and they cannot be left high & dry so to speak.

Patrick Lee on :

Yes, I know most of them run on PHP 5.x since I use many of them myself on 5.1 (sorry, I should have been clearer). I just wanted to hold up MediaWiki as a "poster child" of sorts for how these projects should handle PHP 5.x. They should definitely preserve compatibility with PHP 4.x for the foreseeable future in legacy versions of their software (so as not to leave anyone "high and dry"), but they should also embrace PHP 5.x in their newest versions.

Hosting providers would be able to continue with PHP 4.x, but the advantages of offering PHP 5.x would eventually be too overwhelming to ignore. Hosts could offer both 4.x and 5.x like Dreamhost does. Their customers are able to choose on a site-by-site basis.

I would just hate to see a groundbreaking PHP 6 released and then look around to see that most web hosts and many major PHP software projects are still stuck on 4.x. PHP needs to stay competitive with the likes of Python and Ruby. Strong support from the entire "PHP ecosystem" embracing the new features is essential to making this happen. Agreed?

Ilia Alshanetsky on :

A number of applications including FUDforum run on both PHP 4 and PHP 5. In fact FUDforum even supports PDO database driver as a means of communicating with a database.

I think as long as applications can work on both versions reliable it'd be enough to give ISPs the comfort level needed to move to a new release.

Peter Senkl on :

Will the documentation be updated containing all improvements and extension of PHP 5.2 in the near future? Because now I can only use have of the futures of PHP 5.2 as I don't know the parameter list etc.

-- Peter

Ilia Alshanetsky on :

It will, although it may take sometime for the docs to catchup to the code. That said the UPDATING file linked from the release announcement is a very good place to start.

wesley on :

As fast as PHP4 you say? Where are those benchmark comparisons?

Ilia Alshanetsky on :

I have not posted the benchmarks for two reasons. First the benchmarks I have are based on my own applications, which is the only code I am inclined to test and therefor may not be representative of every bit of code out there. The second reason was to encourage people to do their own tests with their own code and see if this release does in fact work better then prior versions.

If you absolutely must see benchmarks find Sebastian Bergmann's blog, he has some available.

wesley on :

Also, I think a new superglobal should have been created, something like $_FILTERED

Ilia Alshanetsky on :

Pointless since you can make the filter extension filter all input automatically allowing your normal super-globals already to contain post-filtered content. Second it'd be potentially confusing to get all input from one source since you'd have no way to tell the source of the data, same as with $_REQUEST.

wesley on :

And one more thing, I find it rather stupid that after having filtered the data you still must check every variable to see if it is equal to null or false..

Instead it should have been made so that an $errors array would be avaiable. If isset($errors) then we can process that further..

Even better would have been if we could have added a 'message' to each filter in the definitions array. Right now you don't know if it's filter A, B or C that's causing $_GET['bla'] to be false... (If you filter on multiple things)

Ilia Alshanetsky on :

You can use the callback filter feature and create errors array etc... on error.

Char on :

Hi,

PHP 5.2 is great, unfortunately this thing does not work in 5.2

class A { protected $field; }
class B extends A { public function f() { echo $this->field; } }
class C extends B { }

$c = new C();
$c->f()

Error: cannot access protected variable in class A

It works again in the snapshot version, unfortunately again my compiled eaccelerator always problematic with snapshot version.

Char on :

Sorry, I was wrong. It seems to be caused by eaccelerator, not by PHP.

tulolit on :

Yes, it is caused by eaccelerator not PHP.

I got the same problem. I believe it can be avoided by using eaccelerator.filter in php.ini.

I managed to filter out some of php class that is using protected fields, not all.

eaccelerator.filter is a kinda tricky.
I have no idea what is the correct syntax/rule when using this filter.
This might be useful for some people :

- http://eaccelerator.net/wiki/Settings
- http://www.sitebuddy.com/forum/eaccelerator/eaccelerator_eaccelerator_filter_syntax

And if someone knows how to apply the filter syntax correctly, let us/me know please..

dave on :

does anyone else have an issue with storing a reference to an object with the object resource name, eg.
function doSomething(SomeObject $o) {
$this->store["$o"] = $o;
}
this was working with php 5.1.6, but now it dies with no error that i can see, very high level error checking on my behalf, only check the error_log

Charles on :

Hi Dave, have you tried using single quotes

$this->store['$o'] = $o;

The "$o" evaluates to $o->__toString()

dave on :

i think '$o' will not give me something unique like "Object id #11" (which is what i want)

http://php.net/types.string under "Converting to string"
:S

thanks
dave

Charles on :

Hi, Dave, how about using this

class A { }
$a = new A;
// echo "$a";
// echo strval($a);
// Gives: Catchable fatal error: Object of class A could not be converted to string in D:wwwtoolsphpiindex.php(492) : eval()'d code on line 4
var_dump($a);
// Gives: object(A)#1 (0) { }

function toStr($obj) { ob_start(); var_dump($obj); $str = ob_get_clean(); return substr($str, 0, strpos($str, '{')); }
echo toStr($a);

dave on :

i see, it was removed in php 5.2
http://www.php.net/UPDATE_5_2.txt
that's all right, not hard to implement a __toString() method with a unique identifier

Rene Leonhardt on :

Dear Ilia,

Have you ever heard of a problem with nested switch statements?
I am using PHP 5.2.0 on Windows and it results in an endless loop (although there is no surrounding loop).
When I replace the inner switch by an if statement, the execution runs as expected (just once).

Best regards,
René

Ilia Alshanetsky on :

I'm afraid I've never used nested switch statements...
Do you have a short reproduce example?

Rene Leonhardt on :

Dear Ilia,

I tracked the bug down a bit, it is related to APC and switch statements.
Windows XP Pro 5.1 build 2600, Apache 2.2.3, PHP 5.2.0 php5apache2_2.dll, APC 3.0.13-dev Revision 3.113 from Sep 25 2006 12:49:16 (the current one from http://pecl4win.php.net/ext.php/php_apc.dll).

This is the test script, just call it with ?type=selection&action=save

set_time_limit(1);

$filters = array('type'=>FILTER_SANITIZE_STRING, 'action' => FILTER_SANITIZE_STRING);
$p = filter_input_array (INPUT_GET, $filters);

if($p) {

switch($p['type']) {

case 'selection':
if('save' == $p['action'])
echo 'without inner switch';
break;

default: break;
}

if(1) {
switch($p['type']) {

case 'selection':
switch($p['action']) {
case 'save': echo 'inner switch'; break;

default: break;
}
break;

default: break;
}
}
}

If APC is activated, the inner switch terminates the new PHP thread, a console box is popping up, the browser connection to Apache is terminated and the error.log contains a line "[notice] Parent: child process exited with status 3221225477 -- Restarting.".
If I don not execute the inner switch or deactivate APC, everything works fine.

I could reproduce something similar under Linux with the same Apache and PHP version, but APC 3.0.12p2. This runs into an endless loop (actually without any loop statement) if the result contains more than 0 rows:

switch ($count = mysql_num_rows($result))

Best regards,
René

Rene Leonhardt on :

Dear Ilia,

phpMyAdmin 2.9.x is not working with APC, too.

By the way, is it technically possible to add debug versions to the automated Win32 builds on snaps.php.net?
That would make testing and generating backtraces a lot easier compared to acquiring MSVC and compiling
http://snaps.php.net/win32/php5.2-dbgpack-win32-latest.zip
by ourselves.

Keep up the good work,
René

David on :

Confirmed. phpMyAdmin 2.8.4 crashes PHP 5.2 for me when APC is installed.

I'm running Windows XP SP 2. APC is latest from pecl4win.

Anil on :

It crashes on mysql_fetch_field function. Change list says -
Fixed bug #31288 (Possible crash in mysql_fetch_field(), if mysql_list_fields() was not called previously). (Ilia)

Rene L. on :

Dear Ilia,

Good to see updated versions of the downloadable PHP manual.

Unfortunately the CHM versions seem to be broken.
When I i.e. click in php_manual_de.chm or php_manual_en.chm on Function Reference, an Internet Explorer error pops up: H:/phpdoc/en/funcref.html not found

Best regards,
René

dactar on :

phpversion('pdo') return 1.0.4dev in php 5.2.0 official release. Strange to see dev here.

Ilia Alshanetsky on :

We just forgot to update it, rest assured that the 5.2.0 release had the latest stable PDO code that was available at the time.

dactar on :

ok, thanks

Mark Crane on :

I've written a personal web server in PHP using the PHP command line interface. I upgraded it to PHP5.2 and discovered a change or bug not sure which. When running the following code from a Win XP machine with Apache using PHP 5.2:

header("Cache-Control: no-cache");
print_r(headers_list());

The function headers_list() works as expected when run from Windows XP and Apache from a web server. However if it is run from a command line then the headers_list() array is empty. In PHP 5.1.6 and other earlier versions of PHP5 the headers_list() works fine both ways.

I'm not sure if this is a bug or someone assumed that headers_list() wasn't needed for PHP via the command line. If it was removed intentionally then maybe the header() function and headers_list() should be removed from the command line. That way I or others could create functions that do the same exact thing and recover the functionality. If its a bug then that would obviously not be a good idea.

I really would like to keep the program up to date with the latest PHP5.2.

By the way I see your name on the SQLite change log for PHP. SQLite is very cool powerfull and fun database. I appreciate your work in keeping it updated in PHP.

Best Regards

Rohit Wagadre on :

I still can not figure out how to configure php-5.2.0 and apache 2.0. There is no documentation available or the google is not able to catch it!

Add Comment

Name

Homepage

Comment

In reply to

Standard emoticons like :-) and ;-) are converted to images.

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

Remember Information?

Subscribe to this entry

Frontpage - Top level

Guide to PHP Security