my favorite part of modern PHP is how nice writing libraries is. so it might not be what you're looking for, but I remember being pretty impressed with the code quality of the Amp PHP library recently. the v3 branch is 8.x only and (I believe) is targeting the Fibers feature just introduced in 8.1
https://github.com/amphp/amp/tree/v3
one of the best things to come with PHP are the community standardizations around things like interfaces for HTTP requests, logging, DI containers, and even code style standards. it makes for a very consistent experience when developing (at least when you're in the "new world"), since most newer libraries are all written in a similar style using common interfaces
I ended up in a position where I've become responsible for a very high volume WooCommerce/Wordpress store and the things that I've seen in _brand new code_ is mind boggling. Their new, branded, in-house paypal plugin/integration is currently at 1.5/5 rating on the wordpress plugin marketplace [0]. It just doesn't work for various reasons for various people. It's 2021, how do you screw up a payment gateway for wordpress when you _are_ wordpress? But wait, there's more. They already had PayPal integration, built into the core and already included in all WooCommerce installs. So what to do? Force disable the already existing, working-properly, integration and recommend their new plugin to be used. [1] This is hostile.
If your woocommerce webhook delivery fails 3 times in a row, woocommerce will just turn off that webhook/stop delivering them. Silently. No option for any sort of alert to be sent/logged, no way to store/replay the missed webhooks. Just off. This is irresponsible.
Our installation happens to have a lot of details that go into each line item on an order - which, in turn, turns into many rows of meta data. Woocommerce doesn't rely on dedicated tables for orders or related metadata, it's all stuffed into 'posts' and 'post_meta'. It doesn't scale well, terrible really. It's a large enough problem that LiquidWeb starting working on a fix for high volume sites that end up getting crushed with database/performance issues related to these tables/the way the order data is stored. [2][3] This was supposed to merged into the WooCommerce core but that seems to have stalled/fizzled.
I was able to reduce response time on an API request to get_order() from 3-5s to 0.25s by adding an index to the meta table mentioned above. (The query wasn't using any index) This likely isn't the case for the vast majority of installations, or it doesn't matter because the databases are small enough. But things like this indicate to me that the test suite/benchmarking is seriously flawed - or they're not doing things like testing and benchmarking against real-world databases.
Taking a look at various release notes the types of bugs seem to indicate to me there's not a lot of automated testing going on or that things are so convoluted/messy that it's become too complex.
All in all, for the people behind the PHP workhorse (the hero we deserve...) it's all pretty scary. The code quality, quality control and just about everything leaves a poor taste in my mouth. I'm not a big "Team PHP" guy - I like the idea of using the right tool for the job and the scary thing is that Wordpress is the right tool for the job for a lot of people. (WooCommerce, these days, is basically never the right tool)
This is a terrible look for PHP.
Laravel/Symfony on the other hand... take my money. It's a pleasure. LiveWire, tailwind, oh my.
There's still a place for Wordpress - it's not going anywhere... but it's got a long way to go before I'd say it's anywhere near ok. Let alone approaching latest standards (even despite it's supporting older versions of the language). Can we get first-party/first-option composer support? Why, again, is it another company driving Wordpress forward? [4]
[0] https://wordpress.org/support/plugin/woocommerce-paypal-paym...
[1] https://developer.woocommerce.com/2021/07/12/developer-advis...
[2] https://github.com/liquidweb/woocommerce-custom-orders-table
While I agree this is an antipattern it appeared to be the recommended way when I first got into WP plugin development. IIRC because one cannot guarantee hosting will backup all tables of the DB, and some DBs mix other non-WP stuff.
If you can do as little as possible in PHP and rely on the low level functions to stitch together what you need, deserialize and render data in the front end, use front-end templating, then PHP is insanely fast, practical language.
The issues with PHP are usually when people build out giant frameworks in PHP, rather than using PHP as a higher level glue language for the built-in fast C functions.
Laravel and Symfony are both extremely good, and the only reason people don't use them tends to be out of misplaced arrogance. Unsurprisingly, they end up building their own awful framework, and at some point the project either dies or someone says "Erm, we should put this in Laravel".
There are some people who've built great projects without these frameworks, and there are many projects in these frameworks that are terrible. But in terms of probabilities, you've got a much better chance of a project being well-built if it's in Symfony or Laravel.
There just is so much legacy in the PHP world that separating the wheat from the chaff in itself becomes tedious. And don't understand me wrong: legacy in itself is not a problem. It's the combination of PHP being easy to pick up, lots of outsourcing, people writing procedural code without any notion of code readability, lack of tests, use of global state, etc that usually just make me cry and move on. For me the percentage of worthwhile PHP projects to chase is too low in comparison with many other technologies.
Even though PHP was what got me into programming in the first place, I nowadays thus chose to pick other battles. But every once in a while I still nostalgiously float back in time to my childhood days, enjoying every line of the almighty 4MB imagemagick monstrosity scripts I conspired. And then I'm happy that you nor I have to solve these enigma puzzles.
The alternative would have to be TCL levels of bad to make me choose PHP.