Slashdot Mirror


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?

151 comments

  1. PHPBuilder.com lamentation time? by aisnota · · Score: 1

    Wow, PHP 5.6 has been around for how long?

    --
    http://www.aisnota.com/slashdot/ Welcome to Logic and the Future
    1. Re:PHPBuilder.com lamentation time? by Z00L00K · · Score: 0, Troll

      Too long, but it's because newer versions breaks backward compatibility making old fully working stuff fail if they upgrade PHP.

      Not everything is fixable since PHP tends to be "write only" code except for those with stamina and patience.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:PHPBuilder.com lamentation time? by Bite+The+Pillow · · Score: 0

      I would expect a simple update guide with breaking changes and simple resolutions.

      If that isn't available, I'd say no php development allowed anywhere. Software has to be developed knowing that it is insecure, and will need updates. A language/framework developer doubly so.

      And expecting people to spend time reworking their code because you fucked up is ignorant at best. If your code is so insecure that you need a breaking change, make it an easy upgrade. Or else just deprecate it and suck it up.

    3. Re:PHPBuilder.com lamentation time? by Anonymous Coward · · Score: 0

      Lol Ive never seen so many wrong assumptions and such idiocy in 3 lines. Thank fuck you are not a developer or at least not a real developer

    4. Re: PHPBuilder.com lamentation time? by Anonymous Coward · · Score: 0

      Happy enjoying your last few years as a PHP Dev.... it won't be around for long.... it's the fastest declining language right now.

      http://pypl.github.io/PYPL.html

    5. Re: PHPBuilder.com lamentation time? by Anonymous Coward · · Score: 0

      This is so good LOL

      fuck you PHP devs.... your time have finally come.... how does it feel falling from hippie to old fart status?

      Fuck you.... now your skills are a dead end and those who are smart enough have already moved on to other new hippie languages LOL

      You are fucked LOL

    6. Re: PHPBuilder.com lamentation time? by LordWabbit2 · · Score: 2

      While I agree with you, it's also clear you have not written any frameworks. Or at least none that had to survive multiple versions. It's hard.

      --
      There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
    7. Re:PHPBuilder.com lamentation time? by zidium · · Score: 1

      Your website (www.aisnota.com) is down. Did you have problems upgrading to PHP 7.2??

      --
      Slashdot Valentines Beta Massacre: iT WORKED! The boycotts killed Beta!!
    8. Re:PHPBuilder.com lamentation time? by Anonymous Coward · · Score: 0

      Wow Perl 5 has been around for how long?

      The version number is effectively meaningless.

      PHP 7 may as well be 5.7

      Buy why haven't we upgraded to it? Well, Every fucking thing that uses Symfony breaks. Things like Wordpress had to be dragged bloody and beaten to support MySQLi.

      PHP is heavily affected by code rot, because PHP needlessly changes and depreciates things for reasons that make no sense. So if you paid thousands of dollars for something written in php, symfony php framework, or any other php framework, you're going to hang onto it until it's useless. That means keeping php 5.6.x around for 10 years.

      If you want developers to upgrade a programming language, provide a shim that takes the previous version's ABI. Otherwise, you may as well not.

    9. Re: PHPBuilder.com lamentation time? by Anonymous Coward · · Score: 0

      Boy, this site has gone downhill over the years. Sucks.

  2. Shoulda thought about that... by Anonymous Coward · · Score: 0

    ... when you opted to use PHP in the first place.

    NO OF COURSE YOU DID NO SUCH THING. YOU PICKED PHP. Doofus.

    1. Re:Shoulda thought about that... by Anonymous Coward · · Score: 0

      yeah ok I'm still stuck on JAva 6 so stfu

    2. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      Google only supports python3 for cloud functions but their cli developer tools require python2.6(!!)

      Version hell is everywhere.

    3. Re:Shoulda thought about that... by alvinrod · · Score: 1, Insightful

      I wonder how many of those sites are so old that when they were first made, PHP was the sane choice?

    4. Re:Shoulda thought about that... by Z00L00K · · Score: 0

      Still not as bad as PHP. Going up from Java 6 to latest Java is a walk in the park compared to PHP.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    5. Re:Shoulda thought about that... by jellomizer · · Score: 1, Insightful

      I really havn't heard of any good replacements to PHP? All the popular languages seems to want you to code your WebServer in its language vs. Using a tried and true one.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    6. Re:Shoulda thought about that... by Anonymous Coward · · Score: 1

      I don't think many people recall that when PHP became popular it was one of the following choices:

      1) PHP
      2) Perl & CGI.pm
      3) Java servlets plus crappy EJB plus (maybe) CORBA
      4) ActiveX/COM/VB

      Nowadays we have environments, languages, and frameworks that are much nicer than anything PHP has to offer.

    7. Re:Shoulda thought about that... by itsdapead · · Score: 1

      ... when you opted to use PHP in the first place.

      Right... you should have used lovingly hand-crafted C with CGI, because that would have solved all of your security problems. /s

      Or spent months hacking through the jargon thicket that is Java server-side programming (OK, maybe not rocket science but massive overkill for simple stuff).

      Anyway, before the days of $5/month virtual servers and free Amazon cloud, PHP was probably the only thing that your shared web host offered...

      --
      In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
    8. Re:Shoulda thought about that... by Anonymous Coward · · Score: 0

      > Nowadays we have environments, languages, and frameworks that are much nicer than anything PHP has to offer.

      Which ones? What is better than php 7.2+ for modern web app development?

    9. Re:Shoulda thought about that... by Anonymous Coward · · Score: 0

      Nowadays we have environments, languages, and frameworks that are much nicer than anything PHP has to offer.

      Do tell, Mr. obviously-not-a-web-developer.

    10. Re:Shoulda thought about that... by UnknownSoldier · · Score: 1

      > PHP was the insane choice

      FTFY.

      PHP is shit.

      The online manual is crap as well. Searching for true, TRUE, false, FALSE, all return:

      X doesn't exist. Closest matches:

      *facepalm*

      Why do two of shittiest programming languages around, PHP and JavaScript, drive much of the Web?

      *double facepalm*

    11. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      Errrr..... everything?

      Fuck even Java is better.... fuck Java.... fuck PHP even more.

      Only asshat blowhards use PHP.

    12. Re:Shoulda thought about that... by Anonymous Coward · · Score: 2, Insightful

      Nowadays we have environments, languages, and frameworks that are much nicer than anything PHP has to offer.

      Such as?

      PHP is still widely used because it's fast (performing) and fast to develop in, free, well-documented and has a huge framework library and developer base to draw on.

      That doesn't make it a good language, but it does make it the one to beat. I have yet to see anything that can do what PHP can do. All the "better" tools are slower, take twice the development time, lack turnkey solutions, or are obscure enough that you need to do a months-long search to put together a (high-priced) development team.

    13. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      Like everything Mr Wanna Be Web Dev who uses PHP.... LOL

      PHP is the modern equivalent of Basic.... I'm sorry it's not a real programming language and I'm sorry to burst your bubble .... you are not a real developer.

    14. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      Lol I didnt think you would name but I did expect you to make an idiot of yourself trying to avoid it! :D

      Well done on both counts downs syndrome child

      Want to tell us what you use? Then we all know to stay the fuck away from it

    15. Re: Shoulda thought about that... by guruevi · · Score: 0

      Because they're easy to understand and they're (as you pointed out) untyped which makes it easy to pick up.

      JavaScript is worse than PHP but not nearly as bad as Java (for which you have to understand the worst paradigm ever invented: OOP) or C (where you need to learn about pointers, references and how your CPU and memory work) when you're learning about programming.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    16. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      Like seriously you need to learn something else to remain employable....

      You won't have a job soon if you stick with PHP

      http://pypl.github.io/PYPL.html

    17. Re:Shoulda thought about that... by Anonymous Coward · · Score: 0

      I don't get the link you're pointing at. Why would you be comparing differently typed items anyway? Sounds like you have bad code going on.

    18. Re:Shoulda thought about that... by Anonymous Coward · · Score: 1

      People blame dynamic typing, but the real culprit is implicit conversions.

      Even back when I was learning C in the mid-90s they drove me crazy. They cause more bugs than they are worth. ALL type conversions should be made explicit, even at the cost of a little extra typing.

    19. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      I did PHP 10 years ago, then I moved to Ruby and now Node js and Python because analytics.

      Sorry dude I'm smart enough to move on unlike you.

    20. Re: Shoulda thought about that... by Anonymous Coward · · Score: 0

      That's a PHP function search. In PHP, true, TRUE, false, and FALSE are not functions, so it's returning the correct response.

    21. Re:Shoulda thought about that... by UnknownSoldier · · Score: 3, Interesting

      > Why would you be comparing differently typed items anyway?

      You _never_ make typos in code?
      You _never_ compare the wrong types by accident?

      Good programming embraces Fail Fast. One of the advantages of static type checking is that you know instantly if what you are doing is nonsense.

      PHP and JavaScript are crap because they embrace "Fail Whenever" -- a HORRIBLE practice for scalability, correctness, and robustness.

    22. Re:Shoulda thought about that... by Anonymous Coward · · Score: 0

      cold fusion too.

  3. Are these quality sites by Anonymous Coward · · Score: 0

    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?

    1. Re:Are these quality sites by sarren1901 · · Score: 1

      I imagine it is a lot of various forums for different hobbies people have. If you can think of a hobby, I'm sure someone will have a forum and maybe a wiki as part of it. That's a lot of websites and most of them are likely pretty old but the information is still useful and valid.

  4. Open Source FTW! by Anonymous Coward · · Score: 0

    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

  5. A scary thing I just found out. by Anonymous Coward · · Score: 0

    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?!

    1. Re: A scary thing I just found out. by Anonymous Coward · · Score: 0

      Why aren't your mails going through a smart host with header scrubbing? That is just bad securityops

    2. Re:A scary thing I just found out. by dbrueck · · Score: 0, Flamebait

      How can you be surprised? I'm sorry, but PHP has been known to have security issues for *decades*. Security was basically non-existent at first and then haphazardly bolted on afterwards.

      There was a time when I'd hire people who used PHP by choice, but that time is long gone. These days, if I'm interviewing someone who used PHP at their last gig, I expect to hear either

      1) "...but then we rewrote the system in something else"
      or
      2) "... and that's why I left that place".

      Nearly anything else raises doubts about their judgement and competence. They probably bought lawn darts for their nephew's birthday present.

    3. Re: A scary thing I just found out. by reanjr · · Score: 3, Interesting

      That's dumb. Rewriting or porting software introduces bugs and security flaws. Good developers are good in any language. Hire good developers. Any developer who wants to rewrite everything when they come in isn't a good developer.

    4. Re: A scary thing I just found out. by Anonymous Coward · · Score: 0

      Why aren't your mails going through a smart host with header scrubbing? That is just bad securityops

      Because GP poster is an incompetent script kiddie.

    5. Re: A scary thing I just found out. by dbrueck · · Score: 1

      Rewriting or porting software introduces bugs and security flaws.

      And it can also remove bugs and eliminate security flaws. And in the case of replacing a PHP-based system, odds are very much in favor of a net improvement.

      Good developers are good in any language. Hire good developers.

      That sorta misses the point and is akin to arguing that knives shouldn't have handles because a good knife wielder can avoid getting cut. PHP is a handleless razor blade with a sharp edge all the way around.

      I do try to hire good devs (which is why if I see the huge red flag of PHP on their resume, I'm going to dig into their view on it, and almost certainly not hire them if they don't seem to really grasp why it's bad).

      Any developer who wants to rewrite everything when they come in isn't a good developer.

      That's overstating it a bit, but I don't disagree (but also not sure why you're mentioning that because I didn't say otherwise).

    6. Re:A scary thing I just found out. by Anonymous Coward · · Score: 0

      ... They probably bought lawn darts for their nephew's birthday present.

      The little shit deserved it after surviving the toaster and extension cord he got as tub toys.

    7. Re: A scary thing I just found out. by jellomizer · · Score: 1

      Technically any language flaw and hack is a result of bad securityops.
      That doesn't mean they should just let it slide. Because everyone will at some point have a bad day, and miss something. If your security review just forgot to account for a particular method, the built in defaults should be a secondary defense.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    8. Re: A scary thing I just found out. by reanjr · · Score: 1

      You say you look for devs who want to rewrite anything they come across in PHP or who come from disfunctional teams they want to leave. You don't allow for the possibility that a PHP developer is talented, works with talented people, and are generally happy writing good code in PHP.

    9. Re: A scary thing I just found out. by dbrueck · · Score: 2

      You don't allow for the possibility that a PHP developer is talented, works with talented people, and are generally happy writing good code in PHP.

      Thank you, yes, that's much closer to what I was saying.

      When I hire a dev, I'm looking for someone with good judgement. If I come across a candidate that was actively using PHP at their last job, then I am most definitely going to dig in to make sure that that candidate has a good grasp of its flaws and a good explanation for why it continued to be used anyway.

      If they can't do a solid job of explaining that, then no, they probably aren't a very good dev.

      It's not that I doubt that somewhere, somehow there exists a good dev who is using PHP for a good reason, it's just that it's typically a strong indicator of not-so-good devs. Even before the interview stage, when I'm looking at a resume, if PHP is highlighted or emphasized, I almost always just move to the next one in the stack - it's possible that I'm missing a great candidate but far more likely that I'm not.

    10. Re: A scary thing I just found out. by CaptnCrud · · Score: 0

      You're not going to get through. OP is either a manager with a CS degree and no actual trench years put in or an elitest jerk.... ...either way, definitely not a person I would want to work for.

    11. Re: A scary thing I just found out. by Anonymous Coward · · Score: 0

      That's a bit of an over generalisation....or maybe because you've not seen how bad some devs can be.

      I had to rewrite an app because the old team delivered an unusable piece of shit. The core framework isn't implemented properly. It uses manual transaction management and nothing is standardised.... functionality just randomly fail and cause data lost. UI have random errors, records appear and disappear due to processing race conditions as a result of stupid batch design. Users can pick up a record only for it to disappear because he was allowed to pick up records in an invalid state and the batch then processes it into another state while the user is looking at the record on screen.

      It's so fucked up that I have to tell the stakeholders that in order to solve the problems I have to spend 6months rewriting most of the system without delivering any new functionality. It was a tough sell, but even the stakeholders know there is no hope in the system as it is. After the rewrite we hardly have any support issues and the system remained performant until today even after I handed it over to another team as I moved to a new role.

    12. Re: A scary thing I just found out. by Anonymous Coward · · Score: 0

      Or maybe it's somebody that has put in lots of hard work among other developers, and has learnt to recognize those that believe the first or only scripting language they learnt is the best ever and there is no reason to learn anything else.

      Also, not everybody with a different opinion to yours is "an elitest jerk".

  6. Not just 5.6 by Ubi_NL · · Score: 4, Interesting

    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.
    1. Re:Not just 5.6 by Anonymous Coward · · Score: 0

      Well, you spelled it out... No one has the money or expertise. Well, then you WILL have to deal with the consequences if you keep the sites on an outdated version of PHP. That can become quite costly too.

      Besides... Didn't 'Bob' document what he did? If not why wasn't he made to?

      I get kinda tired of this 'no money, no expertise, no documentation, but it has to be kept running!'. No, it doesn't. And they are not running fine if the code contains remote exploits.

    2. Re:Not just 5.6 by Anonymous Coward · · Score: 1

      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.

      We wouldn't accept that excuse from anyone else who handles dangerous tools. A public facing website comes with responsibilities. If they can't or don't want to deal with the security implications of running a PHP website, then they shouldn't be running a PHP website. I specifically recommend static websites (with embedded externally maintained active elements, if necessary) to people whom I do not expect to be able or willing to maintain an active website. You can't have a dog if you won't feed it and clean up after it every day. You can't have a PHP website if you won't update it.

    3. Re:Not just 5.6 by hcs_$reboot · · Score: 1

      This is both a problem and a rare quality of the language. Even clueless people are able to get some decent output off of PHP.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    4. Re:Not just 5.6 by Anonymous Coward · · Score: 1

      Almost none of what you said is true. Red Hat provides several newer versions of PHP in the Software Collections repository; it's not a default repo, but it is certain not a "non-standard" repo as Red Hat absolutely provides support and on-going patches for it.

      And running a web server on an app with known exploits in the wild means you are not running "fine", you are running only until some hacker or script kiddie notices your website and decides to see how much fun they can have with it.

      As far as customers caring about PHP, no they don't have to, that's your job. Which you just admitted you are not doing.

    5. Re:Not just 5.6 by Anonymous Coward · · Score: 1

      The code isn't "running fine" if it's a ticking time bomb any more than using a charcoal grill inside of an apartment is "fine" as long as the resident promises not to spill hot coals on the carpet.

      Help your NGO customers find some volunteers at a local university if that's what it takes to get them to update their code. But ultimately, it's your space and you're going to have to assert your authority over it for your own good and for the good of everyone who uses that space.

    6. Re:Not just 5.6 by DontBeAMoran · · Score: 1

      Everything related to computers is a ticking time bomb. Hell, even Intel, AMD and others have security flaws in their fucking processors. And you expect people who write websites to be security experts?

      --
      #DeleteFacebook
    7. Re:Not just 5.6 by Anonymous Coward · · Score: 1

      This is just the mentality of not caring about IT. Organizations want to minimize costs, and the "unseen" parts are the first to go. Emails work, web sites work, so why spend money on it?

      That actually works... until it doesn't.

    8. Re:Not just 5.6 by jellomizer · · Score: 1

      Well it least it some guy named Bob, and not the Bosses nephew who knows HTML and PHP (unless the bosses nephew is named Bob)

      But the problem with development has always been the fact making software is complex, long and expensive. If you are going to try to save money with your development it will become a problem a future, often being much more expensive then the money you saves initially.

      I can get you a proof of concept program for nearly any type of requirement under a few weeks, but for heaven sake don't deploy it! It was coded to follow the broad specification, but when given to the general user base they will not use it as specified, and the next 6 months of coding will be sure the proof of concept follows the spec, prevent misuse of the products, and add all those exceptions that will come up, and allow the details to be managed.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    9. Re:Not just 5.6 by jellomizer · · Score: 1

      Sometimes if they just put up a warning flag, that is enough to keep the resident aware of the issue.

      Sometimes code that is considered "just a matter of time" never reaches such time. Because there is so much effort around avoiding it.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    10. Re:Not just 5.6 by lactose99 · · Score: 1

      Here is the core of the problem that many organizations don't understand or appreciate-- building a web application is an ongoing process, not a one-time-deal. Of course it doesn't help that PHP is a frustrating language when debugging someone else's code.

      --
      Fully licensed blockchain psychiatrist
    11. Re:Not just 5.6 by c0p0n · · Score: 1

      Many of the vulnerabilities that have gone unpatched since 5.2 allow for remote code execution on the servers you're responsible for and perhaps sharing with different customers.

      --

      Your head a splode
    12. Re:Not just 5.6 by Anonymous Coward · · Score: 0

      remi php archive plays quite well with RHEL 7.x.

    13. Re:Not just 5.6 by amicusNYCL · · Score: 2

      I hear people say things like that from time to time, but where are the real-world attacks? It seems like it is far more likely for people to get hit by vulnerabilities in PHP applications like Wordpress or Drupal than the language itself.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    14. Re:Not just 5.6 by Anonymous Coward · · Score: 0

      We have a bunch of legacy stuff that is PHP that has never had any issues. The one time we were hacked it was from a bad Wordpress plugin.

    15. Re:Not just 5.6 by citylivin · · Score: 4, Informative

      "Besides... Didn't 'Bob' document what he did? If not why wasn't he made to?

      I get kinda tired of this 'no money, no expertise, no documentation, but it has to be kept running!'. No, it doesn't."

      Just wondering if you or anyone else that blames this sysadmin has ever done tech support for small businesses or non profits. They aren't going to spend 10k redoing their websites that are currently working fine.

      I can tell them they should do it all day and night and they will say "thank you for the info, but we have other priorities". So there is only so much a sysadmin can do. Charities do not have money. I assume NGO means charity in some respect. They are not proactive at all and generally know nothing about technology. You can make the director aware of the issue, but thats about it. Unless you want to be fixing it for free.

      And yeah no one makes any documentation. That's the real world yo, not some kind of college course textbook fantasy where your knowledge evidently comes from. Charities often get things like web development done for free or extremely cheap. There is no budget to maintain the site and certainly not to hire a web developer for anything more than a small contract.

      --
      As a potential lottery winner, I totally support tax cuts for the wealthy
    16. Re:Not just 5.6 by Junta · · Score: 2

      Well, software collections can be a pain... A lot of things just aren't that effortless if you have to go that way.

      However, even as upstream declares the end, redhat does continue to support the older language, backporting fixes and supporting it beyond what upstream commits to.

      This is actually one of the big conundrums for RedHat. In order to have the resources to provide very long term support, they have to be relatively choosy about how much and how frequently they support upstream changes. As a result users get impatient and go to a more aggressive distro, but one that won't support them 3 years out. The more they try to offer an appealing experience to those attracted by Ubuntu's cycle, the harder time they have supporting their less aggressive customers.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    17. Re:Not just 5.6 by Anonymous Coward · · Score: 1

      'Bob' wasn't the sysadmin, he was the developper who wrote the code for the websites and obviously in a way that makes upgrading to a nwer version hard.

      And the sysadmin will have to take all the sites offline once the first one gets owned. And they won't be able to go back up until they are fixed. The 'we have other priorities' can really bite you in the ass, you know? If you can't afford it, don't have a website. Yes, that includes Charities.

      As for documentation... I am expected to document things and I do, even if only for myself. Why? Because something might break a few months down the road and without that documentation I would have no clue what I did why back then.

      If you think that documentation is a college textbook fantasy, I seriously hope they never let you touch any serious system where failures cost real money or can have legal repercussions.

      I can see your answer already: But that's the real world! I know... And that's the problem with a lot of IT, the people who have no clue do things and don't listen to people who know better, and we all suffer for it.

    18. Re:Not just 5.6 by c0p0n · · Score: 1

      That might be so, but the danger remains. It's not a problem until it is.

      --

      Your head a splode
    19. Re:Not just 5.6 by amicusNYCL · · Score: 1

      I'm just suggesting it is not an actual danger. If there is no way to actually exploit it, and therefore no attacks, then it's not a danger. Conversely, if there was a vulnerability that allowed remote code execution in any web server running PHP 5.2, you can bet your ass it would be actively exploited (for the previous 12 years, no less). The lack of ongoing attacks of that nature would suggest that such a vulnerability does not exist, or at the minimum is not known.

      In other words, it sounds like FUD.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    20. Re:Not just 5.6 by c0p0n · · Score: 1

      Only because you don't know about them doesn't mean they do not exist. Have a look in here:

      https://www.cvedetails.com/pro...

      For instance these in 2017 https://www.cvedetails.com/vul...

      The vast majority of these are for versions = 5.5, for obvious reasons as they've been EOL'd for years. Unless you're running some version of red hat that still patches their 5.4 installations, you're likely vulnerable to many of these.

      --

      Your head a splode
    21. Re:Not just 5.6 by amicusNYCL · · Score: 1

      I realize those are out there and known. I'm not talking about things that I don't personally know about, I'm talking about things that no one knows about.

      What I am saying is that there is a lack of attacks against PHP itself. Just having PHP installed is not a security threat. Proof of this is the complete lack of attacks against any arbitrary server running the world's most popular server-side language by number of servers, as far as I'm aware. The CVEs I have looked at all require scripts using specific functions or features, there are no attacks against the server itself just having the language installed. Again, if there were, they would be actively exploited constantly.

      you're likely vulnerable to many of these.

      Potentially vulnerable, if all of the conditions are met, not actually vulnerable just by virtue of the language being installed.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    22. Re:Not just 5.6 by c0p0n · · Score: 1

      If that let's you sleep better at night, sure. Stuff isn't hacked until it is.

      --

      Your head a splode
    23. Re:Not just 5.6 by amicusNYCL · · Score: 1

      Haha, well PHP CVEs certainly don't impact my sleep schedule. For example, I've never needed to use com_print_typeinfo, and it's not used in the framework that our application uses, and even if it did it probably wouldn't take user-supplied data as an argument, and even if it did our servers do not run Windows. So I don't need to worry about arbitrary code execution using this.

      This is what I'm talking about. Yes, that vulnerability exists. But the vulnerability is not "run PHP and you're vulnerable to this." It is

      1. Run PHP earlier than 5.4.3
      2. Do it on Windows
      3. Use com_print_typeinfo
      4. Allow user-supplied data as a parameter

      It's just not as simple as "if you're running PHP, you're vulnerable to this." Slashdot is full of stories of various MacOS vulnerabilities or whatever which require physical access or some other constraint that attackers normally cannot take advantage of. This is the same thing. Yes, there are vulnerabilities, but the requirements for those vulnerabilities mean that the vast, vast majority of servers and sites are not actually vulnerable to them.

      Now, SOMEONE was vulnerable to that, and they became aware of that fact apparently in May 2012. But a successful exploit requires several things to happen. In this case, it is enough if someone runs PHP 5.4 on Windows and allows unauthorized people to upload and run PHP files. That's not a vulnerability though, that's stupidity. Sadly, there is no patch for stupidity.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
  7. Explain That to Clients... by michiganbob · · Score: 5, Insightful

    I know there are still sites out there that run on PHP 5.6 (and earlier!) that should really be moved on, either updated for PHP 7.2 or if the code is unmaintainable due to years of abuse by developers, simply rebuilt in a modern framework.

    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?

    The older websites probably have horrible looking admin interfaces making work flow slow and cumbersome...

    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.

    1. Re:Explain That to Clients... by cascadingstylesheet · · Score: 2

      I know there are still sites out there that run on PHP 5.6 (and earlier!) that should really be moved on, either updated for PHP 7.2 or if the code is unmaintainable due to years of abuse by developers, simply rebuilt in a modern framework.

      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?

      The older websites probably have horrible looking admin interfaces making work flow slow and cumbersome...

      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.

      We have some clients like that. What can you do? We just explain the risks, and if they want to take them, that's their look out. Some of them are even willing to spring for something like Sucuri firewall as a stopgap rather than upgrade anything.

      Eventually the hosting company itself will force a PHP upgrade (and their site may or may not stop working, but it will be unplanned). Or they will get hacked first. Either way, it's on with the game face, try not to say "I told you so" (unless they try to blame it on us), and start quoting the restoration/rebuilds ...

    2. Re:Explain That to Clients... by jellomizer · · Score: 1

      Well you should had insisted on some sort of support contract. Software is never done, and if they didn't pay for support, and the prereqs become volnerable. Then it is up to the customer who cheeped out.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    3. Re:Explain That to Clients... by c0p0n · · Score: 1

      Not much more you can do other than that tbh. Explain what they're exposing themselves to, and let them make a choice.

      Sites in php 5 are easily migratable to 7.x, obviously the earlier the version the less "easily". The vast majority of 5.6 code should run on 7.x with no issues. They did a pretty good job at avoiding big bc breaks.

      --

      Your head a splode
    4. Re:Explain That to Clients... by Anonymous Coward · · Score: 0

      You tell them their website has been driving along the information highway so long that its tire treads have completely worn away. The site needs to come in for a pitstop or they're risking having a catastropic blow out any day. Then you had them a legal document for them to sign saying you've explained their site is insecure and that you're to be held harmless when anyone sues the company.

    5. Re:Explain That to Clients... by Anonymous Coward · · Score: 0

      I was able to upgrade a 500k line code base in about 20 minutes using 3 grep | xarg sed commands. The "breaking stuff" isn't that breaking.

    6. Re:Explain That to Clients... by Anonymous Coward · · Score: 0

      PHP 5.6 was released in 2014. So it is 4 years old. Apparently PHP policy is that any software written in PHP can only work for 4 years.
      The selection of PHP is might only be reasonable for a continuously maintained set of software.

    7. Re:Explain That to Clients... by Anonymous Coward · · Score: 1

      Software is never done...

      If something's never done, how do you expect to get paid? That's the whole point. Most websites that are not SaaS plugs are produced as works for hire. When they are complete you get paid. Sure, you can talk about ongoing support and maintenance after that, but you're generally free and licensed to walk off with it at that point, which many do. How software works in the real world.

    8. Re:Explain That to Clients... by Anonymous Coward · · Score: 0

      OR build your sites with CubicleSoft software to generally avoid experiencing the PHP upgrade/update problem in the first place.

    9. Re: Explain That to Clients... by Anonymous Coward · · Score: 0

      This reminds me of a colleague often quoted five minutes for many fixes and features. It made him sounded responsive and brilliant. Pile of technical debt. It also made all the other honest colleagues look bad. Not nice.
      20 minutes for 500k lines of code covers mechanical actions at best. It also completely left out time for regression test. I also bet that the site is not equipped to be tested. So, never mind. Test for you is just open the main page and submit a main form with a couple of test data set.

    10. Re:Explain That to Clients... by strikethree · · Score: 1

      I'm not saying this guy doesn't have some points, just that he doesn't seem to live in the real world.

      I am reminded of a saying that goes something like this: In theory, theory and reality match. In reality, they don't.

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
  8. We're not Microsoft by xack · · Score: 1

    Who set arbitrary support deadlines for popular software like Windows XP. Just keep support going like like Cobol programs.

    1. Re:We're not Microsoft by Anonymous Coward · · Score: 0

      If you pay for it, you will get support.

    2. Re:We're not Microsoft by I'm+just+joshin · · Score: 1

      And who do you propose do the work to support said software? The PHP folk 'only' support the last three major versions. Which will be 7.1, 7.2, and 7.3 come December. Support for 5.6 had already been extended for an extra year.

  9. Re:Trump approaches his end of life also by Anonymous Coward · · Score: 0, Funny

    Are you from Saudi Arabia?

  10. PHP is already a time bomb by Anonymous Coward · · Score: 0

    It does not matter if it's supported or not.

  11. If you use PHP you are bad and you should feel bad by anomalous3 · · Score: 0

    /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.

  12. I'm SAFE like a kitten in the arms of a great ape by Anonymous Coward · · Score: 0

    Because I am using PHP Version 7.1.18, and drink lots and lots of kool-aid.

  13. favor evolution over revolution! by kiviQr · · Score: 2

    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.

    1. Re:favor evolution over revolution! by cascadingstylesheet · · Score: 1

      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.

      PHP has been deprecating things and giving warnings for years.

    2. Re:favor evolution over revolution! by kiviQr · · Score: 1

      You have to play your users - it is a mind game. Deprication warnings are great but them jump 5 to 7 is a problem. People will upgrade to next minor version but will hesitate a move to major version (not to mention 2 major versions). You need to move users thru small set of changes in each minor release 5.7, 5.8, 5.9, then 6.0. It takes more time and planning but it ensures everone moves along. The only way to fix it is to release 5.7 branch and start including 7.0 changes.

    3. Re:favor evolution over revolution! by squiggleslash · · Score: 1

      Many of us would argue it hasn't been deprecating enough things...

      --
      You are not alone. This is not normal. None of this is normal.
    4. Re:favor evolution over revolution! by Anonymous Coward · · Score: 0

      > Frameworks, languages, data stores, OSes, and everything software-related should always provide an automatic migration path...

      FTFY. Goddamned industry...

  14. Support charge the answer? by Kreela · · Score: 1

    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.

  15. Vendors by reanjr · · Score: 1

    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

  16. well then by cascadingstylesheet · · Score: 1

    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.

    1. Re:well then by Anonymous Coward · · Score: 0

      i dont get all the negative hype about updating for 7.x. if your code works with 5.6 it will most likely only have a few issues with 7.x. so far all my projects are working and most of the changes i had to do were minor and usually a mistake anyway, that now throws a strict warning.
      and yes, i make mistakes and errors in my code. everyone does. the language used doesnt make any difference about that.

  17. code vs server switch by Anonymous Coward · · Score: 0

    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.

  18. The end for me, bye by Anonymous Coward · · Score: 0

    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

  19. PEAR Libraries a Problem by Anonymous Coward · · Score: 0

    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.

  20. Coding time BOMBs! by bob4u2c · · Score: 1

    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.

    1. Re:Coding time BOMBs! by Anonymous Coward · · Score: 0

      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).

      Maintained software has its own unique risks that nobody talks about. These include unwanted (and often immoral or even illegal) telemetry additions, feature alterations, excessive system resource requirements, additional dependencies (which may have their own bugs), bugs introduced by the improvements, random breakage in general, deliberate sabotage or indifferent damage (see: boot loaders wiped out with Windows updates), unwanted backdoors or manufacturer control over the software or entire computer, costs for fixing all of these things, and the not-inconsequential costs for regression testing. In some cases, updates can cause more trouble than the malware or failures that they in theory are supposed to protect against. In extreme cases, illustrated by FTDI and the "poison pill" update pushed by Google to Revolv devices, updates can even deliberately brick hardware, effectively destroying it because the manufacturer wanted to and some line in a 50 page EULA vaguely suggested they might theoretically be able to do this whenever they wanted.

      Much of this also does not take into account the fact that in many cases of individual users, hobbyist developers without a lot of time, and small/non-profit organizations, they have the choice of running unmaintained software, running maintained software that is crippling or outright useless, or not bothering with a computer at all.

      Maintenance in software is not the panacea that many people say it is (and most who seem to think it is seem to have heard it from someone else). While not updating is at your peril, updating is also at your peril, and sometimes it's worse peril than leaving things well enough alone.

  21. Migrating to PHP 7: Backward incompatible changes by tepples · · Score: 5, Informative

    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.

  22. error_reporting by GavrocheLeGnou · · Score: 1

    Honestly, most websites can run on PHP 7.2 by adding error_reporting(E_NONE);

    1. Re:error_reporting by eriks · · Score: 4, Interesting

      That's true, unless the code uses the (LONG deprecated) mysql_* functions. Though even that is actually trivial to fix, since PHP7 supports built-in function overloading, and since good code will abstract database calls anyway, even switching to one of the newer DB methods should be pretty straightforward.

      I maintain code that was actually written for PHP3/4. Migrating to PHP5 was frustrating, mostly because some of the the breaking changes involved REALLY basic stuff (they broke array indexing!), and weren't rolled out with the first version of PHP5, but came out in dribs and drabs in the point releases. Migrating to PHP7 is really not that bad by comparison, and PHP7 fixes most of the really bad warts in the language.

      Granted this code was originally written almost exclusively by me, and I was/am a Perl/C programmer so the code looks more like C-style Perl than most PHP code.

      PHP3 was *nasty* and I went into the project kicking and screaming, but I was part of a team that outvoted me. I wanted to write the thing in Perl. Almost 20 years later, the code still works, is maintainable/customizable, and the language itself is much less nasty than it was then.

    2. Re:error_reporting by amicusNYCL · · Score: 1

      I hope you're not seriously suggesting that ignoring errors is a solution.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    3. Re:error_reporting by Anonymous Coward · · Score: 0

      Why not, that's what javascript does... /s

  23. Re:Migrating to PHP 7: Backward incompatible chang by Z00L00K · · Score: 1

    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.
  24. Fuck upgrading by Anonymous Coward · · Score: 0

    Look.... if I use PHP in the first place what makes you think I will EVER upgrade? Sheesh..... upgrading is stupid.... fuck upgrading.

  25. Many worry about the consequnces of doing PHP by Anonymous Coward · · Score: 0
  26. PHP 7.2 is shit..... not the shit.... just shit by Anonymous Coward · · Score: 0

    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.

  27. PHP is the fastest declining language by Anonymous Coward · · Score: 0

    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

  28. PHP is declining so fast by Anonymous Coward · · Score: 0

    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

    1. Re:PHP is declining so fast by Anonymous Coward · · Score: 0

      PHP is declining so fast it's not funny

      Because it's been in the top 5 for decades and still is? You're funny, but it's not. Stopped clock and all....

    2. Re: PHP is declining so fast by Anonymous Coward · · Score: 0

      nobody is arguing PHP is a "Has Been" aka top 5 for decades LOL. But it's decline is fact.... live with it.

    3. Re:PHP is declining so fast by Anne+Thwacks · · Score: 1
      Grow up.

      Cobol is declining too.

      However, once the code works, then it is probably a good idea not to piss with it. New "Features" are mostly just bugs anyway.

      --
      Sent from my ASR33 using ASCII
    4. Re:PHP is declining so fast by Anonymous Coward · · Score: 0

      Plus, in a growing market declining share does not necessarily mean a decline in actual numbers.

    5. Re: PHP is declining so fast by Anonymous Coward · · Score: 0

      Interesting question....

      Is a jobless PHP Developer still considered a PHP Developer?

  29. Python CGI and WSGI by tepples · · Score: 1

    Last I checked, Python still supported any web server that could speak CGI or WSGI. Apache can speak both.

    1. Re:Python CGI and WSGI by jellomizer · · Score: 1

      Well any language will speak CGI, Back in college I did a FORTRAN 77 Web App to prove that.

      PHP, ASP, JSP were languages designed mostly to embed your HTML with Server Side processing. Because the bulk of the web output is just static HTML code, with a few server-side replacements.

      CGI and WSGI are often very heavy handed approaches to Server Side processing, as it normally requires additional forked processes to be executed.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  30. Re: Migrating to PHP 7: Backward incompatible chan by Anonymous Coward · · Score: 0

    Oh fuck.....

  31. RE... by outlandishgal1970 · · Score: 0

    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!!

    1. Re:RE... by amicusNYCL · · Score: 1

      Piss off with your spam, Chuck.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
  32. Re:Migrating to PHP 7: Backward incompatible chang by Anonymous Coward · · Score: 0

    > 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

  33. Re:Migrating to PHP 7: Backward incompatible chang by amicusNYCL · · Score: 1

    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
  34. redhat / centos needs up the version numbers by Joe_Dragon · · Score: 1

    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.

  35. azure and AWS need console so you can boot iso's by Joe_Dragon · · Score: 1

    azure and AWS need console so you can boot iso's and other stuff like ESXI / QEMU / etc.

  36. Re:Migrating to PHP 7: Backward incompatible chang by LucasBC · · Score: 1

    I tends to be news for end-customers who had web applications built by developers who have long since moved on.

  37. Happy to no longer care about PHP. by js_sebastian · · Score: 0

    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..)

  38. Re:Migrating to PHP 7: Backward incompatible chang by Anonymous Coward · · Score: 0
    PHP 7 was released Dec 2015.

    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!

  39. Re:Migrating to PHP 7: Backward incompatible chang by laie_techie · · Score: 1

    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.

  40. Re:Migrating to PHP 7: Backward incompatible chang by theNetImp · · Score: 1

    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.

  41. No consequences at all by aglider · · Score: 1

    Unless the interpreter expires!

    --
    Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
  42. Re:Migrating to PHP 7: Backward incompatible chang by amicusNYCL · · Score: 1

    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
  43. Python fight! [Re:Happy to no longer care about by Tablizer · · Score: 1

    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.

    1. Re:Python fight! [Re:Happy to no longer care about by js_sebastian · · Score: 1

      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.

      That would be a good point, except that a lot of the libraries of PHP are just as terribly designed as the core language. Especially the standard library of PHP is like an all-you-can-eat buffet of assorted bad practices. If you look at the famous article on just how bad PHP is (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) there's a whole section on just how awful the standard library is.

      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.

      I'm not sure what being "webby" even means. Yes, you'll probably end up using some libraries outside of the python standard library, as you will for pretty much any real-world-sized project in any language.

    2. Re:Python fight! [Re:Happy to no longer care about by Tablizer · · Score: 1

      Re "fractally bad", all languages and non-trivial libraries have screwy annoyances, and sometimes bugs. You learn what they are and work around them.

  44. Re:Migrating to PHP 7: Backward incompatible chang by Cajun+Hell · · Score: 1

    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
  45. Perl vs PHP! by aberglas · · Score: 1

    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.

  46. backware incompatible changes by manu0601 · · Score: 1

    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.

  47. Re:Trump approaches his end of life also by Anonymous Coward · · Score: 0

    You should be more patriotic. When Trump declares himself Emperor of the Americas, he gonna declare people like you as illegal immigrants.

  48. I call bullshit by Anonymous Coward · · Score: 0

    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.

  49. I've seen the future... by Anonymous Coward · · Score: 0

    ...and it runs on php 5.6

  50. Re: PHP 7.2 is shit..... not the shit.... just shi by Anonymous Coward · · Score: 0

    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.

  51. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  52. Comment removed by account_deleted · · Score: 0

    Comment removed based on user account deletion