Minimal PHP version requirement

[qiangxue]

This ticket collects the minimal PHP version requirements from various classes. We will determine the final minimal version requirement when we finish the core framework classes.

• 5.3.2
  • stream_resolve_include_path
• 5.3.3
  • Json::decode(): use of constant JSON_ERROR_UTF8, http://us1.php.net/manual/en/function.json-last-error.php
• 5.3.7
  • SecurityHelper::generateSalt(): use of $2x$ and $2y$ Blowfish modes to deal with potential high-bit attacks. See http://www.php.net/manual/en/function.crypt.php
  • Fatal error handler doesn't work well on Windows in some cases for PHP < 5.3.7

[bwoester]

Just found this project: PHP_CompatInfo
Maybe it can be included in the Travis configuration. Both to help finding minimal PHP version requirements and later to ensure new commits don't introduce higher requirements.

[klimov-paul]

I can not tell for everyone, but I usually deal with Linux CentOS as a basis of web server. Since CentOS is a free version of RedHat, it is common choice for the server systems, which do not require any visual interface.
Currently, the latest available PHP version at CentOS is 5.3.3, which is already too low for Yii2. However you can at CentOS you can use ‘Remi’ respository, which provides the PHP version 5.4.20.

There are several major advantages, which Yii can benefit from using PHP 5.4:
– Usage of traits can increase code reusage and flexibility
– Array short syntax ([‘a’=>’b’]) can “purify” the code appearance

In our pursuit for the better functionality we have already raised the requirements up to 5.3.8, why stop there?
The Yii1 was released and supported to be compatible with 5.1, which becomes deprecated very soon after release, while support for the features from 5.3 (such as namespaces) created a issues, which have been resolved only lately.
If we are going to step into PHP 5.4, we should do this as early as possible to develop framework, which matches its features and needs.

We have already found that at least Ubuntu and CentOS do not support PHP 5.3.8 natively, I would not be surprised if many other Linux distributives will have same problem. If we have already overcome the common restrictions, why we can not overcome them further for the “better future”?

[samdark]

Because of stats: http://w3techs.com/technologies/details/pl-php/5/all

[klimov-paul]

At these “stats” it is hard to tell which exact “5.3” version is used. I assume in this statistic “5.3” means “5.3.3”. I doubt it matches “5.3.8”.

[klimov-paul]

As I said before, I am afraid we have already overstep the most spread PHP version by requirement of “5.3.8”

[samdark]

http://w3techs.com/technologies/details/pl-php/5.3/all

[klimov-paul]

OK, let’s do some precise calculations, just in case.
Version 5.* is used in 97.3%, so assume it covers 100% just for simplicity.
5.3 is used in 52.0%
5.4 – 8.1%
5.5 – 0.5%
So 5.4 + 5.5 = 8.1% + 0.5% = 8.6%
Now, not every 5.3 version matches Yii – only 72.1% of 5.3.* usage matches 5.3.7 or higher.
52.0 * 72.1 / 100 = 37.49 % – usages version 5.3, which matches Yii.

Summary:

1. For requirements 5.3.7 usage percentage equals to 46.09%
2. For requirements 5.4.0 usage percentage equals to 8.6% (18.65% of the 1st one)

[samdark]

Yeah. So while 5.3.7 looks like safer approach compared to 5.4. Featurewise there were no things we can't do with 5.3 till @cebe refactored AR to use traits. So far that's the only valid usage. Short array syntax is just a bonus, not a tech stuff.

[qiangxue]

Can we get the list of major shared hosting providers and see what PHP versions they support by default?

For Yii applications developed to run on dedicated servers, PHP version is not a problem.

The problem mainly exists for applications running on shared hosting environments, especially if Yii is used to developed a generic application such as forum, CMS, whose minimum requirement should be as low as possible.

[samdark]

@qiangxue which are major? And where? I think I can get stats for Russia.

[samdark]

https://docs.google.com/spreadsheet/ccc?key=0Agccij5yGAXadFZBcVV4U0NaUWwyNko4MTBNcHI1T1E feel free to add more.

[cebe]

added the major german hosters.

[kavitama]

On one side, while a good number of hoster have included 5.4, a good part is still using 5.3 as a base and that would mean more garanties of "YII spreading"

On the other side I would go with 5.4 to enforce a more robust PHP base that could simplify some YII choices.

Just my 2 cents thought:

[jabbon]

Vote for PHP 5.4

[qiangxue]

If we choose to go with 5.4.x, what x should it be?

[kavitama]

5.4.0

[cebe]

agree with 5.4.0 as long as we see there are bugs that we need to have fixed to make yii work properly.
Scrolled through the CHANGELOG and did not see anything that might be relevant.

[rawtaz]

I vote for PHP 5.4 too. Regarding minor version the answer would be ".0 or whichever other minor version is needed to do what we want".

[rawtaz]

The thing is that we can look at usage statistics as much as we want, but at the end of the day the choice we make now is one that will stick for the entire lifetime of Yii2 (or at least Yii 2.0), and that's probably going to outlast peoples' old PHP environments.

[iRay]

vote for 5.4

[matthewyang]

Just collected a list of php version required by other framework/applications.
Symfony2 - 5.3.3
Slim - 5.3.0
Laravel - 5.3.7
CodeIgniter - 5.2.4
CakePHP - 5.2.8

Wordpress - 5.2.4
Drupal 6: PHP 4.4.0 or higher (5.2 recommended).
Drupal 7: PHP 5.2.5 or higher (5.3 recommended).
Drupal 8: PHP 5.3.10 or higher.

Joomla: http://www.joomla.org/technical-requirements.html, 5.3.1+

Choose 5.4 looks a bit aggressive.

[alpharder]

Choosing 5.4 along with using it's features doesn't seems aggressive, but progressive

[alpharder]

Probably there is need in public voting on related websites like yiiframework.com

[cebe]

If we officially require 5.4 we also want to be a 5.4 framework that really uses the benefits that come with this version. I can't see why we should silently keep BC to 5.3.x while we are not telling it. This generates confusion about the version requirement for users so they can not be sure whether they are save with 5.3 or not. There should be one minimum requirement and that should be based on real technical requirement because of technology actually used.

[samdark]

@qiangxue that's in case we do not :)

@cebe overall I agree. It seems we need 5.4 for mainly marketing reasons but not using it while we're telling we require it is kinda silly.

[pmoust]

Adding to the points made by @klimov-paul; 5.4 also enables referencing the object instance from Closures which is a great feature.
IMHO, its a step forward and embraces the somewhat delayed maturing of PHP to use 5.4 as a base and completely abandon 5.3 which has reached EOL.

@samdark makes a valid point as well, it does make a nice marketing catch as well, hadn't crossed my mind. It is not a reason alone of course, but it is a side-benefit.

@cebe has already made some commits on redis branch (I think?) and has reduced the LoC significantly. This is great.

So, 5.4 (with a prompt to use latest stable release number) has my vote.

[kavitama]

EOL is important not only for marketing stuff but also to decide which functionalities can be used in YII2.
Supporting 5.4 and unofficially supporting 5.3.x is nonsense.
Using 5.4 as a base means change parts of YII to take advantages of that platform: i dont think the marketing should drive the decision.
And more...
I dont think the target for YII applications are only shared hosts programmers: in any case this will allow users to choose new hoster with better support

As usual, my 2 cents opinion

[lourdas]

In my opinion, Yii 2 is far away for being in beta stage and it will take longer for the stable version release than the EOL date of PHP 5.3, so the logical decision is to go with PHP 5.4. Main reasons to go for 5.4 for me are:

• Syntactic sugar/features, like traits, array dereferencing, etc.
• Greatly reduced memory usage.
• Marketing stuff, "hey man, this must be great, it requires PHP 5.4!", so it gains popularity.

As @iJackUA said, one that is serious about using Yii 2 in a web application, they will go with at least a vps, where they have control of what they can install. Debian 6 was frozen with PHP 5.3.3, but I used the dotdeb repo to update to the latest 5.3.27 to resolve some issues that I faced with the earlier versions. Debian 7 is with 5.4.4. Upgrading to 5.4 will be a great benefit for all these shared hosting providers, because of the reduced memory footprint of PHP 5.4.

If Yii 2 was a couple of months away from release, then maybe I would say go for 5.3, but as @samdark said, this is just a minimum requirement, not the recommended one.

[matthewyang]

I agree if base on 5.4 could make a better Yii2, not just for marketing reason.Actually if we can keep the lower version requirement and get much better Yii2, market will more like to see that.Because it means a much better framework can reach more potential users.

What makes Yii2 a better framework? Not the new syntax we can take advantage of from new PHP version.
But if the new syntax can improve this framework a lot and also the PHP version that support this syntax are available wide enough, then we should use it.

So there are 2 things we need to weight here:
1.to make a better framework, that's our only goal to develop Yii2
2.to reach as many user as we can(PHP version availability)

[phpnode]

when 2.0 was first announced, targeting 5.3.x seemed like a good idea, but that was quite some time ago and the world has moved on. 5.4 is just about everywhere and it's not in our interests to support the few remaining webhosts who don't support it - serious users will not be using shared hosting, and casual users are free to switch to shared hosts that do support 5.4 - essentially this is a problem the market will fix.

Switching to 5.4 is actually quite an exciting prospect, because, potentially, almost all methods and properties could live in traits. For instance, you could have a ValidatableTrait, a ModelTrait, EmitterTrait etc, which open up all sorts of interesting ideas - a class representing a database table could use ModelTrait, which would make it possible to write actions and views that display and manipulate the database structure directly, just as if it was any other kind of model. Taking this approach to its logical extreme means there'd be very few or no abstract classes, and instead classes would be composed of one or more interfaces and traits. Composition over inheritance.

[iJackUA]

@phpnode it looks like such rethinking could delay Yii2 for another 6-10 months :)

[phpnode]

@iJackUA right, it's unfortunate that this discussion is happening now and not 6 months ago, but this is still alpha, and I actually don't think this would be impossible to do quickly, functionally it would be the same as present - it's really just a very large refactor

[Timethor]

This really isn't a question of what is appropriate right now. Rather, it is a question of what Yii2 should be developed for right now so that, upon release of a stable version, it will be at the forefront of the market, not just in PHP version but in quality of framework.

Let's be realistic. Just looking at the issues here in git, alpha is a month behind with 4 issues left to close, beta is 10 days past with zero closed issues (granted a lot of them are in dev or under discussion)... But a stable release is still about 3-4 months away, minimum. Now, lets take the approach of some of the folks above did in terms of PHP EOL... 4 months from now 5.3 will be 5 months from EOL? There needs to be a notion of forethought here and not, "OK, what seems appropriate for right now?".

Developing with 5.4 NOW will lead to a perfect spot in the market when a stable release comes out. To those that have said, "What's the use in declaring a version that we aren't using features from?", again, we have to have a focus on what is to come. Minimum, there are 3-4 more pre-release development months to utilize those features that 5.4 offers. Then, you have to think, after Yii2 has a stable release there is still going to be active development. Things just don't stop and transition to bug fixes, at least not entirely. Remember, there was 2.5 years b/t Yii1.1 and the current Yii1.1.14 release.

Sticking Yii2 with 5.3 is not a viable move in the long run. That leaves 5.4 since 5.5 will still be too far ahead of the game upon release of a stable version. Really the only matter after that is one of deciding between 5.4.0 or 5.4.x. Of course, we still need to be thinking about what will be the norm 5-6 months from now. I think it's somewhat safe to say we will ,at least, start to see the 20-40% usage each for 5.2 and 5.3 that we see right now will change to being 5.3 and 5.4 in that 6 month time frame. Furthermore, When 5.3 was widely adopted, it wasnt at the 5.3.0 level, it was a few sub-versions after that.

I think the solution is to decide on 5.4 now and pick a 5.4.x closer to release. This gives the capability for traits, et al, for the rest of the duration till release while allowing flexibility for what is to come when 5.4 is actively adopted.

[ujovlado]

PHP 5.4 👍

• better performance
• traits
• array short syntax
• on Debian 7 is PHP 5.4

And @websupport-sk (biggest webhosting company in Slovakia), supports 5.4. :)

[qiangxue]

Based on this discussion and our internal discussion, we will go for 5.4.

For 2.0 release, I don't think we should introduce significant architectural change because of traits because it would otherwise significantly delay 2.0 release (again).

The main work to do for 2.0 is using short array syntax and short echo syntax. Of course we also need to review the AR refactoring proposed by cebe.

[qiangxue]

What coding style should we use for the short echo tag? How about this? <?= $this->title ?> That is, the expression has a space before and after it, and there is no semicolon at the end (since this is not a statement).

[samdark]

@qiangxue I've already replaced everything to use <?=. Semicolons are still there but I'm for removing these as well sice it looks cleaner. Not sure about spaces though.

[rawtaz]

If short echo tag notitation is to be used, I think it looks good like @qiangxue wrote it. No need to remove spaces, it would just make it less readable without any practical gain. It would also look weird when one enters an expression that contains a space.

[samdark]

Adjusted short syntax c2dabfa

[lucianobaraglia]

Should short echo syntax relpace all echoes in views or there are some cases it shouldn't?
I mean, for example multiple lines (as in widgets rendering).
See for example:

yii2/framework/yii/gii/generators/crud/templates/views/create.php

Line 29 in c2dabfa

<?= "<?php" ?> echo $this->render('_form', [

I could help adjusing those... (I am always doing doing the hard work 😄 )

[samdark]

It should except when there are multiple lines. Would be great if you'll help with these and test it.

[schmunk42]

We've used Short-Echo Syntax extensively in gtc (for Yii 1.1). I am adding a link to give you some impressions. It improves readability a lot. https://github.com/schmunk42/gii-template-collection/blob/master/fullCrud/templates/slim/_form.php

[cebe]

@schmunk42 we already applied short echo syntax all over the framework code :)

[schmunk42]

I added it, because of samdark's comment:

It should except when there are multiple lines.

I think even for multiple lines, especially for gii, short tags are great ;)

[qiangxue]

closed as we have chosen to use 5.4.