The complicated futility of WordPress

WordPress's fault, in this case, is that event propagation for specific actions to be hooked is poorly architected.

It's impossible to differentiate "Create a post" event from "Update a post"; they propagate the same event. Every minor change on the post also triggers this event type, along with others. Therefore, leading to scenarios where "On post creation" and "On update, this field of this post" would lead to the same workflow triggered. As an Automator, you don't want to trigger the same workflow for another event that you didn't intend to. Our idea was to use the Conditions to judge if this workflow would run or not, but...

We hit another roadblock; another issue was that when an event is triggered and conditions are to be evaluated, WordPress doesn't include in its payload the previous state of the fields, so if you want to do a "diff" (so you can tell which field values change) you then have to store the current state somewhere to be able to do such a "diff" to compare.

We then had two roads:

- Re-tool the core of WordPress with the functionality (with a lot of PHP hackery) that would enable us to run workflows the right way.

- Relying on the existing API and end up with the same feature set that Uncanny Automator plugin currently has.

So, instead of reinventing the wheel, we just dropped the idea.

I invite you to try it. We truly wanted this plugin to happen, we finally found a niche where there wouldn't be a zillion competitors, and we found out that WordPress's software design currently looks like it's been all hacked together.

This "hacked-together" situation is not their fault in the sense that they have lacked engineering. I'm sure Automattic has some world-class engineers there. However, their codebase lags by years because of their legacy users. From a business perspective, they are hands-tied because any breaking change will bring hate towards them.

Their userbase is too big to make any significant change, and Gutenberg already fragmented their ecosystem badly. They will need to create a new next-generation product from scratch, just like JetBrains does with Fleet instead of IDEA.

For a more technical answer, I already gave detail at: https://news.ycombinator.com/item?id=30185809

From Taleb's 2012 book _Antifragile: Things That Gain from Disorder_

> Every year that passes without extinction doubles the additional life expectancy. This is an indicator of some robustness. The robustness of an item is proportional to its life!

"The Lindy effect proposes the longer a period something has survived to exist or be used in the present, it is also likely to have a longer remaining life expectancy"

https://en.wikipedia.org/wiki/Lindy_effect

I have become convinced that words like “lightweight” and “fast” have lost all meaning in software circles. You’ll get two projects describing themselves in similar terms because they’re comparing themselves to wildly different things. (For example: Hexo and Zola both have a heading on their front pages titled “blazing fast”, but for equivalent loads Zola will be much faster than Hexo, probably a minimum of 5–10×, and Zola isn’t even particularly optimised, just written in Rust.)

The WordPress download is 20MB compressed, 63MB uncompressed, containing almost half a million lines of PHP spread across over a thousand files (~16MB; around 55% code, the remainder blank or comments), over half a million lines of JavaScript in over 500 files (~25MB; around 67% code), a couple of hundred thousand of CSS in 700 files (~7.5MB; around 75% code), and the odd spot of other languages. (This is in languages where more code fairly directly means slower, even if faster code can claw that back; whereas in compiled languages, more code just means slower compilation, and runtime performance is comparatively uncorrelated.)

That’s not particularly lightweight.

Conceptually WordPress isn’t lightweight, either. I’ve never used WordPress myself, but I’ve seen three people using it, and in each case they were being drowned in choices and data fields, using two or three fields out of the thirty or more fields it was shoving in their faces; and the themes and plugins and such made matters considerably worse and more complex; and a lot of that complexity didn’t seem well-structured, though my observation has only ever been brief.

Addendum to my previous comment (as an in-depth technical review):

Check out the source code of wp_insert_post() [0] on line 4407, you'll see three hooks that trigger: "edit_post_{$post->post_type}", 'edit_post' and 'post_updated').

Then after that, these other ones trigger unconditionally: "save_post_{$post->post_type}", 'save_post' and 'wp_insert_post'.

For the cherry on top: wp_after_insert_post() is called, with several other hooks on their own.

Try to evaluate each configured workflow whenever every one of these hooks triggers. Your WordPress installation will get slow in no time.

Somebody designed this function this way, and that design is inhibiting effective WordPress automation.

--

[0]: https://github.com/WordPress/wordpress-develop/blob/5.8.1/sr...