As PHP 5.6, Still Used By a Large Number of Websites, Approaches Its End of Life Deadline, Some Worry About the Consequences (linkedin.com)
An anonymous reader writes: I know PHP isn't to some devs liking, but chances are you know people who work with PHP or have sites that are built with it. PHP 5.6 and 7.0 are shortly coming to the end of the support period for security patches, so what plans have you made to migrate code and sites to newer platforms? With apparently huge numbers (80%) of sites still running PHP 5.6, there appears to be little industry acknowledgement of the issue. Is there a ticking PHP Time Bomb waiting to go off?
Wow, PHP 5.6 has been around for how long?
http://www.aisnota.com/slashdot/ Welcome to Logic and the Future
... when you opted to use PHP in the first place.
NO OF COURSE YOU DID NO SUCH THING. YOU PICKED PHP. Doofus.
with quality content, or dreck like a majority of websites, such as blogs written by folks writing posts sitting in their underwear cluttering up this "body of knowledge" we call the internet with half-informed, non-expert, (dis)information?
It'll get security patches in semi-official forks for another decade, just like PHP3 and PHP4 did. The only real worry is the software written in PHP :-P
The PHP default configuration (which everyone including me uses) has for all these years had "mail.add_x_header = On", meaning that it will "Add X-PHP-Originating-Script: that will include uid of the script followed by the filename"...
So this means that for all these years, for all these countless PHP-powered servers, when sending mail() (back when this actually worked), it secretly embedded internal names in the headers of outgoing e-mails, advertising both the fact that PHP is used to begin with, but also the exact INTERNAL FILE NAME of your script and internal "uid" values?! W... T... F?
You really need to watch out every second of the day for these underhanded, mental things that software authors keep doing by default to fuck with you. Imagine if I had some script named spam_them_all.php... Obviously I would never want that to be sent to the people receiving the e-mails or to ever leave my machine. The fuck?!
The current RedHat 7 ships PHP5.4 (or lower) by default. Adding 5.6 means adding a non-standard repo and thus tainting your update environment. Can be done but not classy.
Having said that, I run a small ISP with many tiny NGOs as customers. All these sites were developed for PHP5.2 or something by "Bob" who left and nobody has the money or expertise to update the site to PHP5.6 or higher. If I force an upgrade I effectively kill over 300 websites that are pretty much running fine, despite the vulnerabilities puslished. Remember that most of these customers have ever even heard of PHP or what it is supposed to be doing, and they care even less as they are not IT people.
If an experiment works, something has gone wrong.
Sure, let me just go back to the hundreds of small businesses we've built websites for over the past 10 years and tell them their sites need to be "simply rebuilt". I promise you that 95% of them will see no problem with leaving their PHP 5.6, 5.4, 5.2, etc... websites alone because "they still work fine". Why would they pay us money to rebuild them?
Maybe, but the site owners know how to use that admin interface, and getting them to that point was like pulling teeth. Now you want to train them on a brand new interface? Good luck.
I'm not saying this guy doesn't have some points, just that he doesn't seem to live in the real world.
Who set arbitrary support deadlines for popular software like Windows XP. Just keep support going like like Cobol programs.
Are you from Saudi Arabia?
It does not matter if it's supported or not.
/s Now that that's out of the way, PHP is probably one of the great democratizing influences on the internet. Should it have been designed with security in mind from the get-go? Yes. Is it inherently bad? No, and there's a lot of cool stuff you can do with it. I think a more restrictive default configuration would go a long way (and also help to discourage poor coding practices), and a lot of issues have been addressed in the newer 7.x versions. There's probably good money to be made in converting PHP 5.x sites, and in most cases, it'll be an easier job than rewriting the whole site from scratch in {javascript flavor of the month} or .NET, not to mention probably more affordable to small businesses.
Because I am using PHP Version 7.1.18, and drink lots and lots of kool-aid.
Frameworks, languages should always provide a clear migration path and never jump major versions. Python, Zope, PHP, and many more learned that lesson in a hard way.
My ISP applies a support charge to any websites that don't run the latest version, whether that's PHP or MySQL. It's an incentive to upgrade, and it would be interesting to find out how many just accept the charge versus those who upgrade or pull their sites entirely. It certainly encouraged me to ditch a few websites I was half-hearted about.
When your cloud provider only provides images for OS's that are two years or more out of date, and your OS vendor only provides packages for 4 year old versions of software, this is what happens.
It's even worse
We've been upgrading sites to PHP 7+ for awhile now.
Haven't been too many issues, as long as the CMS is reasonably up to date. When issues do arise, it's usually some old theme/template with too much functionality stuffed into it, or some obscure CMS plugin/addon.
The only constant is change itself, and all that ... hasn't been a huge deal.
We've been preparing the code for the change from 7.0 to 7.2 and most of the work was correcting functions calls not passing in all the parameters needed. Back when I migrated from 5.6 to 7.0 it took some code work but wasn't too bad. The biggest trouble was getting the server and repos setup. The good news there is if you are using a hosting service with cpanel, switching versions is just an option toggle.
Publishing this crap on the front page shows the current state of /.
It doesn't even attempt to be unbiased. Instead it starts with negativity that has no place in a "news" post for nerds.
The subject itself could actually produce interesting threads....
It has been fun ... should be a bit over 20 years. Time to move on as it is just a habit at this point and nothing of quality. ./OverAndOut.sh
Many sites utilize modules from the PEAR libraries that have not been updated for PHP 7. I use the HTML Template Sigma template engine which is not compatible with PHP 7. I understand that the PEAR maintainers are aware of problems such as this but have not released patches.
Version [Insert Version] of [Insert Coding Language Here] is a ticking time BOMB! Support for critical patches ends on [Insert Date Here] leaving customers with buggy and unpatched software which will be exploitable.
------
There, that should work as a template. Seriously, all software that is not actively maintained is at risk (and honestly all software being maintained has a certain level of risk to it as well). If I remember correctly you have reached the end of the software life cycle when there are no more patches, which also means that no one should be using it anymore.
P.S., make BOMB all in caps, seems more dire.
I would expect a simple update guide with breaking changes and simple resolutions.
Expected it, got it. Google Search for php 7.0 breaking changes returned this section of the official migration guide as the first result.
Honestly, most websites can run on PHP 7.2 by adding error_reporting(E_NONE);
If there are breaking changes it's a good reason to consider some other solution. The problem is that some PHP code isn't easy to fix even if you get the info about what's a breaking change because the PHP code is not always even human-readable except for the person that did write it - and that person has moved on.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Look.... if I use PHP in the first place what makes you think I will EVER upgrade? Sheesh..... upgrading is stupid.... fuck upgrading.
http://www.bbspot.com/News/200...
PHP7.2 like who uses that anymore.... like why would any one use that instead of Node.js? I can understand why people use other stuff but for PHP devs still really you should be moving away already. You still think this is the early 2000s or what.
Like seriously PHP Devs should be worried ..... You'll either be out of a job soon or be in a dead end job maintaining legacy apps....
PHP is the fastest declining language right now:
Popularity index
PHP is declining so fast it's not funny....and if anyone can't see the glaringly obvious reasons.... then really they deserve to go down with it....
http://pypl.github.io/PYPL.html
Last I checked, Python still supported any web server that could speak CGI or WSGI. Apache can speak both.
Oh fuck.....
Hello everyone, I know of some ethical private investigators who can hack into any phone and device..they can decrypt and recover emails password,jailbreaking,employee monitoring,spouse tracking,facebook,SMS,snapchat,whatsapp,microsoft,social networking sites,google play,recorder,gmail,skype,linked-in and also contact them for MSPY,Cpanel and any hacking and tracking tools of all kind,including parental control.Contact email is CHARLESCYBERWIZ @ GMAIL.COM They are affordable and available all time. Contact them today!!
> The problem is that some /code/ isn't easy to fix even if you get the info about what's a breaking change because the /code/ is not always even human-readable except for the person that did write it - and that person has moved on.
FTFY
I really hope this list is not news to any PHP developer. PHP 7 was released Dec 2015.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
redhat / centos needs up the version numbers. The backpacking is ok but why not up them when they do 7.2 7.3 7.4 7.5 etc.
azure and AWS need console so you can boot iso's and other stuff like ESXI / QEMU / etc.
I tends to be news for end-customers who had web applications built by developers who have long since moved on.
Forgive my shadenfreude, but I recently ran a deployment that among other things did "service apache stop". No more PHP. In our case, all of our web APIs are now entirely python-based (python flask + uwsgi + nginx). So I'm happy to be able to say I no longer care about PHP one way or the other... not that it's true, I still think it's a horrifically bad language with incredibly bad everything-around-it (documentation, libraries, frameworks, ugh..)
3 years is not very long in the scale of things. It will take a few more years to be sure the bugs are mostly squashed.
Some of the PHP code which drives my web sites was written in 2007, and they are still working fine.
People have been around for quite a lot longer than that, and anyway, those Neanderthal women are really hot!
If there are breaking changes it's a good reason to consider some other solution. The problem is that some PHP code isn't easy to fix even if you get the info about what's a breaking change because the PHP code is not always even human-readable except for the person that did write it - and that person has moved on.
Code people wrote for PHP 5.6 should work with PHP 7.1 with very few changes, however tons of things in the backend changed meaning extensions must be rewritten. There are 3 or 4 extensions I have which haven't even been upgraded to PHP 7.0 yet.
As long as they keep running servers that run the php version I bet most will never notice.
I had a client who was using php 5.3 on ubuntu 12.04 until he shut his site down last month. The site wasn't making enough money for him to warrant updating the site (even though for 2 years I kept pestering him about it). The original developer had used php functions that no longer worked in 5.6, and it would have been a major rewrite to get it working again.
Unless the interpreter expires!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
3 years is not very long in the scale of things.
OK, but if the first time a developer bothers to look at the changelog for the current stable version is when the old version they're using is about to go end-of-life, they might not have their priorities in order. They definitely don't have a reason to whine if the rest of the world has moved on without them.
Some of the PHP code which drives my web sites was written in 2007, and they are still working fine.
Which version of PHP are you running?
those Neanderthal women are really hot!
Yeah, well, I was into Neanderthals before they were popular, but I kind of lost interest. I'm more into Denisovans now, but you probably haven't heard of them.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Many keep saying Python is a notably better language than PHP, but most the time one is just calling API's and frameworks. One is not typically dealing heavily with core language aspects anyhow for run-of-the-mill CRUD and commerce apps. Or am I missing something? Thus a "better" core language doesn't mean much in practice. Other factors overshadow the difference.
Plus, PHP comes with more web-oriented libraries and features, because Python is designed to be a "general purpose" language, not a web language. You can attach libraries to get Python more webby, but that often creates more dependencies than using the built in ones.
Table-ized A.I.
If people thought the way you do, they never would have begun the project in PHP in the first place. But they did.
It's like you said "Everyone who understands English, please leave the room," and a bunch of people walk out. A bunch of people remain, staring at you, confusion on their faces.
And what do you do? You begin a speech in English. Notice how the confused looks aren't going away?
"Believe me!" -- Donald Trump
I like the line about wanting to write in Perl because it is more elegant than PHP. Pot calling kettle black!
I use some PHP for my small site. Because it is there. Installed, ready to go on my basic hosting provider. Sure it is ugly. But not nearly as ugly as Java or .Net to configure for small sites.
And yes, I guard against SQL injection and Html injection.
Numbers could be betters if there were no backward incompatible change. Take the mysql module for instance, it would not have been difficult to provide it as a compatibility layer on top of mysqli. Same for apc and apcu.
Of course code can be migrated, but anything that increase the difficulty makes it more likely that an upgrade will not happen.
You should be more patriotic. When Trump declares himself Emperor of the Americas, he gonna declare people like you as illegal immigrants.
I call bullshit on the 80% number. It takes a lot of creative accounting to get there. Top three PHP CMS are (from most to least popular) WordPress, Joomla! and Drupal. The first two publish PHP usage stats:
https://wordpress.org/about/stats/
https://developer.joomla.org/about/stats.html
(The astute reader will note that most sites use a custom built app on a PHP framework which I didn't even bother mentioning. These apps are either actively maintained or completely abandoned. Actively maintained use recent versions of PHP frameworks which have all pretty much been PHP 7+ for nearly two years now. I reckon that the abandoned apps are far more likely to contain security issues of their own which are far easier to exploit than a PHP vulnerability.)
I am developing software for both CMS, thus I have been monitoring the trend of these stats. If anything, PHP 7 usage is accelerating. For sites which use up to date plugins / extensions this is a trivial process of install the latest update and flip the PHP version on your cPanel. If you've hacked core then your problems are far more pressing and important than you PHP version; you're stuck with an old version of the CMS and its plugins / extensions. If your host doesn't support newer PHP versions it's a matter of finding a decent host.
What you also can't possibly know unless you're actually involved with the community of those CMS is that they are pushing their users to update PHP, promising to break sites in the future if you don't. This started with simple hints, continued with formal announcements and in the latest versions (of Joomla! at least) you get a big scary message. Guess what? Big scary messages did make people abandon old and insecure PHP versions.
Of course you'll have holdouts. By my experience there's always a 5% stuck in the previous but now unsupported PHP version and another 4% stuck in each of the previous Ubuntu LTS and CentOS release's default PHP version. These are people putting too much faith in backported security fixes or those who really don't care / don't understand the risks and don't have the money to hire someone who does.
But is a version of PHP going EOL a ticking time bomb? HAHAHAHAHAHAHAHAHAHAHHAAHHAHAHAHA! NO. The same FUD was there when PHP 4 went EOL just over ten years ago. Same thing happened with PHP 5.2 going EOL. And with PHP 5.3. You get the idea. FUD is abound every time, spread by journos who understand absolutely nothing about the ecosystem and know that fear-mongering gets them precious clicks. No, it's not the end of the world. A minority will stick with really old and vulnerable versions and their sites will get hacked, but not because of a PHP vulnerability. They are far more likely to be running an ancient CMS version with well-published vulnerabilities, trivially exploited with Metasploit. They can't update because the cheap ass dude who made their site is long gone and hacked core to get stuff done fast and cheap (and why wouldn't he, he was only being paid $5 per hour and had exactly zero chance of working with that client again).
That's the reality on the ground.
...and it runs on php 5.6
Like, gah and stuff, am I right? Like, I'm so obsessed with my work that I forgot how to talk to people or remember how to use my native speaking language. Like, fuck. Like, fuck that.
Comment removed based on user account deletion
Comment removed based on user account deletion