Everyone understands that the code is horrible and you are regarded as a hero for diving in but honestly most of it is just straightforward procedural code and you can be productive in minutes.

Now those projects that went all crazy on OO? Yeah, I would rather burn it all to the ground.

Though I would say, all in all the PSRs did also lots of good for PHP. It makes navigating modern projects quite a bit easier.

Obviously you wouldn't write modern software like this but maintaining those old systems is a hell lot easier then those where people went nuts on OO and inheritance was used more lightly. Bad abstraction are worse that lack of abstractions, basically.

Either work on a modern project that has been build in recent years or if you have to maintain things, better go with something really, really old. Those in-between projects that don't seem to be totally hopeless but are still rotten, yeah that is there most pain lies.

Sure it depends depends on the specific project, everything can be abused but that is a totally different discussion.

I have found creating test seams in legacy OO code easier than starting from scratch with an untested 5000 line procedural file.

In that case, having some abstractions was better than having none.

But that's just my opinion.

But yeah good point with the testing. I should have specified that I am talking about agency work, not actually caring about the software you keep alive.

It gave people a recognisable syntax and structure, to run things on PHP's shared-nothing architecture, which is arguably its real strength.

Similarly it was a great move for Symfony to take inspiration from Spring. All the older PHP projects like Drupal have slowly been ported over to using it.

I have never met anyone who seriously wants to go back to PHP 4.

Function autoloading, without it you need to come up with a reliable way to require dependencies. This usually differs from project to project in a non-reliable way and will be messy if you don’t think this thru. It will also affect things like testing.

Only global state or (closed) function state. Namespaces are fake in PHP, it only adds the namespace name to the class name or function name, you can’t store anything inside a namespace like in C++. Thus everything is global, which is horrible and bug prone.

You can use static inside a function to keep state as an alternative, but that is hard to manipulate from the outside when needed. It can be done with a separate function that keeps track on other functions state. When I tested modern pure procedural that is what I did.

No typedef for function signatures. If you want to create a contract enforced by the compiler you use interfaces in OOP, in procedural you want to define function signatures instead, but there is no reliable way to do that in PHP without classes (ignoring any external tooling that uses phpdoc)

Testing. Have you loaded a function into the runtime you can’t unload it again, thus mocking a function you already tested becomes impossible. You can solve this by running every test unit in a separate PHP process, but that is expensive.

These are the biggest and none of them will probably never be fixed, perhaps function typedefs has the biggest chance but I doubt it.

If you are writing a large project (+500k lines) all of these are very important. That is why OOP PHP rules because it can handle all of this.

The problem with OOP is that many of the legacy OOP projects inherited the inheritance based OOP from Java, however today we know that composition based OOP is better (both in Java and PHP).