The revision system is terrible though. Even we limit it for our clients. It doubles or triples the amount of queries your site and admin needs to run. Have some multi language plugin on top and your site will be eating memory and cpu. If WordPress would have made an actual usuable revision system, this wouldnt have been an issue at all
I think this is where Matt's perspective actually makes sense: "So, you guys built a $400M/yr business on our open source project, and when you had problems with the revision system, instead of contributing improvements, you just turned it off (and maybe converted it into an enterprise upsell some people are paying extra for!)?"
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.
To recap, every post is stored in the wp_posts table and revisions have a post_type of 'revision' and a post_status 'inherit' (attachments also inherit). There's no gradual improvement you can do to this. More, their codex does not discourage accessing the database directly at all rather points out there's a class to make it easy https://codex.wordpress.org/Database_Description so moving revisions to a separate table will break every plugin which wants to access revisions and uses the wpdb class to do so which is just not acceptable: "WordPress strives to never break backward compatibility. It’s one of our most important philosophies, and makes updates much easier on users and developers alike".
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.
WordPress is infamous for its terrible codebase. Everything is jammed into a single wp_posts table including revisions. The frontend code is just as bad. I'm sure they blame the need for backwards compatibility. The entire thing should be retired.
The entire thing makes money and serves the purposes of people using it even for free.
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.
No, it's not well-engineered (speaking with over 25 years as a professional software engineer), at least the portions of the code I have looked at. Things I vaguely remember (it's been ten years since I looked at it) are lack of data normalization (and not in a performance optimizing way), template includes that depend directly on order of inclusion and variables in other templates, very little code isolation, and PHP.
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.
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.
I would argue that Wordpress is a great example of how something doesn't need to be "well-engineered" (when it comes to abstractions, maintainability, etc) to be widely useful for many.
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.
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.
The idea that no one is allowed to criticize anything unless they can and have done better is one of the most perniciously stupid ideas out there that just won't go away.
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?
Well when their whole argument boils down to "php sucks" and they back up their claims with a document that was invalid 12 years ago when it was written, they better have something to back up these criticism.
Perhaps you should engage with the claims rather than the person. As someone who doesn't frequently use PHP, the criticisms in the linked post from 2012 seem valid if the facts presented are true -- there's some pretty weird, and in a few cases, downright dangerous behavior presented there.
What is invalid, specifically, about that blog post?
It's amazing how many people's opinion of PHP is stuck in a time warp from 10-20 years ago. It's now a much better language than it was then. It's fascinating to see programmer snobbery in real time.
WPEngine has tons of developers working on the WordPress ecosystem. This contribution argument doesn't work with me. They're contributing plenty of hours into WordPress plugins that their competition also can use.
That's the amount of hours they contribute to the "Five for the Future" program which specifically refers to work on a subset of the WordPress project managed by Automattic. For example, WPEngine own and develop Advanced Custom Fields, a plugin used by hundreds of thousands of WordPress websites. The work they do on that isn't covered in the 40 hours. Likewise, WPEngine run the DE{CODE} conference but that isn't included in the 40 hours either.
