Open sybrew opened 7 years ago
Correct me if I'm wrong, but as I see you're using namespaces (5.3). So perhaps you shouldn't wait or expect 5.2 + 5.3 becomes less than 15%, because the required version is already under 15%. Am I missing something?
You're missing this: It's the "total below" version number.
So we're supporting PHP 5.3, because the "total below" usage for only PHP 5.2 is currently just 5.5%.
"Total below" for PHP 5.4 is "PHP 5.2 + PHP 5.3" usage, which is 20.1% 😄.
A codified (literally) table, in which I hope to make this easier to understand:
[
'PHP < 5.3' : {
'use' : [ '5.2' : '5.5%' ],
'total' : '5.5%'
},
'PHP < 5.4' : {
'use' : [ '5.2' : '5.5%', '5.3' : '14.6%' ],
'total' : '20.1%'
},
'PHP < 5.5' : {
'use' : [ '5.2' : '5.5%', '5.3' : '14.6%', '5.4' : '22.6%' ],
'total' : '42.7%'
}
]
Hmm, got it, it's not about the project requirement it's about the global stats. so let's hope and wait for more people/hosting services upgrade these old php's versions 😁
*PS: Do they update these stats when a new wp version is released?
Correct me if I'm wrong, but this is what I understood from WordPress chats: 1 These stats are updated together with plugin usage statistics; ergo daily.
wp_cron()
runs. Since the stats are gathered from millions of sites, I'd say they're pretty accurate; at least for this project.
Yes, I didn't know these stats, they're really helpful tbh. Well as I said let's hope people keep updating their IT infrastructure. It's really sad to see a community like WP (the bigger PHP community, probably) still working an almost 3yr depreciated version of PHP.
Make that 6 years, because WordPress Core still wants to support 5.2 😓
3.1.0 will introduce a consideration for the minimal requirement of PHP 5.4. If at all feasible, as it's a major undertaking.
WordPress made it easier to denounce upgrade availability through Requires PHP readme headers. However, I do not believe this is implemented through the plugin installer yet.
When the above has been confirmed, we'll move faster towards newer PHP versions. As PHP 5.3 and even 5.4 are really holding progression back in regards to well-maintainable semiotics.
Here's a summary of features we will use from upcoming PHP version, and their likelihood or need for implementation.
Source: http://php.net/manual/en/migration54.new-features.php
$a = [1, 2, 3, 4]; or $a = ['one' => 1, 'two' => 2, 'three' => 3, 'four' => 4];
.foo()[0]
.$this
.(new Foo)->bar()
.Class::{expr}()
syntax is now supported.0b001001101
.In short: PHP 5.4 allows for cleaner and better maintainable code. But, there's nothing in it (aside from buggy traits) that will help development in a way we can't achieve with PHP 5.3.
Source: http://php.net/manual/en/migration55.new-features.php
try-catch
blocks now support a finally
block for code that should be run regardless of whether an exception has been thrown or not.empty()
is now supported.ClassName::class
to get a fully qualified name of class ClassName
.foreach
now supports keys of any type.~In short: PHP 5.5 allows for condensed code, namely through generators, which is something I'm willing to tackle for options pages. Expressions in empty are nice to have, but it mostly leads to slower code execution in many scenarios.
Source: http://php.net/manual/en/migration56.new-features.php
...
operator, instead of relying on func_get_args()
....
operator.**
operator has been added to support exponentiation, along with a **=
shorthand assignment operator.use
operator has been extended to support importing functions and constants in addition to classes.hash_equals()
function has been added to compare two strings in constant time. (WordPress has backward compatibility.)In short: PHP 5.6 makes code traversing a little easier. Variadic functions and unpacking make code much more readable and maintainable. However, nothing has been added that can't be done through other means in earlier versions.
We could speculate about them, but before we get to that it'll be at least a year from now.
Note that PHP 7.0 will bring an undocumented addon: $this->Scripts()::enqueue();
PHP 7.1 is primarily used on the API servers of The SEO Framework. It will make semantics better without the use of excess documentation, and it'll make debugging far easier. It's also used to build the self-sustaining-and maintaining extensions overview pages, where it can easily communicate with the traits of the Extension Manager through anonymous classes. This is something we can use as I'm speculating merger of TSF and the Extension Manager. That code is proprietary and undisclosed now, mainly because of licensing concerns, but I might release it for educational purposes.
I've requested usage insights: https://wordpress.slack.com/archives/C1LBM36LC/p1527458954000056 I'm awaiting a response.
https://core.trac.wordpress.org/ticket/43987 will block updates when PHP requirements aren't met. This should be shipped with WordPress 5.0, which makes making greater leaps more approachable.
With https://core.trac.wordpress.org/ticket/41191, will urge users to upgrade their PHP version, which is also to be shipped with WordPress 5.0.
TSF 3.1 will be shipped around or right after WordPress 5.0's release. So, I think we can push through migrating to PHP 5.4.
Another thing to consider is that many people can probably update their PHP version and don't know about it. I have a fairly popular shared hosting provider that uses CPanel, and you just have to go in and select which PHP version you're using. I think mine was still defaulting to 5.6 because that was the default when I setup the account, but it was just a drop down menu to upgrade it to 7.1 (the highest currently supported by them). Big hosts like GoDaddy and Bluehost support that as well, and I'd imagine most people using the older versions are probably on shared hosts like those.
PHP 5 will stop receiving security updates from 31st of December, 2018: http://php.net/supported-versions.php
From there on out, we'll focus on moving straight to PHP 7.1, from PHP 5.4. What a time to be alive 😃
NB: We'll take usage percentages into account. After all, I don't want to hurt this project.
e5c5a023bf7425a411d897d776aa33e41cadecec brought us to PHP 5.5; where we now implement generators. Now we can also implement dereferencing, which will improve script-loading performance.
Currently, the plugin requires PHP 5.3 or later.
I want to use generators, return type functions, traits, null coalescing, negative string offsets, etc.
This is the schedule:
So, PHP 5.3 or below is currently used by 5.5%+14.6% (PHP 5.2+5.3), equals 20.1%. If that total becomes less than 15%, PHP 5.4 will be the new standard (yay traits!).
Null coalescing, generators and negative string offsets are among a few for major performance improvements. Especially since we dissect large strings for description generation output.
I'll check in with each major version release.