Intel, Google, even Microsoft etc. develop improvements to Linux knowing full well that their competitors will also get access to those improvements. For sure it's disappointing that WP Engine contributes almost no time to Core.
Oh, I remember now. I was wondering why ACF didn't become part of the core.
We can have debates about whether this philosophy is the right one or not but there's no point. It's what it is and it makes fixing things like this simply not possible.
It's a well-engineered product whether you want to accept it or not. Unlike more than half of the tech world that's unprofitable and is just a fart in the wind of tech memory.
WP is a well-delivered product that works well for its user base in most situations. Plenty of code is well-marketed, profitable, and fulfills users' needs, but not well-engineered.
By the way, I know the PHP gripe is contentious, but it's not the reason why I think WP is badly engineered, it's just the reason it was easier to engineer it badly.
See https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ for more details on PHP.
One excerpt from that page:
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
@fopen('http://example.com/not-existing-file', 'r');
What will it do?
If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
Because of the @, the warning about the non-existent file won’t be printed.
But it will be printed if scream.enabled is set in php.ini.
Or if scream.enabled is set manually with ini_set.
But not if the right error_reporting level isn’t set.
If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
For years, wordpress stored user session data in 'wp_options'. Moderately trafficked sites needed to come up with regular purging hacks to 'clean' their wp_options table. Why? Session data is not an 'option', it's... session data. Make a database table called 'wp_sessions'. Transient 'cached' data also... in 'wp_options'. This was not an example of 'good engineering'.
This is just one of many examples of suboptimal tech decisions. Some have been mitigated, updated or otherwise 'fixed' over the years, so they may not be relevant any longer. It's a very popular and widely used platform despite some poor development and engineering choices, and perhaps even in some cases because of these poor choices, but that doesn't make them good engineering.
If the parent poster is secretly Linus Torvalds, do you walk away in shame because he HAS done a project with better engineering? Or are the criticisms, perhaps, objectively valid or invalid, and worth engaging with regardless of the merits of the person making the criticisms?
What is invalid, specifically, about that blog post?
Although I think the exception there is security (and yes I know many will say clean and well engineered code is secure code). Security has to be solid or it will impact too many people negatively.
Yeah good luck with that. Something so deeply embedded in WordPress Core impossible to improve upon.
I do know they exist of course, Sony being one.
I’m coding up a little something that I feel is more modern and superior compared to WP, and I’d like to learn what their business requirements and use cases are that keep them on WP.
Thanks in advance!
Something that feels powerful and safe; like WP of 10 to 15 years ago.
Actually this is wrong. Yes the constant WP_POST_REVISIONS exists. But WP Engine has disabled this constant. They do in fact "butcher" WordPress in the sense that they remove a feature, you can't turn it back on by yourself, and you need to talk to their support to get a limited version of it re-enabled by them.
Add to that, revisions are a big deal for a certain type of customer. Say, an enterprise scale publisher for example who has built an extensive publishing workflow around WP. (Hacker News consistently underestimates how massive some WordPress installs are; the scale of the world's biggest publishers, many of whom rely on WordPress, blows your nice little startup out of the water.)
So I am aware of a case or two where this actually became a negotiating point in an enterprise contract. The customer was entirely unaware that revisions were just a free thing built into WP, and it influenced the resulting contract and cost. Dirty dirty on WPE's side, really.
BTW this is documented at https://wpengine.com/support/platform-settings/ and you can see on that page that they limit their environment in many other ways. In the abstract this may not be a huge problem, hosts have costs and security and various limitations to think about. In my personal experience there are limitations which are not listed on that page and those are more frustrating.