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.
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.
Yes, these are different hooks with different parameters, but these are triggered by the same function[0].
When the function is called, all of these hooks are triggered. To identify what the user was doing (post creation on the first time? post updated? is the status being updated?), unless you have many conditions (potentially nested ifs), it's a cumbersome job.
For example, a user wants a workflow every time the post is sent to the Trash. When a post is sent to the Trash, three things happen:
- A hook is triggered because it's sent to the Trash.
- The updated status one is also triggered (Published -> Trash).
- The Updated post one is also triggered, because yes, this is an update.
Yes, these are different hooks, but these do come from the same function. We tested two other plugins similar to ours and found minimal automation capabilities; we speculate this is because of the reasons I just exposed.
If you check out the source code for wp_insert_post(), you'll find many do_action(). When clicking the "Add Post" button, the post is created at that moment (so it can reserve the permalink, etc.); by the time you save the post for the first time, in reality, it's being updated, not saved for the first time as one would believe.
This is just a single example, but these software design decisions make it not that straightforward to create an automation plugin. By the way, that function calls many others inside, functions that trigger hooks by themselves; therefore, you'll have many workflows trigger attempts many times per second, just by saving the post.
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.