Skip to content

Creating a New Thrive Automator Action

popmihaiadr edited this page Aug 14, 2021 · 8 revisions

In this article, we'll guide you through the steps required for creating a new Action in Thrive Automator. We'll implement a simple action that will issue a POST request to an external URL. The POSTed data will contain a user email. Thus, the action can be bound to any trigger that exposes a user email ( for example: form submissions, login/register, etc.)

Pre-requisites

  • make sure you have the Thrive Automator plugin installed and activated

Creating and registering the action

An Automator Action has to be implemented as a class extending Thrive\Automator\Items\Action_Abstract. We create a new class that extends Automator's Thrive\Automator\Items\Action_Abstract. See the full implementation here

A couple of things to note here:

  • each action must have a unique ID (as a best practice, you should always prefix it; in our example, the prefix is thrive-automator-docs/)
  • each action must have a name, description, etc - these are used in the admin UI - users will see your action name
  • action image - to be clarified
  • each action has a list of required data (property $requires) - this is a list of data keys - see the article on the types of data available in Automator - currently Automator exposes user_data and form_data data objects - more details here
  • when users will choose our action, we have to allow them to configure a URL where the action will send the POST request - we'll call this the Webhook URL - this is declared in the $fields property. To achieve this, Automator exposes another integration, Action fields - see below

Creating and registering the Webhook URL action field

Implementing the action field is as simple as it is for the action - you just need to extend Automator's Thrive\Automator\Items\Action_Field_Abstract class and implement the abstract methods. The full working example from this tutorial is available here

  • our field's id is webhook_url:
	public static function get_id() {
		return 'webhook_url';
	}
  • type of the field is text - a simple text input where users will configure the webhook URL
	public static function get_type() {
		return static::FIELD_TYPE_TEXT;
	}

Putting it all together

All Automator integrations must be registered during the thrive_automator_init hook. In our main plugin file, we'll hook into the thrive_automator_init hook and register our action and our action field:

add_action( 'thrive_automator_init', static function () {
	thrive_automator_register_action_field( new \AutomatorExamples\Actions\Fields\Url() );
	thrive_automator_register_action( new \AutomatorExamples\Actions\Webhook() );
} );

Executing the action - send request to webhook URL

Everything happens in the public function do_action( $data ) method from the action class.

  • $data is an array that will contain the actual data provided by the trigger - it will have the exact same keys as defined by the action's $requires property - and each item in the array is a data object of that type.
  • the action instance is already pre-populated with the configured webhook URL - accessible via $this->get_data( $field = null ) method
  • the actual action implementation is quite straight-forward, the code sample below illustrates the simplicity of putting it all together once everything is setup correctly:
	public function do_action( $data ) {
		/** @var User_Data $user_data */
		$user_data   = $data['user_data'] ?? null; // take the User_Data object exposed by the trigger
		$webhook_url = $this->get_data( 'webhook_url' )['value'] ?? null; // take the value of the webhook URL configured by the user
		if ( $user_data && $webhook_url ) { // if everything seems right, send the request using WordPress's `wp_remote_post()` function
			$args = [
				'headers' => [
					'User-Agent' => 'Thrive-Automator-Webhook',
				],
				'body'    => [
					'user_email' => $user_data->get_value( 'user_email' ),
				],
			];

			wp_remote_post( $webhook_url, $args );
		}
	}

While this is a really simple webhook implementation, it can easily be extended to add authentication for the API request, additional fields etc