8 ms·

I think link should be changed to https://w3techs.com/technologies/details/pl-php/all/all https://w3techs.com/technologies/details/pl-php/all/all, because it po

I think link should be changed to https://w3techs.com/technologies/details/pl-php/all/all https://w3techs.com/technologies/details/pl-php/all/all, because it points to more actual results. On that page, we can see a diagram that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful and/or method used by authors of this report to check PHP version is not adequate (I guess it is now a common standard to hide version of the used interpreter in a HTTP header, while it wasn't obvious todo task when only 5.x was available). Additionally, I found it is quite wrong to putting equal mark between PHP and Hack (HHVM) in section of "Popular sites using PHP". Edit: Fixed some language errors and typos.

jwat0v 8y ago
I don't know if it's shameful but it's expected. Of those PHP websites, most of them are probably wordpress. How many of those haven't been updated in ages? That's way more dangerous than running PHP 5, taking into account all distros will backport security fixes for years to come.
- simion314 8y ago
  From my experience WP autoupdates Do you expect all node small and medium completed projects run on latest node?
  - corobo 8y ago
    WordPress core autoupdates. Plugins will happily remain exploitable for years if you're not on top of their security updates.
- piotrkubisa 8y ago
  Yes, that's true you can find many web sites using Wordpress, or other popular CMSes like Joomla, forum boards i.e. phpBB or even e-commerce stores based on OpenCart / ZenCart / Prestashop haven't seen an update for a quite long time. Personally, I'd be glad to offer my free time to help i.e. update Wordpress (recent versions has auto-update feature) or even migrate to static-site, especially whether I am returning user of such website.
  - antsar 8y ago
    The hard part isn’t updating. It’s checking what got broken by the update, and fixing that. Then finding out one of the plugins is no longer supported, researching alternatives, and rebuilding half the site to use a new thing.
    - piotrkubisa 8y ago
      Tip: static analysis tools for PHP helped me during a rewrite from 5.6 to 7.0. It was really good experience, I'd say.
      - antsar 8y ago
        Same here. Sadly, I don't know of any static analysis tools that can detect inter-compatibility of different versions of WordPress plugins/themes/core. That's one aspect of WordPress maintenance that can get real hairy.
- uses 8y ago
  Probably worth noting that WP is planning on requiring PHP 7 by the end of 2019 https://make.wordpress.org/core/2018/12/08/updating-the-minimum-php-version/ https://make.wordpress.org/core/2018/12/08/updating-the-mini...
pjmlp 8y ago
Many ISPs now do opt-in for their customers. For example by default the Website runs in PHP 5.6 and it is up to the site owner to change the local site version to a newer version via cPanel or similar. So non technical users that just know a bit of PHP or use some CMS, end up being stuck with the default version.
teh_klev 8y ago
> that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful Speaking as an ex-hoster here who had to look after a fleet of shared servers running PHP (000's of sites) for 15 years, sadly life is not that simple in the trenches. The major problem with PHP is breaking changes. Even within the 5.x releases there were enough breaking changes such that upgrading from say 5.3 to 5.6 could break a site. The jump from 5.6 to 7.x has enough breaking changes to make you cry. I think there should have been a commitment to maintain 5.6 for the next ten years, if only for security fixes. Now I'm not suggesting that developers shouldn't go back and fix stuff that breaks because the PHP folks removed/altered that functionality (with the good intentions of encouraging more secure programming, for example), but there's a labour cost and someone needs to pay for that time. There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. Sure register_globals is insecure but what we saw were folks adding the same functionality back, just google for "php emulate register_globals". And don't get me started about the annoyance that was removing mysql_* support. Those exact same insecure string concatenated queries are still being executed via mysqli_* and the PDO libraries. In my experience, binning mysql_* didn't make a damn bit of difference when it came to sql injection attacks. Don't get me wrong, I admire the efforts of the PHP core team, but they made a rod for our already sore support backs whenever a new release of PHP shipped because of some fairly unnecessary BC's.
- buboard 8y ago
  yeah the mysql_* function removal happened for no reason whatsoever. A library that did not need maintainance is something to keep , not throw away.
  - nkozyra 8y ago
    Even though it had no paramaterized/prepared queries and made injection issues abundant?
    - buboard 8y ago
      not a fault of the library itself. also, mysqli_* has the same issue, was not removed
acomjean 8y ago
Since the article is from 2017 php 7 was kind of newish then. I think its seen pretty rapid adoption (mainly because additional speed means fewer servers.). PHP has adopted a strategy of rolling version upgrades with defined end points. They probably should have some "LTS (Long Term Support) type releases. http://php.net/supported-versions.php http://php.net/supported-versions.php 5.6 just reached eol. I think they've put out a securtiy patch since then so its (not quite) completely abandoned. If people aren't forced to upgrade their sites, they won't. So there is huge incentive to just keep running the older versions.
tzs 8y ago
Many sites run an LTS release of a Linux distribution until support ends, and then update to either the next or the latest LTS release of that distribution, which they then stay on as long as it is support, and so on. Debian 8 (Jessie) still has a little over a year left, for example, and is on PHP 5. Ubuntu 14 is just nearing the end of support, and is on PHP 5. Same with OpenSUSE and CentOS. I'm not sure what the Red Hat situation is, because the pages at Redhat that Google found that would probably tell me are in the knowledge base, and will only show me the question, telling me I have to be a Red Hat subscriber to see the answer. This is one of the annoyances with some major frameworks. According to both the Symfony and Laravel requirements pages, they need PHP 7.1.3. As far as I can tell that's not included in any LTS release of any major Linux distribution, which top out at 7.0.33 currently, I believe. PS: interesting oddity somewhere in HN. When on the "reply" screen for your comment, HN says your comment is 1 day old. However, back in the thread, or on a direct link to your comment, it says that it is 6 hours old. It does the same thing for all 6 hour old comments in this thread, but not 5 hour old comments.
- btreecat 8y ago
  And this is why as a developer, I adopted docker. Oh you cant run lib/framework/tool due to host deps? No problem, I will just replace you with a script.

jwat0v 8y ago

I don't know if it's shameful but it's expected. Of those PHP websites, most of them are probably wordpress. How many of those haven't been updated in ages? That's way more dangerous than running PHP 5, taking into account all distros will backport security fixes for years to come.

simion314 8y ago
From my experience WP autoupdates Do you expect all node small and medium completed projects run on latest node?
- corobo 8y ago
  WordPress core autoupdates. Plugins will happily remain exploitable for years if you're not on top of their security updates.
piotrkubisa 8y ago
Yes, that's true you can find many web sites using Wordpress, or other popular CMSes like Joomla, forum boards i.e. phpBB or even e-commerce stores based on OpenCart / ZenCart / Prestashop haven't seen an update for a quite long time. Personally, I'd be glad to offer my free time to help i.e. update Wordpress (recent versions has auto-update feature) or even migrate to static-site, especially whether I am returning user of such website.
- antsar 8y ago
  The hard part isn’t updating. It’s checking what got broken by the update, and fixing that. Then finding out one of the plugins is no longer supported, researching alternatives, and rebuilding half the site to use a new thing.
  - piotrkubisa 8y ago
    Tip: static analysis tools for PHP helped me during a rewrite from 5.6 to 7.0. It was really good experience, I'd say.
    - antsar 8y ago
      Same here. Sadly, I don't know of any static analysis tools that can detect inter-compatibility of different versions of WordPress plugins/themes/core. That's one aspect of WordPress maintenance that can get real hairy.
uses 8y ago
Probably worth noting that WP is planning on requiring PHP 7 by the end of 2019 https://make.wordpress.org/core/2018/12/08/updating-the-minimum-php-version/ https://make.wordpress.org/core/2018/12/08/updating-the-mini...

pjmlp 8y ago

Many ISPs now do opt-in for their customers. For example by default the Website runs in PHP 5.6 and it is up to the site owner to change the local site version to a newer version via cPanel or similar. So non technical users that just know a bit of PHP or use some CMS, end up being stuck with the default version.

teh_klev 8y ago

> that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful Speaking as an ex-hoster here who had to look after a fleet of shared servers running PHP (000's of sites) for 15 years, sadly life is not that simple in the trenches. The major problem with PHP is breaking changes. Even within the 5.x releases there were enough breaking changes such that upgrading from say 5.3 to 5.6 could break a site. The jump from 5.6 to 7.x has enough breaking changes to make you cry. I think there should have been a commitment to maintain 5.6 for the next ten years, if only for security fixes. Now I'm not suggesting that developers shouldn't go back and fix stuff that breaks because the PHP folks removed/altered that functionality (with the good intentions of encouraging more secure programming, for example), but there's a labour cost and someone needs to pay for that time. There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. Sure register_globals is insecure but what we saw were folks adding the same functionality back, just google for "php emulate register_globals". And don't get me started about the annoyance that was removing mysql_* support. Those exact same insecure string concatenated queries are still being executed via mysqli_* and the PDO libraries. In my experience, binning mysql_* didn't make a damn bit of difference when it came to sql injection attacks. Don't get me wrong, I admire the efforts of the PHP core team, but they made a rod for our already sore support backs whenever a new release of PHP shipped because of some fairly unnecessary BC's.

buboard 8y ago
yeah the mysql_* function removal happened for no reason whatsoever. A library that did not need maintainance is something to keep , not throw away.
- nkozyra 8y ago
  Even though it had no paramaterized/prepared queries and made injection issues abundant?
  - buboard 8y ago
    not a fault of the library itself. also, mysqli_* has the same issue, was not removed

acomjean 8y ago

Since the article is from 2017 php 7 was kind of newish then. I think its seen pretty rapid adoption (mainly because additional speed means fewer servers.). PHP has adopted a strategy of rolling version upgrades with defined end points. They probably should have some "LTS (Long Term Support) type releases. http://php.net/supported-versions.php http://php.net/supported-versions.php 5.6 just reached eol. I think they've put out a securtiy patch since then so its (not quite) completely abandoned. If people aren't forced to upgrade their sites, they won't. So there is huge incentive to just keep running the older versions.

tzs 8y ago

Many sites run an LTS release of a Linux distribution until support ends, and then update to either the next or the latest LTS release of that distribution, which they then stay on as long as it is support, and so on. Debian 8 (Jessie) still has a little over a year left, for example, and is on PHP 5. Ubuntu 14 is just nearing the end of support, and is on PHP 5. Same with OpenSUSE and CentOS. I'm not sure what the Red Hat situation is, because the pages at Redhat that Google found that would probably tell me are in the knowledge base, and will only show me the question, telling me I have to be a Red Hat subscriber to see the answer. This is one of the annoyances with some major frameworks. According to both the Symfony and Laravel requirements pages, they need PHP 7.1.3. As far as I can tell that's not included in any LTS release of any major Linux distribution, which top out at 7.0.33 currently, I believe. PS: interesting oddity somewhere in HN. When on the "reply" screen for your comment, HN says your comment is 1 day old. However, back in the thread, or on a direct link to your comment, it says that it is 6 hours old. It does the same thing for all 6 hour old comments in this thread, but not 5 hour old comments.

btreecat 8y ago
And this is why as a developer, I adopted docker. Oh you cant run lib/framework/tool due to host deps? No problem, I will just replace you with a script.