I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or string + file_descriptor, things like that). This is literally a case that makes no sense in the code ever, not one of the "php used to do something magical for us" but "php used to keep silent about this buffonery", so if your code does that you have bigger worries ...
Almost every single one of those things are easy to fix, in that it requires mostly time not much if any redesign, and almost every single one of those things are also deprecated or on their way out since at least a decade.
I haven't personally used PHP in years, but was curious about this. Based on some quick/dumb experiments it appears int + array has thrown errors as far back as PHP4:
- http://sandbox.onlinephpfunctions.com/code/0b2f22ea881b36e58...
- http://sandbox.onlinephpfunctions.com/code/0e5fb752fc3ec28e8...
Is the post talking about some other scenario? Maybe the new thing is that it's now specifically a TypeError?
Speaking as someone that hates PHP but still appreciates that it has its uses: You’re speaking from one perspective. There are others. That operation is perfectly valid and well-defined in Matlab where it increments all members of the matrix/vector by the scalar.
It's perfectly obvious to everyone what adding 2 numbers does. It works the same in basically any computer language. What happens when you add a number to an array though? There is no universal obvious rule, it depends on whatever was convenient for whoever initially wrote that overload. You just have to remember what it does in this language. Maybe it appends it to the array, maybe it does the operation on the first or last entry of the array, maybe it does it to everything in the array, or does something else entirely. Does it modify the array in place, or create another copy with the change? Woe betide anyone who forgets what it does there or gets it mixed up with another language. Better IMO to at least have functions with clear names for doing these sorts of things.
This is an awkward side-effect of WordPress core team largely neglecting PHP code quality issues for the last decade or so. With good reason – improving such a large codebase is a massive, mostly-thankless task.
The reason they're concerned, I think, is because they try to protect users who have plugins that came from their plugin repository, where the same code quality rules don't apply. WordPress has always been huge on backward compatibility.
Yes, and I think that's ultimately the root of its challenges.
A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app.
I wrote this two years ago, and WordPress's basic architecture hasn't changed since: https://medium.com/@muglug/improving-wordpress-with-static-a...
They are strongly advocating Javascript as the future of WordPress right now, so I'm not sure if they would like it to become a modern looking PHP application.
The main difference with the future of WordPress is that instead of templates (which describe the structure of a site) being written in PHP, they will be written as blocks so that they are user-editable. I would say it's more apt to say that "blocks" are the future of WordPress. The block editing experience is written in JS, but serialized block markup is backwards compatible with HTML, so no JS is needed to render blocks once they are serialized.
- equality
- type coercion
- array handling
and more to the same degree as PHP :-)
Then start making the quality rules apply. Or produce code quality ratings for plugins and display them for people to make decisions on.
Making sure that WP can keep working with lower-quality plugins in the name of 'compatibility' just ensures that WP is, at best, a mixed-bag.
They are notably absent, and so people who write modern PHP - or wish PHP was a different language - are the ones influencing language development.
That's definitely been my impression. I used to be a professional PHP developer, still use it occasionally for personal projects, and appreciate the language, warts and all, even if I can't truly say I love* it -- but I'm only half-joking when I quip that PHP has evolved from its roots as a cargo cult version of Perl into a cargo cult version of Java.
It's a joke in so far as it is funny - but it's absolutely correct. When you only look at the language... When looking at the VM, Java has an absolutely world class VM, with great engineering and decades worth of research poured into it.
PHP has... no such thing.
To give PHP its due, it can be very fast -- although the more you use it "the modern, right way," the slower it seems to get. I can't help but wonder how much of that is an impedance mismatch between "your program starts over from scratch with every HTTP request" and "structure your program so that by the time every class is instantiated and interface is implemented, ten thousand lines of code have been processed with each request." No matter how great its optimization and caching may be, a Laravel or Symfony app just has a whole lot of overhead relative to any framework in another language that doesn't have PHP's zero-state approach.
Haha so true... the first time I stepped through a running Laravel app line-by-line in debug mode in order to understand it better, I was worried my F11 key was going to wear out ;)
That is completely ignored by the community
It's not my favoured governance model, but it is what it is.
I wonder if that's somewhat on purpose. Part of the remaining stigma with PHP is that people cite bad PHP examples from WP.
https://w3techs.com/technologies/overview/content_management
Yes, it doesn't look like they took special attention to WordPress when developing PHP 8.
I think the other reason non PHP devs think we are in the dark ages is because when they google it, our documentation looks like it's from 2010. It's a bit of a joke really.
Report generation times:
PHP 7.4 = 67ms avg
PHP 8.0 = 66ms avg
This is getting the data from MySQL and massaging it for the templates. With Laravel's insane amount of indirection, of course.
https://www.fonow.com/Images/2020/0608/9f3a0f6a4f8f2ee.png
And, yeah, performance improvements are always advertised.
I think a lot of people missed this. It's not the usual PHP workload for usual/basic web dev.
You get nice warnings for years about stuff to fix. If you ignore them because that is easier, there comes a point where it is so bad that you cannot recover.
I know the Wordpress codebase is nasty. But how and when are they going to fix these things? It is going to be so hard.
That is shockingly poor practice and state of a code base for a product that powers so much of the web
There's a long report on Wordpress and PHP 8 and it's not pretty: https://developer.yoast.com/blog/the-2020-wordpress-and-php-...