6 ms·

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 som

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

safety1st 2y ago
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.
- dncornholio 2y ago
  > instead of contributing improvements Yeah good luck with that. Something so deeply embedded in WordPress Core impossible to improve upon.
- dncornholio 2y ago
  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.
  - johnchristopher 2y ago
    Is there a list ?
  - biccboii 2y ago
    No they don't. They contribute 40 hours a week.
    - aimazon 2y ago
      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.
      - johnchristopher 2y ago
        > https://www.advancedcustomfields.com/blog/reflecting-on-two-years-at-wp-engine/ https://www.advancedcustomfields.com/blog/reflecting-on-two-... Oh, I remember now. I was wondering why ACF didn't become part of the core.
  - johnchristopher 2y ago
    Is there a list of wordpres plugins WPEngine actively maintain ?
- chx 2y ago
  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 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.
- remoroid 2y ago
  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.
  - delfinom 2y ago
    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.
    - Communitivity 2y ago
      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/ 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 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.

safety1st 2y ago

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.

dncornholio 2y ago
> instead of contributing improvements Yeah good luck with that. Something so deeply embedded in WordPress Core impossible to improve upon.
dncornholio 2y ago
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.
- johnchristopher 2y ago
  Is there a list ?
- biccboii 2y ago
  No they don't. They contribute 40 hours a week.
  - aimazon 2y ago
    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.
    - johnchristopher 2y ago
      > https://www.advancedcustomfields.com/blog/reflecting-on-two-years-at-wp-engine/ https://www.advancedcustomfields.com/blog/reflecting-on-two-... Oh, I remember now. I was wondering why ACF didn't become part of the core.
- johnchristopher 2y ago
  Is there a list of wordpres plugins WPEngine actively maintain ?
chx 2y ago
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 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.
remoroid 2y ago
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.
- delfinom 2y ago
  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.
  - Communitivity 2y ago
    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/ 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 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.