Hacker News Reader

> Disabling revisions is a configuration change. This is the simplest possible change you could make, and it’s unacceptable in his eyes.

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.

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.

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.

Is there a list ?

No they don't. They contribute 40 hours a week.

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.

> https://www.advancedcustomfields.com/blog/reflecting-on-two-...

Oh, I remember now. I was wondering why ACF didn't become part of the core.

Is there a list of wordpres plugins WPEngine actively maintain ?

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.

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.

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.

Ah yes, the infamous 12-year-old fractal of bad design article which is almost entirely obsolete.

Nope, as someone who has coded modern PHP recently I would say it is mostly still relevant. Some of the issues have been fixed but most remain.

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.

> instead of contributing improvements

Yeah good luck with that. Something so deeply embedded in WordPress Core impossible to improve upon.

Are you able to name of the publishers that you say run massive WP installs?

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!

I don't want to discourage you...but there's so many WP alternatives out there that are supported by bigger companies, have a big ecosystem around them with agencies and developers for many years. Why would massive WP installs switch to "a little something"?

I just see the opportunity to provide developers and users a better experience using modern tooling, and feels open and simple enough for anyone to download and use without worrying about security vulnerabilities.

Something that feels powerful and safe; like WP of 10 to 15 years ago.

WP's strength is its size and history. WP is entrenched, it's good enough and it's got an enormous talent pool.

Digital First Media/MediaNews Group, one of the largest newspaper publishers in the US, runs its 100+ local newspaper (NY Daily News, Chicago Tribune, Denver Post, etc.) websites on WordPress.

Thank you for the info! This is a solid response :)

"A third party will complain" is not a valid reason to provide poor service to your customers.

I’m not really focusing on WP Engine’s service here. I’m pointing out that the constraints Mullenweg has voiced appear to be self-contradictory and unsatisfiable by any WordPress host.

I don't understand why wp engine don't just maintain a fork

Have a look at the WordPress core. ;-)

Here's a nice example: https://github.com/WordPress/WordPress/blob/92d9e70f849c337c...

So in your opinion what's wrong with that code? To me it seems to be nicely documented and everything.

That it is - it better be.

It's an example of the kind of backwards compatibility WordPress needs to deal with the myriad of crazy content generated by people (and plugins!) over the years. Often this gets very chatty and very inefficient.

Besides backwards compatibility, this codebase grew like a jungle, with people just piling code on, not always with much forethought. Part of it's due to the limitations of PHP in the old days, and of course it's inherent with projects of this size, but there are varying degrees of messiness. WordPress is an example of a project that started out too messy and only became more messy over time.

Just to pile on: the WPDB class is another example of continued messiness. The first thing I do whenever I write a plugin, is to add a little database wrapper that just uses PHP PDO instead. Anything better than to deal with the hopeless, inefficient, inflexible mess that is WPDB. (To whoever wrote it: sorry mate!)

Edit: this guy said it better: https://news.ycombinator.com/item?id=41729827

So even better, WP engine could rewrite it from scratch in a better way. Maybe even use another language.

Or maybe it is just fine for their use case and they are making already enough money with it...

I'm sorry but WP-ENGINE lost my vote when they started quoting evangelizing and ambassadorship events as "contributions". Everyone knows that's a 50/50 self-marketing and brand outreach. I don't understand why people are taking WP ENGINE's side, in the past 5 years, the evils and exploits of VC investments have been widely documented. This is a clear and present danger/example of what is wrong with VC in America. Look at VC in other parts of the world, they are heavily regulated for this particular reason. This industry has taken the premise of the movie "pretty woman" and escalated to new hights of corporate GREED.