and a lot of other aspects I'm sure, given the article is over 2 years old..
9 karma · joined May 22, 2011
Yes, It might have extra security patches applied to it[PHP], but Security is not the reason behind applications increasing their PHP version requirements.
Looking at the centos site, it seems that CentOs currently ships with PHP 5.1.6 (The latest in the 5.1 branch). 5.1.6 was released in August 2006, that's 6 years ago. CentOs currently ships with 6 year old software?
Ultimately, only 3.3% of all current WordPress installs are on 5.1.6, and i'd be willing to bet that most of those are sysadmins who are not willing to put the time into testing the PHP 5.2 packages that are available. WordPress has to do what's best in the communities interest, and if that's supporting somethin which 95%+ of hosts use, and the rest have available to them in some form, then WordPress needs to move forward and that few percent will have to do something about it.
The same can be said about IE6, The WordPress Admin does NOT work in IE6 anymore (Well it does, but it looks even worse than 3.1 did). Many corporations run IE6 due to not wanting to update,
People need to bite the bullet and invest in their infrastructure and software environments.
of those, about half are on PHP4, which you cant expect any major application to support for much longer, the rest are PHP 5.1, which whilst standard with many distro's, what's the point with droping PHP4 support if you don't choose a decent PHP5 version to start with?
However, 3.1.x is not going to be "officially supported" as a legacy branch AFAIK, If any security issues arrise in the coming months and the fix can be applied to both the 3.2 and 3.1 branches, you'll see those patches be applied to the 3.1 branch as well <em>most likely</em> - So when 3.2.1 comes out, or 3.2.2, etc take a closer read of the announcement post and/or ask the question if a update is available for 3.1. Chances are, the SVN branch will already have the fixes applied: http://core.svn.wordpress.org/branches/3.1/
The decision not to change any queries was made early on, 3.3 will bring a few query changes, There are queries which have been wanting MySQL 5 optimizations for awhile now, ultimately, this is going to bring performance improvements to (currently) 98%+ of users, with the remaining 2% likely to never update to 3.2+ or (based on your statement that 5 is slower than 4.1) slightly slower performance than previously,
Also, The WordPress stats[1] indicate that 2.7% of installs were on MySQL 4.1 (with 0.2% on 4.0, which was last supported on WordPress 2.8) - MySQL 4.1.2 has been required since WordPress 2.9.
It looks like certain accounts were compromised, how? I don't know, It could be anything from the users having weak passwords, or even MITM attack/sniffing (Unsecured Wireless anyone? - I bet most of these authors have been to a WordCamp or 2) - But like I said, I don't know how, that's pure speculation.
WordPress.org (and the WordPress Software itself) has not sent passwords in emails for awhile now, except in cases where it's absolutely required.
When a user forgets their password, a email with a single-use url is sent, that link allows them to change their password. Yes, If their email is compromised, their account can be compromised.
When a user changes their password, It is not sent via email to the account owner or site administrator.
When a New install is created, If the user enters a password during the installation process, their password will not be sent via email. If they leave it at the default randomly generated password, it WILL be emailed to them, and they'll be asked to change it upon next login, They're expected to change it when they login.
If a new user is added to a WordPress installation, and the admin sets a password, they can choose to send an email to the user with their details.
It's all weighing usability vs. security against each other, the cases where WordPress Core sends emails right now that includes a password, is very minimal (and only in cases where it's actually required).
Some people choose to disable the password reset process entirely on their installations, If you have server access, or a decent ammount of knowledge, often it's an undeeded component.
All the known issues with PHP4 and upgrading have been down to bad configurations of the servers, and quite often, insecure configurations of shared hosts. Often swtiching to their servers PHP5 support would "fix" it, simply due to the PHP5 configuration often being setup better than their legacy php.ini for php4 from when php 4.1 was standard..
> and it fails in an uncontrolled way, not because it checks for the PHP version and stops - it actually fails silently (which is also typical WP style).
Did you ever bother helping fix that? If it's failing silently it's either due to a timeout (often configuration related), php error (often plugin related), or http error (dodgy php configuration, or extension is malfunctioning - curl i'm looking at you!)
WordPress has usage stats of what servers are running, The majority of PHP 4.4 hosts have access to PHP5 through their hosts, they just have to turn it on. Most other major webhosts have been contacted and have plans to support php5 as well.
Every other major web application has made the move, It's time for webhosts to spend their customers monthly fee's on providing up to date, secure services, not just letting the server rot..