PHP 5.3 and Yii

The highly anticipated PHP 5.3 is formally released. This version introduced many exciting features to the PHP language itself, such as namespaces, late static binding, closures, etc. It brings PHP to a new level. We hereby congratulate the PHP developer team!

Yii framework should be compatible with PHP 5.3. If you find any problem, please let us know. Thanks.

We are not going to exploit these new PHP 5.3 features in the near future in the core framework code for the following reasons:

  1. Using the new features may introduce significant backward compatibility problem.

  2. Using the new features would mean raising the basic requirements of using Yii to PHP 5.3. We expect that PHP 5.3 needs several minor releases before getting stable enough.

  3. While namespace is cool, the strategy of prefixing all Yii core classes with letter 'C' works very well. It may be treated as a different form of namespace.

  4. Late static binding would allow us to use Post::findAll() instead of Post::model()->findAll(). It is true that the former is more pretty; however, the latter also has its own benefits because Post::model() is an object instance and can be stored in a variable.

While the Yii core code does not use 5.3 elements, application code built on top of Yii has full freedom to exploit them.

We may consider rewriting Yii 2.0 on top of PHP 5.3, but this won't happen in the near future.

Please let us know if you have any comments on our decisions above. Thank you.

Sounds really interesting, i thought they were saving up all the new stuff for the 6.0, but i was mistaken. :)

I like the idea of namepaces but i prefer having a prefix like we do now.

But hey, i’m not conservative, i wouldn’t mind using them either  8)

I know I will be using PHP 5.3 because I have control over the server environment (and by the time my project launches, PHP 5.3 will already be stable enough). Gotta love closures and late static binding. :)

Most of the shared hosting environments won't have 5.3 for at least a couple of months, I think it is a sane choice to have the core stay backward compatible.

I am a huge fan of Yii, so I really want to see Yii have great features. ;D

For upgrading to PHP 5.3, this is just what I thought this afternoon. As PHP 5.3 is newer and may be better than 5.2, but it really needs time to prove this. Yii is a very strong and effient framwork for developing, so it must confirm that it can run on most of servers, which is for PHP 5.2.  :P

And for PHP 5.3, I think it’s great to support this on Yii 2.0. At that time, maybe 5.3 is everywhere, so we won’t worry about the server problem. :D

That’s my little advice for Yii developing, and I really hope Yii will get better and better in the future. ;)

At last, I really appreciate for what you did. I can see you answered almost every questions in Chinese board. You’re really my hero!  :D

I love keeping up with the latest stable versions, although I never use brand new features out of PHP. I even dislike the idea of namespaces, as I mostly work on small projects and I don’t need additional complexity.

Speaking of future plans - how many releases are planning to make in the 1.0.x branch, Qiang?

We will continue releasing 1.0.x, mainly to fix bugs, until December 31, 2010, the scheduled end of 1.0 maintenance. We expect future 1.0.x versions will be released in a slower pace (e.g. a release every 2 or 3 months).

PHP 5.3 has up to 30% more performance than PHP 5.2!

In my humble opinion, I still wish Yii to keep ahead of other frameworks in exploiting the newest and greatest features/performances from PHP (like native MySQL driver, for performance). I'm doing ASP.NET C# for enterprise apps and I'm cheering for PHP as a programming language to get up to speed.

But, I do agree Yii should wait for sane number of months until one-third of shared hosting environments support PHP 5.3 (e.g. DreamHost) and few more future maintenance updates to stabilize PHP 5.3. I don't mind Yii breaking changes to support PHP 5.3, if we have a upgrade guide.

More performance from PHP 5.3 language itself:…rmance-win.html

More performance using Native MySQL Driver:…or/php-mysqlnd/

The post doesn't mean Yii won't work with PHP 5.3… It mainly states that the core framework code will not use the language features offered by PHP 5.3, at least in the near future.

It will take a long time for majority of share host to upgrade to 5.3.  Look how long it took for the share host to support 5.x

I think qiang is doing the right thing to ensure backward compatibility.  It is very important for wide adoption.

I haven't seen this thread when I posted a question on 5.3 support, sorry.

I agree, 5.3 will take a long time to be adopted, so it'd be smart to avoid using the new features.

Keeping backwards compatibility is not always a win-win situation. Other frameworks, like Drupal for example, do not keep backwards compatiblity in each major version (minor versions are security-fixes), which means that third-party modules have to adapt to new versions. The big plus in this, is that you don't have to carry all the old-for-the-sake-of-compatibility stuff in each new version and has proved a wise decision so far. So my point is, Yii doesn't have to be backwards compatible in each new major version. If you wish to use PHP 5.3's new features, then do so in your next major revision, just document the changes and warn developers ahead from this.

Well well, I'm testing PHP 5.3.0 with a rather old and big Prado-based system, and kaboom, an error in code, the cause:

All POSIX Regex function will be deprecated in PHP 5.3. This will cause notice when E_STRICT is on :

Function split() is deprecated in aaa.php on line xxx

To resolve this you can replace split by explode(). You should take this into account on your old or new code!! (also take into account that ereg functions will not exist in PHP 6!!!)

Also, some extensions don’t compile on 5.3.0, so far tested: adodb and perl  ::)

like rails, backwards compatibility is not the most important.

from 1.0 to 1.2, keep 1.x stable

i think 2.0 is important milestone.

I believe that yii is the best

No doubt, PHP 5.3 is have really great features. But as far as yii is concerned. It’s better to keep it on 5.2 untill 5.3 does not get proved.

Reading my daily news, I find one framework taking full advantage of PHP 5.3 and unsurprisingly moving fast, CakePHP.

Article on PHP 5.3 and CakePHP 3.0:

Source Code: Development already started on PHP 5.3 called CakePHP 3.0

Hi there,

i just updated my php from 5.2 to 5.3 in windows using apache server with 27Jul09 browscap.ini. but has met with problem occurred by either CHttpRequest::browser or get_browser or browscap.ini. none of my browsers can be detected by get_browser function. it stated:

stdClass Object


    [browser_name_regex] => �^.*$�

    [browser_name_pattern] => *

    [browser] => Default Browser

    [version] => 0

    [majorver] => 0

    [minorver] => 0

    [platform] => unknown

    [alpha] => 

    [beta] => 

    [win16] => 

    [win32] => 

    [win64] => 

    [frames] => 1

    [iframes] => 

    [tables] => 1

    [cookies] => 

    [backgroundsounds] => 

    [cdf] => 

    [vbscript] => 

    [javaapplets] => 

    [javascript] => 

    [activexcontrols] => 

    [isbanned] => 

    [ismobiledevice] => 

    [issyndicationreader] => 

    [crawler] => 

    [cssversion] => 0

    [supportscss] => 

    [aol] => 

    [aolversion] => 0


did anyone experience the same problem?


Hi all,

Problem has been resolved. I have go for another way to retrieve browser header provided by PHP comments.


希望能够早日看到 yii 2.0~

I’ve not experienced any problem with my current configuration:

  • Apache 2.2

  • PHP 5.3

  • Ubuntu Server 9.10

  • MySQL 5.1, PostgreSQL 8.5-dev, Firebird 2.5

  • Yii 1.0.11-dev

However, it is necesary to add the line below to my php.ini file:

date.timezone = America/Bogota

Obviously, Each server has his own configuration.

The above line is for not having problems with date functions.



Did anyone resolve this issue using 5.3 and yii… I am hopeing someone has but this bug to rest…

Error 500

date(): It is not safe to rely on the system’s timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘America/Los_Angeles’ for ‘PDT/-7.0/DST’ instead