Objects ​

Put simply, WunderAutomation objects represent different things in WordPress that a workflow can interact with and provides access to various properties that they have.

These "things" can be a WooCommerce order, a WordPress post or the data content of an incoming webhook.

The "interactions" are when filters and actions use these objects to filter the execution flow, to use object properties, i.e. the title of a post when sending out an email or updating them using i.e. using the Change status action.

Using objects ​

Perhaps the easiest way to explain what objects are is to give a few examples of how they can be used. Once an object has been added to the runtime context of a workflow, they become accessible to filters and actions in the workflow editor.

Here a Post object is being used in a filter that uses the post type to determine if the workflow steps should continue or not:

Here's the billing email address of a WooCommerce Order object used as a parameter when sending out a plain text email:

...and here's an example of using the parameter editor to retrieve the user registration date, with 10 days added to it, using the ISO YYYY-MM-DD date format:

Types of objects ​

Standard objects ​

A standard object is an object that represents things that a user creates and saves to the WordPress database. This includes things like a blog post, a page, a user a WooCommerce order or a BuddyPress group.

They could also be described as "tangible", something you can create, edit or delete on the WordPress admin panel.

Transient objects ​

The other type of object that WunderAutomation handles is a transient object. A transient object typically only lives for a short while during a single web request.

An incoming webhook or a contact form posted from the website's front-end pages are typical examples of transient objects.

Standard vs transients objects ​

When creating or editing a WunderAutomation workflow there isn't a huge difference between standard objects and transient objects. You can use them in filters and actions pretty much the same way. One important difference is that transient objects are normally not available when a workflow is running delayed.

Multiple objects of the same type ​

The standard way of naming objects is that when a trigger adds a post object, it will also get the name **post ** in the workflow. When you select your workflow trigger at the top of the workflow editor, the name of each object that the trigger adds will be displayed along with a short description of that object. This is what the Save Post trigger displays:

When you add another object of the same type, it obviously can't have the same name so you need to be careful when naming manually added objects to the runtime context.