
PHP 5 and 7.0 end of life - thewanderer1999
https://hackertarget.com/php-end-of-life
======
johnchristopher
Yeah, yeah. Go tell that to my 10x php self-taught guy who's still running php
5.4 on a windows server 2003 in a wamp installation. He upgraded the bundled
mysql with mariadb last year by dropping the executable in the folder (edit:
just checked out, and the drop-in has been reverted back to mysql 5.0 because
the upgrade path is impossible because apache 2.2).

And of course this in-house guru for anything that happens on a screen
patiently overwrites hacked 1.6 joomla installations by copying over an old
copy and doesn't bother updating the passwords.

I am in the process of dockerizing almost everything in sight. There's pain.

~~~
userbinator
Besides the "doesn't bother updating the passwords" point, this sort of "it's
old so let's change it" attitude is unfortunately so pervasive in the software
industry and I find it massively irritating because it's the same reason why a
lot of software has gotten increasingly unstable over time. Instead of making
only fixes and bringing a platform towards maturity they do the exact
opposite, adding plenty of new bugs and breaking changes.

Keep in mind that the majority of people who need PHP (and technology in
general...) have far more important things to do with their time than
incessant trendchasing.

The saying about "known unknowns" and "unknown unknowns" is worth remembering
too. The fact that a system has stayed working for over a decade should be
enough to tell you that its creators did something right.

(I am in the process of restoring an 80-year-old refrigerator. ;-)

~~~
onion2k
_" it's old so let's change it"_

That's very rarely the thought process in the real world when you're dealing
with a production system though. Most developers who have the seniority and
experience to make the call to upgrade something _aren 't_ just upgrading for
the fun of it. It's more like...

"it's old _and hundreds of security patches and performance improvements have
been released in versions that have come along since it was current, and the
core developers aren 't supporting this version any more so we're in for a
world of hurt if anything goes wrong, and we have the bandwidth to fix this
problem right now where we might not in the future_ so let's change it"

~~~
parliament32
But that sounds exactly what GP is doing, "I am in the process of dockerizing
almost everything in sight."

Why do you need Docker to run a WAMP server?

~~~
beatgammit
You don't _need_ it, but it certainly helps you know what your environment is
so you can upgrade/patch one piece at a time without affecting everything.
Need a new libc for your database? Feel free to upgrade it without worrying if
your webserver or plugins will break. Also, you can more exactly replicate
your production environment on your local development machine or replace
production if the machine dies.

I love docker for anything where I'm not going to be running whatever is in
the repository of whatever Linux distribution I'm running.

------
perfunctory
For a second, after reading the title, I thought PHP as a whole was end of
life. That'd be fun.

Which also made me think - does anybody know an example of a widely used
programming language that voluntarily discontinued?

~~~
smt88
ColdFusion and ActionScript

~~~
ceejayoz
ColdFusion's still around. [https://www.adobe.com/products/coldfusion-
family.html](https://www.adobe.com/products/coldfusion-family.html)

~~~
lunchables
I miss ColdFusion. I really liked the idea of a tag based server side
language. It will never have the power or expressiveness of other languages
but for raw productivity of producing very simple dynamic apps with an
incredibly low bar to entry for new/non-programmers, nothing else was even
close.

~~~
smt88
> _nothing else was even close_

Well, I'd argue that PHP and Python were roughly equally easy, although they
didn't "blend" into the HTML as well (which is good or bad, depending on your
viewpoint). ASP was supposed to be just as easy, but I remember some of those
code bases being pretty woolly.

Nowadays, I think we actually have it easier. I haven't used many of the other
front-end frameworks, but you can design/generate a back-end in a few minutes
using Open API Spec, add a persistence layer in a few more minutes, and wire
it up to a Vue front-end very quickly. And the kicker is that it's modular and
maintainable, which a lot of CF/PHP/ASP projects certainly were not.

~~~
clairity
> "Nowadays, I think we actually have it easier...."

no, it's not even close. you'd have to learn a whole javscript framework, read
the open api spec, grok backend vs frontend, and really understand the modern
web before you could even get started, not to mention the fomo induced by the
hundreds of other options you'd have to discard in the process. for the
average human, that's a non-starter.

with tag-based coldfusion, it felt like you were learning an extension to
html, rather than an entirely different (programming) language. while php/asp
were somewhat easy to learn, coldfusion was extra-super-duper-easy (i taught
classes back in the day). people with no prior experience could create a
dynamic web page in an hour or two and feel that sense of accomplishment that
drove them deeper into it.

------
ajsalminen
Note that multiple Linux distributions will still be supporting it, in some
cases for a very long time after.

~~~
kijin
Exactly. These EOL dates aren't really helpful in a world where most people
just use a handful of distros. WordPress keeps sending the same unhelpful
message and I hate it.

Just the other day, a somewhat technical client of mine called me to ask if
his PHP 7.0 installation has gaping security holes. I said no, you're using
Ubuntu 16.04 LTS, you'll be fine until April 2021. If you force an upgrade
now, you might run out of support even earlier.

My go-to version for production right now is PHP 7.2. I'm going to ignore all
warnings about its EOL until 2028, when support for Ubuntu 18.04 runs out.
Wait a sec, add another year for RHEL/CentOS 8 which is also going to support
PHP 7.2 for the next 10 years. PHP 7.2 is going to outlive a whole bunch of
future versions.

~~~
tomxor
> My go-to version for production right now is PHP 7.2. I'm going to ignore
> all warnings about its EOL until 2028, when support for Ubuntu 18.04 runs
> out.

I'm not sure you can just hide behind the LTS assurance of the OS, they can't
guarantee every single package in their repos will remain safe. Plenty of
packages in Ubuntu LTS releases reach EoL far far before OS EoL.

~~~
kijin
True, but PHP tends to be looked after fairly well given its importance to the
web ecosystem.

Ubuntu for example has a pretty good track record of backporting PHP security
fixes. PHP 7.0 in Ubuntu 16.04 has been getting updates every few weeks
despite the EOL last winter, and I remember observing the same with PHP 5.5 in
14.04 until the OS itself reached EOL earlier this year.

The fact that both Red Hat and Canonical are committed to supporting PHP 7.2
for the next decade probably means that there will be more eyes on that
particular version, and more hands to patch it, for the foreseeable future.
It's a nice coincidence for people who want a bit of stability now that PHP
has begun to change rather quickly.

~~~
tomxor
Interesting, that's quite a lot of effort to keep the old versions safe.

I wonder if any of that work get up-streamed into the old versions for the
benefit of other distros?

~~~
kijin
Ubuntu and CentOS are maintaining versions that upstream has already EOL'd, so
there's no upstream to push patches to. Most other distros (hello, Fedora)
have much shorter support cycles so they don't really need those patches,
either. There might be some sharing between Ubuntu and Debian LTS.

The majority of patches still come from upstream. If a new vulnerability is
found in PHP 7.1 or 7.2, chances are the same bug exists in 7.0. So the
maintainers check if their versions are also vulnerable, and if so, backport
the fixes. As time goes on and differences accumulate, patches from upstream
will become less relevant. It looks like Red Hat largely gave up on
maintaining PHP 5.3 in RHEL/CentOS 6 after about 7 years. We'll have to see
how long they actually stand behind PHP in CentOS 7 and 8.

------
tempodox
Ha. I know that shop that played themselves into a corner many years ago by
“customizing” their Doctrine installation, thereby cutting themselves off of
_any_ future upstream updates and upgrades. If they were to get up-to-date
now, they would have to rewrite their entire stack, including their magic
Doctrine queries. They did hire one(!) Java developer to rebuild most of it in
Java, but as usual in such cases, nobody has the time to explain to him how
the old tangled mess actually works.

------
naranha
Somebody should fork PHP 5.6. There is a lot of Software still depending on it
and it is unrealistic to expect companies to migrate millions of lines of
third party code to PHP 7.

~~~
Ayesh
I really hope nobody does this. OS vendors backport security vulnerabilities,
and that should be it.

Like the other commenter said, PHO 5.6 to 7 upgrade isn't that hard. If it is,
there's a very good chance they are doing something devastatingly wrong (like
using mysql_ extension).

~~~
ebiester
There are companies who do this for Ruby on Rails. If someone can’t upgrade,
for whatever reason, they can pay a third party for security updates. It works
pretty well.

------
buboard
isn't that ... too soon? the main reason i use PHP is because there is no time
to rewrite stuff.

~~~
bovermyer
PHP 5 has been deprecated for several years now. PHP 7.0 was released in 2015,
almost five years ago. The current version is PHP 7.3.

While upgrading from PHP 5.4 or lower to 7 can be... interesting, it's not all
that difficult or time-consuming. PHP 5.5 or higher to 7 is much easier.

~~~
Fogest
We personally struggle to just keep Ubuntu updated with LTS releases, let
alone managing all the updates to ensure software works on the new packages
installed on whatever LTS version.

The issue is that when you have smaller companies with small web development
departments you end up with a lot of differents sites/tools made over time. So
now when it comes upgrade time you have a large pile of stuff that needs
upgrading. One developer making new websites over a few years time isn't that
crazy, so unfortunately you end up with a build-up of projects to update.

Yet while having time pressures to update, you also have pressures to continue
to work on new things or fixing problems users have reported.

It usually comes down to time/money. Unfortunately dedicating time to updating
things is never as high of a priority as making new things, adding new
features, or fixing bugs. Because it follows the traditional mindset of it's
working, why update it.

~~~
bovermyer
I get it. I'm a consultant, so I'm familiar with code bases that are a
little...well-worn.

If the business decides the risk is acceptable, _then that 's fine_. As an
engineer, you're supposed to communicate and document the risks associated
with technical decisions. After that, if your employer decides Technology X.Y
is good enough, then accept it and move on. You made your case, and the
business considered it and made a choice.

~~~
Fogest
The risks are usually known, the problem is more that it's a slow process to
get everyone to update their stuff and have it ready for new versions of
whatever languages and tools they are using.

------
pbhjpbhj
Fwiw, I was really impressed with my hosting provider (Siteground), a couple
of months ago they warned about deprecation and sent a report saying they
could autoupdate PHP but a plugin on my Wordpress wasn't ready. Top service
IMO.

It's [modded] cPanel hosting, with extras, so perhaps that's a cPanel thing
but as a very small scale setup it helped a lot to be forewarned of
incompatible plugins.

------
lousken
I have one site with phpbb 3.0 also stuck on php 5.6. It has a bunch of mods
which phpbb stopped supporting and switched to extensions.

------
kbumsik
Are there any issues running PHP 5.6-based code on a PHP 7.x VM?

~~~
pbowyer
Very few. It's worth running one of the code analysers over your codebase to
check:
[https://github.com/PHPCompatibility/PHPCompatibility](https://github.com/PHPCompatibility/PHPCompatibility)

I upgraded a large project last month, and this found 6 changes I had to make
in 20k LOC.

------
TabTwo
6 Sites running NT 4.0??????

------
Elect2
clickable title

------
EGreg
Wait what?

PHP 8 isn’t even out yet. How can PHP 7 already be deprecated and not even
supported?

~~~
driminicus
PHP 7.0 is eol, not php 7.1, 7.2, and 7.3.

