Pre-defined ticket applied to a new event

[Mikko Siikaniemi]

Hello, and thanks for the great plugin. I recently bought the pro version, and running full speed with the development.

My use case: a training calendar and registration system for a client. There will be two types of training (two event categories), taking places in various cities around the country. For those two types, there is a fixed training fee for each, i.e. for training type A the fee is always X euros and for type B fee is Y euros. The fee will be billed offline.

To make it as easy as possible for the client to add new trainings to the calendar, I’m thinking of a solution, where a pre-defined ticket — X or Y — would be applied to a new training. This would happen instead of the client manually adding a new ticket (identical to other tickets previously created for other events in the same category) to a new event every time. This pre-defined ticket could be based e.g. on the event category. In addition, there would be a default amount of spaces available, say 20.

I’m wondering what would be the easiest way of doing this? Assistance on building such a solution would be greatly appreciated. Should it happen on the wp-admin side or in the booking form template?

Thanks,
Mikko / Mikrogramma Design

[Stephen Harris]

You could hook onto when an event (post) is created, and automatically create event tickets for the user:

When any post is created the hook new_to_{status} is triggered. Typically the starting status of a post is auto-draft. In the following code, when that action is triggered, we create some tickets. (This does assume the default status is auto-draft – if this might not always be the case, there are other hooks you can use)

add_action( 'new_to_auto-draft', 'my_create_default_tickets' );
function my_create_default_tickets( $post ){
      if( get_post_type( $post ) !== 'event' ){
            return;
      }
      //Technically this is API is private. 
      //There are no guarantees of backwards compatability if changes are made, but
      //changes are unlikely, and will be announced.
      //Where possible, we will endeavour to ensure changes are backwards compatible.
    eventorganiser_insert_ticket( $post->ID, array(
        'name'           => 'My ticket',
        'spaces'         => 20,
        'price'          => 14.49,
        'occurrence_ids' => array(), //don't know this, see  Health Warning #2
        'from'           => false, //Or a DateTime object
        'to'             => false, //Or a DateTime object
        'order'          => 1, //optional, the order in which the tickets appear
      ));
}

Health Warning #1: See comments about backwards compatability.

Health Warning: #2: If you are selling tickets by ‘date’, since the event’s dates do not exist yet, it is impossible to specify the occurrence IDs for which this ticket is purchasable. The user will have to select these dates (or click ‘select all’) after they have created the dates. Alternatively, if you want to remove the user from ticket handling altogether, every time the event is saved, update the tickets to reflect the changes to the event.

The above code hasn’t been fully tested, but does ‘work’.

[Mikko Siikaniemi]

Thanks for your prompt reply, Stephen.

The code you provided does associate two new ticket types for a new event immediately on creation, which is great. The tickets do not appear for the user to select in the booking form, though. I believe this is due to health warning issue #2 you mentioned. For manually created tickets, the event ID is populated in the database (wp_postmeta table, _eo_tickets meta_key) for occurence_ids. For these auto-generated, the occurrence_ids is empty.

Now, I’m wondering how (and when) to get the event ID populated. What would be your advice and recommendation?

[Stephen Harris]

The tickets do not appear for the user to select in the booking form, though. I believe this is due to health warning issue #2 you mentioned. For manually created tickets, the event ID is populated in the database (wp_postmeta table, _eo_tickets meta_key) for occurence_ids. For these auto-generated, the occurrence_ids is empty.

Yes – it sounds like that when the dates are selected, they aren’t be selected for the tickets. With pre-defined tickets such as this, it’s understandably a frustration to have to edit them to select the dates. Instead, whenever the event is saved you can automatically update the tickets to reflect the event’s tickets. This will override the user’s selection, however.

add_action( 'eventorganiser_save_event', 'my_update_default_tickets', 20 );
function my_update_default_tickets( $event_id ){
     $occurrences = eo_get_the_occurrences_of( $event_id );
     $occurrence_ids = array_keys( $occurrences );
     $tickets = eo_get_event_tickets( $event_id );
     foreach( $tickets as $ticket_id => $ticket ){
             $ticket['occurrence_ids'] = $occurrence_ids;
             eventorganiser_update_ticket( $ticket_id, $ticket );
     }
}

I’ve used the hook eventorganiser_save_event – this is almost identical in purpose to the native save_post (except it only fires for events). The above isn’t tested, and you’ll probably want to do the usually permission, cron and auto-save checks that you do on save_post callbacks.

[Author]

Posts