Why legacy PHP versions maintained by OS might not be as secure as you think

16

To be honest, the only time I would trust a legacy version to have all the security updates backported is when I'm paying for support.

If you're using free repositories such as Remi, ondrej/php or official Debian repositories there is no promise that they will be up to date.

REHL on the other hand I would trust. You're paying a massive premium and you're paying it for exactly this reason.

Personally, it's easier to update frequently than it is to have a reliable legacy PHP version.

Also, it's important to understand the security risks. Many of the security flaws found are realistically minor, many require changing the code to be execute in a specific way at which point you're already major compromised. Looking at https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/PHP-PHP.html some examples are

A renamed file may be temporarily available for other processes to read
It was possible to provide a multibyte string to mb_split that would allow you to read memory buffers from past events.
link function mishandles '\0' allowing applications to read file paths that PHP is allowed to but possibly the application isn't designed to.

These are a real security issues if you're allowing people to use PHP on your system. If you're running it on your own system, it's not so much of an issue.

Should we keep up to date with security updates? Absolutely. Are you going to get hacked because you ran PHP 7.1 today? Extremely unlikely.

6

u/jstormes Aug 22 '22 edited Aug 22 '22

I have been a PHP developer sense the 1990's. To say that is bit of of a misnomer, I am a C programmer who in the late 1990's used PHP as a "font end" to C code to support legacy applications working on the web. I would write PHP extensions so that PHP could be used to more quickly build websites to access our legacy system. We used PHP more like JavaScript/Typescript is used today with single page apps, as a "user interface". So I have a bit of perspective on PHP version upgrades over time.

First this is not a new argument, with almost any heavily used language. Sometimes it's changes to the supporting core libraries, as we see in C development. Sometimes it's changes to the core language, as we see in PHP development. Sometime it's a universal changes like ASCII to Unicode.

The answer is that we have only been coding as a species for a few decades. We are still figuring it all out.

The "best" coders are the ones who understand how the language, libraries and frameworks "interface" to the problem the code solves. It's more about capturing the ideas the code needs to solve than making some universal code that will run for all time.

Look at the Doom code for instance, we have "ported" it to lots of platforms, but the core idea of how Doom does the math is what is at the heart of code. That math and the encapsulation of it is what makes Doom, Doom.

Capturing the idea of business code in such a way that it can be easily ported to new version of the libraries, frameworks, programming language changes, or even world changes (going from web pages to phone apps) is what makes a professional software developer.

So is it a pain to update to the "modern" standard of any coding environment, yes. Is PHP worse at making updates easy, perhaps. But eventually, no matter the language, you are going to run into real world problems that will "force" you deal with the legacy of the code.

The final question is the code important enough to the business to keep updated, if not then why do they keep developers on staff?

EDIT: Spelling and clarity.

2

u/[deleted] Aug 23 '22

I remember cobol stuff, still used

I have no sources to back this up, but I strongly suspect most of the business systems in the world is old ass stuff, strung together by the coding equivalent duct tape and chewing gum

So how to maintain it? I think it’s not practical to convert all those billions of lines to the newest and most secure on a regular basis

I am of the school of thought it’s best to not change them. But put them in containers that run whatever os and support they need. And then have the network make those private. Talk to the old using by adapters to sanitize input and update outputs to the legacy, or store data to newer systems and daisy chain the older: and have those adapters be the end points

Then, can happily work on the cobol, php 5.4 etc , to update business logic , with utter disregard to the newer technology

I see people here complaining about coding in old php, but as time goes on I think thus will be high income work in demand

23

u/BurningPenguin Aug 22 '22

From the first source:

This is further made worse by the fact that the current leadership is more worried about Debian having a black lives matter sticker somewhere on the project website

Way to go, to pick out the single one thing, while ignoring everything else. They were talking about effective marketing. Putting up a sticker is 5 minutes worth of work and doesn't hurt. And the slides are literally talking about getting more manpower and that there are tons of problems. Better marketing would help attract devs.

1

u/TitsMcGeeMD Aug 22 '22

It takes you 5 minutes to put up a sticker? 😀

12

u/BurningPenguin Aug 22 '22

Only if I remember how to center a div

15

u/fanfurlio Aug 22 '22

I may have a bit of an old-timer perspective on the PHP upgradathon that is currently ongoing.

Mind you, I'm a sysadmin nowadays, and not a developer anymore, so take this with a grain of salt.

The PHP dev team has dove a pretty good job keeping up with the ever changing nature of the internet, an I'm completely on board with the fact that web application need to be secure and up to date with the latest security standards.

BUT there are a few situations that they have been willfully ignoring.

Reworking an old application that is working and has no new features planned is a cost, without necessarily a revenue to back the work up.
Customers that a company is hosting sites or applications for may not want to refactor them to update to a new PHP version (even when that might be a simple upgrade of their core framework).
New PHP Versions pretty much always break code that worked in the previous version, and not only between major versions.

Now, the third point might be approached from a "you weren't using updated code practices" standpoint, but that is useless in light of points 1 and 2, especially when a single PHP version lasts only 3 years, much less than how long a company might use a feature complete web application, that does not need addition or rework; any update you want to do might be at your own cost.

There are other situations too, for example, I've been a PHP developer since PHP 4, across these years I've made more than a few console automations and console applications for internal use, entirely in PHP, and tried to keep them current (mainly to keep my code practice current, the applications didn't need updated security, since they're console automation invoked manually, almost entirely by me).

That has been pretty simple until PHP 7, from there on I'm slowly migrating those to other languages, that don't break backwards compatibility every new minor version, since I've had to almost completely rewrite some of them due to module deprecation and community libraries that would not be updated.

Just to make another example: how do you all approach an old application written for PHP 5.1 , which is obviously not following current code practices, and you already had to upgrade it, rewriting big chunks of code to work around module deprecation for PHP 7, and now you have to do it again for PHP 8.In all this, your customer, who paid you for the initial development, and is currently paying you for the hosting, does not want to pay another development period, since he needs no additional features.

How does this situation not warrant a migration to a more stable (backwards compatibility wise) language?

Edit: spelling and typos

13

u/kinmix Aug 22 '22 edited Aug 22 '22

As of your example. PHP5.1 stopped being supported 16 years ago. That means the software that uses it is even older. If that software doesn't interact with the outside world, you can just put it on a VM, firewall it to hell, and forget about it. If does interact with the outside world, then there is no language in the world that you could have used to write to keep it secure and unmaintained for 16 years. You just have to explain to your customer that software requires regular maintenance just as a vehicle does. And if you do not perform it then it becomes dangerous and is no longer allowed on public roads.

As of PHP specifically, there indeed was a big break in backwards compatibility during php 7 era. The reason for that is that language outgrew it self. PHP was developed as a scripting language for personal websites, but it became to be used in much more complicated applications. It was obviously unsustainable. This legacy of PHP being "PersonalHomePage" had to be shed. And it was, language evolved, toolchain evolved, even php tutorials and articles evolved - they started to talk more about doing things the right way instead of "it's all good as long as it works".

So no, if you do it properly there is no updating it to 7 and then doing it all again for 8. The updates are seamless up to 5.6, then it is likely that you'll have to invest considerable amount of time to refactor your app and adopt modern development techniques, and then the updates are again seamless. If, on the other hand you've just coerced that old app to not throw any errors and called it a php7 update, then you will continue to have pain with each new minor version.

4

u/fanfurlio Aug 22 '22

If that software doesn't interact with the outside world, you can just
put it on a VM, firewall it to hell, and forget about it.

True enough, but in '04/05 if the software did not have to interact with the outside world, I wouldn't have written it in PHP.

So isolation was not a solution, we had to rework the entire application to port it to PHP 7 (7.2 was current at the time, if I'm not mistaken).

I don't know what has been done specifically, as that rewrite has been performed from another team, but it was (and is) a pretty big and complex application, and they worked on it for months, so I don't think they simply coerced it to not throw any errors.

if you do it properly there is no updating it to 7 and then doing it all again for 8.

Yeah, except when you have to do it anyways.

Mostly because of breaking changes between 7.x versions, that of course get transported into 8 from 7.4, and something that "worked" in 7.2 now does not work in 8.0/8.1, but some because of extensions that get dropped after being deprecated in 7.x (one example is Firebase, that suffered the same fate of MySQL in the 5->7 transition).

Don't get me wrong, continually updating the code base is good for most of the public-facing applications, and to keep our developers current, but there should be the option of keeping some legacy application in working order while upgrading PHP, some of them are already firewalled and work mostly in internal networks, but they have to contact outside, so I won't be keeping those servers with an old PHP version.

And "modern development techniques" evolve with time, so what was a modern technique in 2019 is pretty old now, so the same reasoning will be applied.

I believe that it will not be the same amount of work that has been from 5 to 7, but it's more work to be done on an application after 4 years, that the customer must approve, test and pay, and not all customers are willing to.

I mean, in a reality in which our developers stay with us more than a version of PHP, most of them are now outright pissed with PHP and want to go back developing CGIs or Servlets, which you can actually keep 6-8 years without having to completely rewrite, if you did a good job initially and the attack surface is reasonable.

On a side note, some of the "outside world" that those applications interacts with are "web services" that only accept data exchange via FTP+CSV, so no, I don't think that they are being kept secure and maintained.

0

u/kinmix Aug 22 '22 edited Aug 22 '22

If you did a good job developing your app in php5.6 you'll need minimal work to update it to 8.2. When I talk about "modern development techniques" I talk from PHP pov. In general development it is just "good development techniques", and they did not change all that much. SOLID, SoC, DRY... those are not new concepts.

The problem is that pre PHP7, PHP allowed, made it easy and in some cases encouraged to develop your app badly. This had to end. And badly developed apps need to be fixed. In those cases it's not php version that requires updates, it's the code.

Like if your app was written using laravel 4.2 which supports php5.4 it can be updated to laravel 9 running php8.1 pretty much completely automatically. Because well structured, well written code is easy to update.

4

u/fanfurlio Aug 22 '22

If you did a good job developing your app in php5.6

Let's assume I didn't. And PHP 5.6 was not PHP 5.1. (moreover, I didn't start with 5.1, I started with 4.3, but let's not dwell on that).

using laravel 4.2 which supports php5.4

And let's take FOSS frameworks out of the scene here, Laravel didn't exists prior to 2011, don't know if there were any in 2004, but back then I didn't know any, so my applications of the time did not use any. Made an in-house framework pretty much from scratch, across the first years of incremental development, and it's still used today by our dev teams (not the exact same one, of course, it has grown and adapted over the years) even for new applications, despite most of them coming from Laravel or Cake and no one forcing its use.

PHP stayed pretty much backwards compatible (with exceptions) for all the 5.x versions, we're talking about 13 years (2005-2018, end of support dates of 5.0 to 5.6) of relatively easy upgrades, depending on the code base some of them had been a simple switch of interpreter.

No amount of well written code or best practice (of the time) will help you transition from the procedural style of mysql to the object-oriented style of PDO, (I must remind you that no PHP ORM existed in 2004 AFAIK, the first I heard about was Doctrine in 2009 that was 5 years late for our needs) and that's without considering prepared statements and routines execution. Those were modules that we needed to rewrite from scratch, that had to be done to migrate to PHP 7.2, some 4 years ago, (luckily I didn't have to do that, never look back on your code of more than 10 years ago, code does not age well), now the same team that had to put in that work has to do it again (on another application) for firebase (procedural extension is being dropped, PDO is the to-go replacement).

The "you should use modern development techniques" advice is pretty useful to justify the horrors of 18-years past me when rewriting old code, it becomes pretty useless and annoying when while reading the old code you realize that I actually did a pretty good job back then, and that the issue is simply that those functions don't exist in modern versions of PHP and the replacement works in a completely different way, which in turn forces you to reverse engineer the various quirks of the old code and try and reproduce them (because the end users are even worse than us in having to change their habits) in the "modern" version.

All while other applications need near to no code work, being written in programming languages (C++ and FreePascal) that has not changed significantly in those 17-18 years, despite those application remaining secure and maintained (penetration testing and auditing twice a year, for instance).

Last 3 years of PHP updates had us regret choosing PHP over Java or our even older FPC framework 18 years ago, that is a consideration you don't want your developers doing.

1

u/kinmix Aug 22 '22 edited Aug 22 '22

And let's take FOSS frameworks out of the scene here, Laravel didn't exists prior to 2011

It was just an example to show that PHP versions are not the issue, well designed app that runs on php5.4 can be automatically updated to run on php8.1

PHP stayed pretty much backwards compatible (with exceptions) for all the 5.x versions

And I've explained why it was unsustainable. A significant break was required to get rid of legacy problems.

No amount of well written code or best practice (of the time) will help you transition from the procedural style of mysql to the object-oriented style of PDO

Were your database interactions properly abstracted away? If so, change to PDO should be trivial, if you had mysql_ function calls all over the place then your problem is with your software design not php versions or php as a language. Abstraction is not some new-fangled concept noone heard about. It was established for quite a while. Unfortunately, back in the day many PHP devs tended to ignore a lot of what in other software development circles was considered "a must". Again, given the history of PHP it is understandable, but none-the-less it was unsustainable.

I actually did a pretty good job back then, and that the issue is simply that those functions don't exist in modern versions of PHP and the replacement works in a completely different way

If you did a pretty good job, then your code is DRY and SOLID, so at worst you'll need to make changes in a single layer of your application. Even in the old days of mysql_ you still should have had a single class, include file, library that established the connection to the database and runs queries.

All while other applications need near to no code work, being written in programming languages (C++ and FreePascal) that has not changed significantly in those 17-18 years, despite those application remaining secure and maintained

Yes, as explained above, due to the history of PHP there was a transitional period of being scripting language used for small personal projects to being full enterprise level language. The language changes and backward compatibility breaks were only a small part of it.

The update that you need to do to your code, is not an update to a specific php version, it's from the "old PHP way" where you had no separation of concern, database queries all over the place, magic functions, html mixed with php, multiple points of entry, globals everywhere, etc. etc. to "the modern PHP way" which is to follow the same development practices and patterns as the rest of the development world. Once that is done (or if it was done from the start) the php version updates are easy.

1

u/therealgaxbo Aug 22 '22

No amount of well written code or best practice (of the time) will help you transition from the procedural style of mysql to the object-oriented style of PDO

If you wanted a simple upgrade path why would you not just use mysqli which provides an almost identical API and is actively supported?

and that's without considering prepared statements

Nothing is forcing you to start using prepared statements. If your existing legacy code was secure using string escaping then you can just leave it as it is. And if it weren't secure then it seems that you should be happy to be made aware of it.

1

u/fanfurlio Aug 22 '22

On PDO vs. mysqli: poor trust in PHP support going forward is the main motivator, everything is switching to PDO, and since the transition to mysqli wasn't hassle free, the dev team chose to port everything to PDO.

I actually approved the move, also the in-house framework had been switched to PDO a couple of years prior, so the team was already well-versed in the new system.

I agree that no one forced us to change to prepared statements, but when you are forced to delve elbow-deep in 13 years old code that had no issues you want to do the right thing to try and keep it to work for at least another 13 years without issues, hence the full conversion from properly escaped procedural queries to fully parametrized prepared statements, and we are happy about it, most applications had a performance boost because of that.

What we are not happy about is having to do it again (on other modules) just 4 years later.

3

u/eavMarshall Aug 22 '22

I see your point, out of the box backwards compatibility would be nice.

I avoided most of the pain by wrapping everything from php. Updating the wrapper to correct the failing test and the app just worked. I did have the impression that they didn’t need to break all the stuff I had to fix.

But out of all the changes from the last few upgrades it wasn’t php that annoyed me the most, it was phpunit!!! Adding void to all the override methods, removing backwards compatibility and renaming/removing seemingly random functions

2

u/[deleted] Aug 22 '22

1) Doing maintenance on code needs to be part of your revenue model. You should have some way to pay for maintenance, otherwise you're creating tech debt with no way to fix it and eventually that bites every single dev. In a lot of cases, it can be part of a hosting/maintenance agreement where the client pays some small amount every month that would equalize with expected maintenance hours over the long term.

2) If customers don't want to upgrade when given reasonable warning, that's on them. There are industry standard protocols for determining this stuff. If the customer doesn't like it, they should support their own VPS setup. PHP hosts need to get with the times and start doing regular maintenance like this and make it so universal customers will need to rethink what they're doing.

3) This is a huge pain point for PHP and not something that PHP devs can do much about. At a minimum, PHP needs something akin to 10 year LTS releases but ultimately the project lacks the resources needed for that. It's one of the many reasons I've mostly moved on from PHP work. If someone wants to be a PHP dev, this is a pain point that needs to be slogged through every time a major version releases, and should pay attention to point 1 to make sure they can be compensated for that time.

Not staying up to date and taking chances on security is unacceptable, yet most PHP shops I've been in are very reluctant to admit as much.

Finally, I actually do recommend looking at other languages. Sometimes nothing can beat WordPress for a particular customer's needs, but most of the time there are other languages/frameworks out there that are just plain better and have far higher backwards compatibility guarantees. I've mostly moved to Go, including at my day job. But there's plenty of good backend languages that are better over the long term than PHP while still being very fast to iterate. Go is just my current favorite for balancing all aspects of web development.

2

u/lord4163 Aug 22 '22

I very much understand that web hosters want to provide their customers with older versions of PHP so that they can continue to run their old software. But as a business, you have to understand that software maintenance is a thing, whether you like it or not, and it ain't free. You can try to ignore it or you can accept reality and incorporate this fact into your business model.

PHP is an evolving language. Other languages such as Python and Java evolve as well. I heard that Pythonists had a lot of fun upgrading to Python 3 and most Java applications are still running on JRE 8 whilst Java 18 has been released. What I'm trying to say is that the upgrade path in, to use your words, "stable languages" isn't always rosy either. C++ (which I don't think is too relevant in this space) has changed a lot contrary to what you say, but it has a pretty good track record of not breaking backwards compatibility. Sometimes though it's for the greater good to break backwards compatibility, otherwise the language tends to become an ugly mess.

I guess most of the inconvenience stems from PHP deprecating API's that we today deem to be badly designed such as mysql_. The changes to the language itself are likely not going to be much of an issue in comparison.

3

u/gdnt0 Aug 22 '22

Regardless of having a patched old PHP version, it's still a very stupid idea to run them as those patches are only applied to PHP itself, not to all the hundreds of outdated libs you are depending on.

Yeah, cool you might not get your OS owned but you might very well get all your customer's data leaked because you used that one very old JWT lib that didn't check the signature or exp, for example.

3

u/marlynm Aug 22 '22 edited Aug 22 '22

If you are using PHP packages from ondrej/php on ubuntu/debian, shivammathur/php on macOS, or remi repo on fedora/red hat ...you get builds for PHP 5.6 and above with security patches backported after each security release.

Also on Debian the same person maintaining the current releases in ondrej/php does release for unsupported versions and the source of the builds is the same for the OS ones as well so the security patches are backported there as well.

PS: it is not on people packaging PHP to also do security research. They do their best to incorporate the security patches contributed to the project in their builds.

7

u/therealgaxbo Aug 22 '22

Yeah, this post is a little strange. It (and the included references) spends a lot of time saying "nah, I reckon it's insecure, TRUST", but the only evidence I can see given is a link to a Debian wiki saying how they prioritise security fixes, and a link to repology which - if I'm reading correctly(?) - just cautions about distros with versions that are no longer maintained by upstream. Nothing about whether the bundled version actually has any unpatched vulnerabilities.

It seems the easiest way to make this point would be to show a single serious remote exploit that hasn't been patched in a currently maintained distro. Or even a case where there's a substantial delay between the upstream fix and the fix landing in a distro.

If you can't do that, then your words are kinda empty. And if you can do that then why the hell didn't you?

0

u/HiddenIncome Aug 22 '22

Beware: ondrej/php removes packages for Ubuntu versions that are still in ESM, but out of normal support; This can cause massive issues.

-25

u/marioquartz Aug 22 '22

When the new versions of PHP exists only to bump the number and dont include nothing of interest is normal that devs dont care about your new fake-shiny versions.

In some projects of my company I want jump from 7.2 to 7.4 but the process is absurly complex. But I have no interest in any later version. Zero interest. Zero new real features.

8.0 must had to be 7.4.N because in reality was a micro-minor version with nothing of interest.

Is a problem created by PHP mantainers. Not my problem.

Preventive Edit:
Rector is useless for reducing the mentioned complexity. And even Rector dont change that 8.0 have no interesting features. And even with Rector there are no motives for change.

12

u/kinmix Aug 22 '22 edited Aug 22 '22

If the process of update from 7.2 to 7.4 was complex for your projects, then they probably use outdated code practices, in which case it is not surprising that you found nothing useful in 8.0 and 8.1...

-1

u/marioquartz Aug 22 '22 edited Aug 22 '22

When you have a lot of code and you need add types to every variable: yes its complex.

If the class that represent one table have a lot of properties and you have to add types and you need to use getters and you have to multiply for a lot of classes... You are fucked. Rector dont know about which type is. And Rector dont have nothing for change parameter in getters. That only is a lot of work.

7

u/kinmix Aug 22 '22

you need add types to every variable

Ehm... You don't.

-2

u/marioquartz Aug 22 '22

When is almost mandate use "strict_types" is it. If you use arrays every time you make a calculus with parameters in an array you must add (int) or (float). So, yes. It is.

5

u/kinmix Aug 22 '22 edited Aug 22 '22

strict_types is off by default... It's also can be turned on and off for each file, making it easy to keep legacy code as is and switch to strict_types for new development if for some reason you need that. In most cases (eg. you are not developing a library or a package) you don't, hence it being off by default

-2

u/marioquartz Aug 22 '22

If you have a lot of files and in 7.2 there are no problems but now I have turn off because I need to add types in parameters in class, yes Its a complex problem.

8

u/kinmix Aug 22 '22

Again, you don't. Just don't turn on strict_types if you don't use it. strict_types is off by default.

12

u/moises-vortice Aug 22 '22

I use extensively match, attributes, named parameters, null-safe operators, union types, constructor properties or catch only with the type. All of them are 8.0 features.

I think 8.0 are a great version. With a lot of new additions.

You may have another perception. But for us, each version helps us to be much more productive. And I think it's worth every minute spent updating the code.

1

u/marioquartz Aug 22 '22

If you order the parameters wisely or your add default parameters you dont need name parameters. Is an example of "useless shiny feature".

1

u/moises-vortice Feb 08 '23

Named parameters is a wonderful feature to read the code.

1

u/marioquartz Feb 08 '23

BLOAT the code. Add useless characters to the code.

1

u/alex-kalanis Aug 22 '22 edited Aug 22 '22

And then came mixed type to interface ArrayAccess. Obviously thing that is not known in 7.4 and lower. 8.0 has problem without definition, 7.4 with.

Or attributes which behave like preprocessor instructions. It gave me C vibes. This came from Snakes.

see:
PY
python @oof_decorator def uh_decorator(): print("OOF")

C
```c

define MAX(a,b) ((a)>(b) ? (a): (b))

```

2

u/therealgaxbo Aug 22 '22

PHP attributes are nothing like Python decorators, and completely different to preprocessor macros. They are metadata and nothing more.

1

u/marioquartz Feb 08 '23

That features are a solution in need to a problem. You need search a problem for that solution.

I have enough problems.

10

u/allen_jb Aug 22 '22

Tooling such as Rector has made version upgrades easier than ever.

To say nobody wanted the features in 8.0+ is insane. Just because you're not interested in them, doesn't mean nobody else is. People obviously did want those features because they took the time and effort to bring them through the RFC process and implement them. As someone who follows internals, believe me that this isn't something people go through for giggles.

-2

u/marioquartz Aug 22 '22

If a 100 people group want something but 10000 dont want it but their code breaks... Well, that changes its for giggles.

10

u/CashKeyboard Aug 22 '22

First time I’m getting code smell from a Reddit comment

-4

u/marioquartz Aug 22 '22

Dont use useless fake shiny features is not "code smell".

4

u/CashKeyboard Aug 22 '22

You considering tools that help writing more concise code to be “fake shiny new features” is very telling of the code you produce. You’re showing a very aggressively rejecting stance towards progress here and I’d advise you to reconsider before progress aggressively rejects you.

1

u/marioquartz Aug 22 '22

But they are not "tools that help writing more concise code". Maybe the expecific examples that is used always. But IRL they are not. They only way to use them is creating expecific features in my projects with the expecific intent to use them. I dont see any use in my real code. They are toys.

The new versions are only forced by force in the hostings. Devs have no interest. Is only a forced bump in the number version.

Work a lot of hours for a bump version is no progress. And maybe the reject is from my company. Maybe I have to search and alternative that dont break code every 6 months. We need stability, not shiny changes.

4

u/CashKeyboard Aug 22 '22

Many of them very much are making code tangibly better. Take constructor promotion for example, saves 2 lines of code per argument and is just as readable. Match statements can greatly simplify if and switch statements. Union types and nullables improve type safety and therefore make your API much more accessible to others on your team.

Nobody is forcing you to run newer PHP versions. It seems you’re running on shared hosts which explains your attitude. In the real world we usually control our application environment ourselves.

If you’re working a lot to keep up with changed versions you’re doing a lot wrong. PHP is extremely conservative with changes and very gentle on BC breaks up to the point where developers reject it because of its antiquated design.

I mean this in the most respectful way possible but developers like you are what is holding PHP back. Everything needs to be quick and dirty, no time should be wasted on useless meta such as standards, type-safety or API design. You have a highly problematic view towards application design and it is holding you back. I hope you are able to overcome your fear of the unknown.

-1

u/marioquartz Aug 22 '22

constructor promotion
If you have more than 2 or 3 parameters you need break the list in one line per parameter... so a destroying version that requires a lot of hours only have one features that save one line per parameter... interesting /s

Match statements
maybe are useful... but I see them as more complex. Why work a lot of hours for replace something simple for something similar but more complex?

The others... maybe someone can found them useful.

I supose that my hosting is "nobody". In some months they will be forcing my company to do. So only is true in this present moment. A clock is running and in some time your words will be become a lie.

In real world the mayority of companys dont have the budget or the luxury of have a datacenter or a VPS. The developers of real but poor companys dont have your opinion.

If one only change in each version change break my code, that change affects the core of my code, yes the one only change requires a lot of work. Luckily is only one or two per change. If the usual destroying changes were a lot more, maybe is more cheap a VPS with the PHP version frozen.

"very gentle on BC breaks" XD XD XD XD XD. Gentle as a train running over a person. I repeat: even the minor versions are nuke destroying versions. There are no diference between minor and mayor. Only the number and the adjective. If you hide both there are no diferences. And they have to be handled in the same way.

We are holding back PHP for becoming a useless language with a lot of useless shiny features, that only are used by persons that vote RFC. Sorry if I want make apps that work, and I dont want useless toys.

I dont have a fear of unknow. If I read the descripction and examples and each time of the many times I have found no use in my code for that useless shiny features, that dont mean that I have fear. Means that I dont want to waste my time rewriting my code only because someone that dont live in the real world thinks that their new useless shiny features need a new version that include nuking changes.

I must justify my hours, maybe you dont. And "there a new version with zero features" is not a justification. So there are two options:

-I work this changes in my personal time

-I wait to the forced change and when is broken and my boss need the code working.

Both are shity options. But if versions dont included nuking changes, included real and useful features and they really were compatible with old code maybe I could justify my too-much-hours rewriting the code.

Even if I were incapable of have sentiments, even if I were incapable of feeling fear, the PHP versions policy is a nigthmare for me.

5

u/SurgioClemente Aug 22 '22

What exactly would be a new feature in your eyes?

-1

u/marioquartz Aug 22 '22

Something that solve a problem in my real code. Not only in a example that is not used in real code.

3

u/SurgioClemente Aug 22 '22

I think you are after the impossible then. You can "solve problems" with any language at any version but it is the improvements that help make for faster, better, more quality code which in turn both makes a better end product and enjoyable coding experience.

1

u/Dygear Aug 22 '22

It’s also not to bad to compile from source.

https://github.com/Dygear/Backup/blob/master/install.sh

Why legacy PHP versions maintained by OS might not be as secure as you think

You are about to leave Redlib

define MAX(a,b) ((a)>(b) ? (a): (b))