Registration lifecycle hooks

The point to hook when a visitor registers for an event — most usefully, to send the confirmation email the plugin does not send.

The action

add_action( 'pom_events_ajax_on_event_signup', function ( $user_id, $event_id, $request, &$email_sent ) {
    // Runs after the registration has been stored on the event.
}, 10, 4 );

It fires after the registration is written to the event's attendee map, so at that point:

• the user exists — either matched by email or created;
• the registration is stored, with its status already decided;
• the visitor has not yet received the response.

The fourth parameter is passed by reference, so an integration can record that it has sent a message and cooperate with anything else listening.

The parameters

Sending a confirmation email

The single most common integration, because POM Events sends nothing:

add_action( 'pom_events_ajax_on_event_signup', function ( $user_id, $event_id, $request, &$email_sent ) {
    if ( $email_sent ) {
        return;
    }

    $user  = get_userdata( $user_id );
    $event = get_post( $event_id );

    if ( ! $user || ! $event ) {
        return;
    }

    $assistants = get_post_meta( $event_id, 'event_assistants', true );
    $status     = $assistants[ $user_id ]['status'] ?? '';

    $subject = 'waiting-list' === $status
        ? sprintf( __( 'You are on the waiting list for %s', 'my-plugin' ), $event->post_title )
        : sprintf( __( 'Your place at %s', 'my-plugin' ), $event->post_title );

    $sent = wp_mail( $user->user_email, $subject, my_plugin_build_body( $event, $status ) );

    $email_sent = $email_sent || $sent;
}, 10, 4 );

Two details worth copying: respect the flag so several integrations do not each send a message, and check the status so a wait-listed person does not receive a confirmation of a place they do not have.

Reading the stored status

The status is on the event, not in the request:

$assistants = get_post_meta( $event_id, 'event_assistants', true );
$status     = $assistants[ $user_id ]['status'] ?? ''; // '' | 'waiting-list'

An empty status means confirmed.

Other things to do here

• Notify the organizer that a registration arrived.
• Push to a CRM or a mailing list, subject to the consent you actually collected.
• Log the registration for your own reporting.
• Add the user to a role or group.

What not to do here

• Do not modify the registration to change its status. The waiting-list decision has already been made and the visitor is about to be told the result.
• Do not perform slow work. This runs inside the visitor's request; a slow remote call delays their confirmation. Queue it instead.
• Do not assume consent. The form's consent covers what your clause says it covers. Adding people to a marketing list needs its own basis.

The WooCommerce path does not fire this

A registration created by a purchase does not go through the form, so this action is not the hook for paid events. Use the WooCommerce order hooks instead — see WooCommerce integration hooks.

If you send confirmation emails, implement both paths or half your attendees will hear nothing.

Verify

1. Register from a private window and confirm your handler runs.
2. Confirm the status is read correctly for a confirmed registration.
3. Fill the event and register again; confirm the wait-listed branch is used.
4. Confirm the visitor still receives their on-screen response promptly.