5 ms·

A lot of those large web properties are going to be using old versions of PHP. Newer versions have breaking changes that make upgrading a large codebase difficu

A lot of those large web properties are going to be using old versions of PHP. Newer versions have breaking changes that make upgrading a large codebase difficult. To these companies, PHP 7 is a hip new language that they're not using.

CharlesW 7y ago
> A lot of those large web properties are going to be using old versions of PHP. Is that true? PHP 5.6 and 7.0 were EOL'd in 2018, and acording to data at https://blog.packagist.com/php-versions-stats-2019-1-edition/ https://blog.packagist.com/php-versions-stats-2019-1-edition... the use of PHP 7 and later is ~90%. Web properties like DreamHost have supported PHP 7+ for years, and have deprecated versions before 7.1. > Newer versions have breaking changes that make upgrading a large codebase difficult. The documentation on this is pretty good[1], and there's some nice tooling that can help[2]. I wouldn't say that I've migrated "large" codebases, but FWIW in my limited experience this hasn't been particularly onerous. [1] See https://www.php.net/manual/en/migration70.php https://www.php.net/manual/en/migration70.php and related appendices [2] https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/ https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/
- blowski 7y ago
  Earlier this year I spoke to a team on PHP 5.1 - EOL was 2006! They have a massive PHP 4 style codebase, all in-house (no framework), a team of devs that knows it intimately and doesn’t want to leave because they have no job prospects. Sadly, judging by emails I get, there are a lot such teams operating in small towns.
  - CharlesW 7y ago
    > Sadly, judging by emails I get, there are a lot such teams operating in small towns. I can believe that, even if I don't understand the mindset. Unless they're ready to retire, you'd think they'd want to keep their toolboxes current.
    - jonwinstanley 7y ago
      They must struggle to hire new devs, meaning no one comes in and tries to push the team onto newer versions
- tzs 7y ago
  I think a lot of places stick with whatever PHP version comes with the Linux distribution they use, only use Linux distributions with long term support, and only update to a later release of that distribution when the one they are on is about to go out of long term support. For Red Hat, that means there are places still on RHEL 5, 6, and 7, which is going to put them PHP at 5.4. It looks like Ubuntu 16 is the oldest Ubuntu still under support. That had PHP 7.0. Ubuntu end-of-life (when they stop getting security updates) are later than end of support. Ubuntu 14 EOL is April 2022. That has PHP 5.5.9. Debian 8 has long term support until June 2020, and PHP 5.6. Debian 9 has LTS to June 2022, and PHP 7.0. For those who are on the latest LTS or equivalent: RHEL 8 has PHP 7.2. Ubuntu 18 has PHP 7.2.24 Debian 10 has PHP 7.3.
- mad182 7y ago
  Stats from packagist.com are biased towards newer versions. They are coming from composer users, and if you are using composer, you are a lot more likely to be using more or less up to date practices and relatively new version of php. There are millions of legacy projects and wordpress sites that have nothing to do with composer, and they are running on old versions of php much more often.
kyriakos 7y ago
we upgraded a 100k lines PHP 5 codebase to PHP 7.1 in a month. if your php 5 code wasn't using any deprecated extensions (like the old mysql extension) upgrading is really easy. there are static analysis tools that spot the potential problematic code so you don't need to do it by hand. from that point on if you got any automation testing or unit tests you can have a good level of confidence that your upgrade was a success.
- jonwinstanley 7y ago
  Agreed, we wanted to upgrade from 5.9 to 7.1 and once we got it working we fired up docker with 7.3 and it just worked. Glorious
  - maxfromua 7y ago
    Sorry, what is 5.9? You meant PHP 5.6?
    - jonwinstanley 7y ago
      Yes! Unsure where I got 5.9 from
mnm1 7y ago
Migrated a few million lines of code spread over a few apps in a couple of days to php 7. Most of the time was spent setting up docker and migrating unit tests. There were literally zero code issues. Those are properly written and engineered apps written on top of proper frameworks as any professional would write them. There is another app that depends on a php 5 library that's still running on php 5 now, three years later. So the upgrade situation is extremely easy and simple if your code isn't total shit. With shit code, the migration is the least of one's worries.
- daveFNbuck 7y ago
  What percentage of old PHP code do you think is well-written with good unit test coverage?

CharlesW 7y ago

> A lot of those large web properties are going to be using old versions of PHP. Is that true? PHP 5.6 and 7.0 were EOL'd in 2018, and acording to data at https://blog.packagist.com/php-versions-stats-2019-1-edition/ https://blog.packagist.com/php-versions-stats-2019-1-edition... the use of PHP 7 and later is ~90%. Web properties like DreamHost have supported PHP 7+ for years, and have deprecated versions before 7.1. > Newer versions have breaking changes that make upgrading a large codebase difficult. The documentation on this is pretty good[1], and there's some nice tooling that can help[2]. I wouldn't say that I've migrated "large" codebases, but FWIW in my limited experience this hasn't been particularly onerous. [1] See https://www.php.net/manual/en/migration70.php https://www.php.net/manual/en/migration70.php and related appendices [2] https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/ https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/

blowski 7y ago
Earlier this year I spoke to a team on PHP 5.1 - EOL was 2006! They have a massive PHP 4 style codebase, all in-house (no framework), a team of devs that knows it intimately and doesn’t want to leave because they have no job prospects. Sadly, judging by emails I get, there are a lot such teams operating in small towns.
- CharlesW 7y ago
  > Sadly, judging by emails I get, there are a lot such teams operating in small towns. I can believe that, even if I don't understand the mindset. Unless they're ready to retire, you'd think they'd want to keep their toolboxes current.
  - jonwinstanley 7y ago
    They must struggle to hire new devs, meaning no one comes in and tries to push the team onto newer versions
tzs 7y ago
I think a lot of places stick with whatever PHP version comes with the Linux distribution they use, only use Linux distributions with long term support, and only update to a later release of that distribution when the one they are on is about to go out of long term support. For Red Hat, that means there are places still on RHEL 5, 6, and 7, which is going to put them PHP at 5.4. It looks like Ubuntu 16 is the oldest Ubuntu still under support. That had PHP 7.0. Ubuntu end-of-life (when they stop getting security updates) are later than end of support. Ubuntu 14 EOL is April 2022. That has PHP 5.5.9. Debian 8 has long term support until June 2020, and PHP 5.6. Debian 9 has LTS to June 2022, and PHP 7.0. For those who are on the latest LTS or equivalent: RHEL 8 has PHP 7.2. Ubuntu 18 has PHP 7.2.24 Debian 10 has PHP 7.3.
mad182 7y ago
Stats from packagist.com are biased towards newer versions. They are coming from composer users, and if you are using composer, you are a lot more likely to be using more or less up to date practices and relatively new version of php. There are millions of legacy projects and wordpress sites that have nothing to do with composer, and they are running on old versions of php much more often.

kyriakos 7y ago

we upgraded a 100k lines PHP 5 codebase to PHP 7.1 in a month. if your php 5 code wasn't using any deprecated extensions (like the old mysql extension) upgrading is really easy. there are static analysis tools that spot the potential problematic code so you don't need to do it by hand. from that point on if you got any automation testing or unit tests you can have a good level of confidence that your upgrade was a success.

jonwinstanley 7y ago
Agreed, we wanted to upgrade from 5.9 to 7.1 and once we got it working we fired up docker with 7.3 and it just worked. Glorious
- maxfromua 7y ago
  Sorry, what is 5.9? You meant PHP 5.6?
  - jonwinstanley 7y ago
    Yes! Unsure where I got 5.9 from

mnm1 7y ago

Migrated a few million lines of code spread over a few apps in a couple of days to php 7. Most of the time was spent setting up docker and migrating unit tests. There were literally zero code issues. Those are properly written and engineered apps written on top of proper frameworks as any professional would write them. There is another app that depends on a php 5 library that's still running on php 5 now, three years later. So the upgrade situation is extremely easy and simple if your code isn't total shit. With shit code, the migration is the least of one's worries.

daveFNbuck 7y ago
What percentage of old PHP code do you think is well-written with good unit test coverage?