Overview
The {trigger} macro listens for Events, then, after filtering and confirming any prerequisite requirements, performs the actions contained in the macro body.
Where to use it?
Optional.
One or more {trigger} macros can be put in a {workflow} macro.
Must be placed after the {state} macro(s).
Parameters
Parameter | Required | Default | Notes | Ver |
|---|---|---|---|---|
unnamed first parameter |
|
| The event to listen to – see: Events | |
| macro body | One or more actions to process when the trigger is activated – see: Actions | |||
description | The description for the trigger:
| 5.7+ | ||
| Optionally apply further conditions to filter events – see: Conditions | |||
|
|
Filter to a specific Tip: If you have more than one {approval} with same name, you can also filter to a specific {state} using the
| ||
|
| Only applies to
The primary use of this parameter is to perform one-time initialisation actions for a given piece of content. For example, on the first review of a piece of content you might want to send out additional emails, or set some metadata.
Content by label
There is no content with the specified labels | 3.0.1+ | |
|
| Only applies to The name of the label which was added or removed.
| ||
|
| If this value is set, then a custom event identified by this value will be published when the actions are executed, and will contain a flag
| ||
parameter |  | |||
|
| Only applicable to for the following events:
| ||
|
| Should actions be queued?
If there is a chance that actions will take a long time to process, for example when remote publishing content, they should be queued so the end user doesn't have to wait for them to finish before continuing with thier work.
| ||
|
|
|
Filter to a specific active {state} of the workflow. Note: Only a single state can be specified, and it can't be negated.
| |
|
| This setting is used to listen for the outcome of a custom event (set by the
| ||
|
|
|
Filter to a specific
Content by label
There is no content with the specified labels | 3.2.5 |
Example
{workflow:Example trigger}
{state:Editing|submit=Review}
{state}
{state:Review|approved=Published|rejected=Editing}
{approval:Review}
{state}
{state:Published|final=true|updated=Editing}
{state}
{trigger:pageapproved|approval=Review}
{set-message:style=success}This page has been approved!{set-message}
{trigger}
{trigger:pagerejected|approval=Review}
{set-message:style=error}This page was rejected, please make requested changes.{set-message}
{trigger}
{workflow}
All examples
-
-
Adding page activity to email — Include page activity report, or a link to it, in email notifications
-
-
-
Attachment events — Triggering events when attachments are created, updated or removed.
-
Blog Post Events — Workflow events associated with blog posts
-
Fast-tracked Rejections — How to require everyone to Approve, but only need one person to Reject
-
Message notification styles — Test the
styleparameter of the{set-message}macro -
Require Parameters on State Transitions — Require workflow parameter values to be set before moving into a workflow state.
-
-
State expiry dates — Using state expiry dates, defining them with metadata, and making them editable
-
-
Template Comments — Examples of where the
{comment}macro can be used in your template markup. -
Transitions — Transitions create the routes between states
