Built in triggers

Post triggers #

TriggerDescription
Post / CreatedThis trigger fires when a post object (post, page, custom post type etc.) is first created. Note that at this stage the post will most likely be in a draft status. Setting a trigger at creation might be too early for many workflows.
Post / PendingThis trigger fires when the status of a post object (post, page, custom post type etc.) is changed from any other status to status = pending.
Post / PublishedThis trigger fires when the status of a post object (post, page, custom post type etc.) is changed to published.
Post / PrivatizedThis trigger fires when the status of a post object (post, page, custom post type etc.) is changed to private.
Post / TrashedThis trigger fires when the status of a post object (post, page, custom post type etc.) is changed to trash.
Post / status changedThis trigger fires when the status of a post object (post, page, custom post type etc.) is changed to a new status
Post / SavedThis trigger fires when a post object (post, page, custom post type etc.) is saved. Note! WordPress stores a lot of data as posts which means this trigger will fire often. Make sure to use strict filters, typically including “post type” to make sure your actions only run when you expect them to.

Note that the post object in WordPress are used for many other things than just traditional blog posts or pages. Whenever you use a post trigger, make sure to use the “Post Type” filter to make sure your workflow are only executing actions on the post types you intended.

Post triggers provides the following objects:

ObjectDescription
postThe post that had was updated / saved / trashed etc.
userThe owner of the post

User triggers #

TriggerDescription
User / CreatedThis trigger fires when a user account is created.
User / LoginThis trigger fires when a user logs in
User / Profile updatedThis trigger fires when a user profile is updated
User / Role changedThis trigger fires when a users role is changed

User triggers provide the following objects

ObjectDescription
userThe user that was created / updated or logged in

Comment triggers #

TriggerDescription
Comment / Submitted

This trigger fires when a new comment is submitted
Comment / ApprovedThis trigger fires when a comment is approved
Comment / Status changedThis trigger fires when the status of a comment is changed

Comment triggers provide the following objects

ObjectDescription
commentThe comment that was submitted / approved etc
postThe post that the comment is attached to. For a normal comment, this is the blog post or page. For a WooCommerce order note, this is the actual order

Confirmation link triggers #

The confirmation link triggers all work the same, the only real difference between them is the object types they provide to the rest of the workflow. The type of trigger is really determined when the confirmation link is created and that in turn depends on the confirmation link parameter that was used. The main reason to differentiate between different types of confirmation link triggers is to make the workflow editor UI aware of which filters and parameters that will work.

TriggerDescription
Confirmation link / PostProvides a Post object (main) and a user object
Confirmation link / OrderProvides a (WooCommerce) order object

WooCommerce order triggers #

TriggerDescription
Order / CreatedThis trigger fires when an order is first created and is assigned an id. Note that at this stage the order is still editable regarding order items, payment method, payment status, fees etc. Setting a trigger at creation might be too early for many workflows.
Order / On hold
This trigger fires when an order status is changed to on-hold
Order / PendingThis trigger fires when an order status is changed to wc-pending.
Order / ProcessingThis trigger fires when an order status is changed to wc-processing, meaning that payment is secured but before the order is marked as complete. Note that in some setups, i.e via the plugin ‘ WooCommerce Order Status Control’, order status may change directly from pending to completed which means that this trigger will never fire. If that is the case in your setup, consider using the trigger ‘Order Paid ‘ instead.
Order / PaidThis trigger fires when an order is paid, meaning that the actual order status is changed from a non paid status (new, on-hold, pending etc.) to a paid status (processing or completed).
Order / CompletedThis trigger fires when an order status is changed to completed. This normally happens after payment is secured and the store owner then manually sets the status from processing to completed.
Order / CancelledThis trigger fires when an order status is cancelled and status is changed to wc-cancelled
Order / FailedThis trigger fires when an order failed and the status is set to wc-failed.
Order / RefundedThis trigger fires when an order status is refunded and status is set to wc-refunded
Order / SavedThis trigger fires an order is saved (updated). Note that during the life cycle of an order, this trigger will fire multiple times, for instance every time the status changes.

Order triggers provide the following objects

ObjectDescription
orderThe order that was updated / saved / had a status change

Order Note trigger #

TriggerDescription
Order Note SubmittedFires when a new order note is added to an order

Please note that many order notes are created automatically as part of the order management process. Besides the order notes for status changes most payment gateways also add order notes. The only real way to filter different automatic order notes from manually written notes is to filter on the content of the note.

Order note triggers provide the following objects

ObjectDescription
commentThe order note is actually a WordPress comment object, so the order note is provided in the form of a comment.
orderThe order that the note was added to

Powered by BetterDocs

Leave a Reply

Your email address will not be published. Required fields are marked *