Event Organiser Pro v3

Breaking changes

Below are the details of changes made in 3.0.0 which might require third-party code to be updated in order to continue to function correctly.

Minimum requirements

In line with WordPress 5.2 dropping support for PHP 5.2-5.5, Event Organiser Pro 3 will now require

• PHP 5.6 or higher, with PHP 7.1+ strongly recommended.
• WordPress 4.5+ with the REST API enabled (it is by default)

Booking / payment flow has changed.

No action required, accept to be aware of the changed booking / payment flow

Previously you created and paid for the booking in one-step (unless you were redirected to a payment gateway). Event Organiser Pro 3 removes the gateway fields. Instead, after you submit a booking, the booking form changes into a payment screen.

Behind the scenes the booking has been created with status ‘incomplete‘. Once the payment method has been selected and the user has chosen to pay, the booking is updated to ‘pending‘ until payment has been confirmed. Depending on the gateway this might happen instantly or after user has been redirected to the payment gateway website and completed the payment. Either way, once confirmed the user is to returned to a booking confirmation message or confirmation page.

If the booking is free, the payment method screen is skipped and the booking confirmation message is shown.

In Event Organiser 3, this is all handled through a RESTful interfaces, and not so tightly coupled to the booking form. In short, this means it is much easier to build you own interface (either on the web, or an app). Documentation will be made available in the OpenAPI Specification format.

Payment Gateways

Ensure payment gateways are up to date before updating to Pro 3

The following payment gateways will need to be updated before upgrading to Event Organiser Pro 3:

• Stripe (2.2.0)
• Ideal (1.1.0)
• Authorize.net (1.3.0)

If you are using a payment gateway not listed here, please get in touch before upgrading.

UI / CSS changes

Notices have changed styling, the styling for notices on existing booking forms will be lost. You can either add CSS changes for these yourself, or add the following classes in the Booking Form customiser: eo-booking-notice-error eo-booking-notice (for errors) and eo-booking-notice-info eo-booking-notice (for informational notices).

Errors on booking form are indicated by an appropriate error message next to the form, and errored-fields no longer have a red background. Credit card icons, and the spinner have also been updated.

Additional styling has been added to support the new payment and confirmation screens – it is strongly recommend you re-enable the plug-in stylesheets if you have disabled these in Event Organiser > Settings.

“You already have a booking for this event” notice removed

You can re-add this with the following field:

add_filter( 'eventorganiser_booking_form_form_display_notices', function($notices, $formView){
    if ( eo_user_has_bookings( get_current_user_id(), $formView->get_form()->get( 'event_id' ), 0, eo_get_reserved_booking_statuses() ) ) {
        $notices['prior-booking'] = esc_html__( 'You have already made a booking for this event.', 'eventorganiserp' );
    }
    return $notices;
}, 10, 2);

Disabling auto confirm free bookings

By default, bookings which are free are automatically confirmed. The previous method of disabling this behaviour will no longer work, going forward you will need to use the following line of code:

add_filter( 'eventorganiser_autoconfirm_free_bookings', '__return_false');

Custom booking fields (in code)

No action required unless you using adding fields through the API and have changed the field name

Any booking form fields which do not have the HTML field name beginning with "eventorganiser[booking]" will be ignored.

What’s impacted: Custom fields where the get_field_name() has been overridden. Unless you have any custom code on your site that is doing this, then these changes will not impact you. For example, the fields added via the form customiser will likely no need changing.

How to fix Ensure all fields have a name of the form eventorganiser[booking][myfieldname] or do not override the EO_Booking_Form_Element::get_field_name() method.

Functions & filters removed / deprecated

No action required unless you have custom code that is using any of the filters below

The following filters have been removed:

• eventorganiser_process_form
• eventorganiser_process_booking_form_submission
• eventorganiser_pre_gateway_booking_{$gateway}
• eventorganiser_pre_gateway_booking

These functions will be removed in a later version, so you should avoid using them.

• eventorganiser_register_gateway (function) – use \EventOrganiserPro\Gateway\Service::register_gateway
• eventorganiser_gateways (filter) use \EventOrganiserPro\Gateway\Service::register_gateway to add a gateway
• eventorganiser_enabled_gateways (filter) use \EventOrganiserPro\Gateway\Service::register_gateway to and implement EventOrganiserPro\Gateway\GatewayInterface
• eventorganiser_pro_get_booking_complete_message (filter) – no replacement, confirmation message uses the templates/eo-booking-form-confirmation.php template.

Emailing payment instructions

A reasonably common requirement is to send a email to the user after the user opts to pay ‘offline’. Previously, you would have done something as follows:

add_action('eventorganiser_pre_gateway_booking_offline', function($booking_id){
     $post_id = (int) eo_get_booking_meta( $booking_id, 'event_id' );
     $occurrence_id = (int) eo_get_booking_meta( $booking_id, 'occurrence_id' );
     $booking_amount = (int) eo_get_booking_meta( $booking_id, 'booking_amount' );
     $bookee_email = eo_get_booking_meta( $booking_id, 'bookee_email' );
     $template = eventorganiser_pro_get_option( 'email_template' );
     eventorganiser_mail( $bookee_email, "subject", "message", [], array(), $template );
});

As this hook is no longer in use, you need to use eventorganiser_offline_payment_initiatedaction which passes the EO_Booking object:

add_action('eventorganiser_offline_payment_initiated', function($booking){
     $bookable = $booking->get_bookable();
     $event_id = (int) $bookable->get_event_id();
     $occurrence_id = (int) $bookable->get_occurrence_id();
     $booking_amount = $booking->price();
     $template = eventorganiser_pro_get_option( 'email_template' );
     $bookee_email = $booking->get_bookee()->get_email();

     eventorganiser_mail( $bookee_email, "subject", "message", [], array(), $template );
});

Stripe gateway

No action required unless you have custom code using eventorganiser_stripe_create_charge filter

From Event Organiser Pro 3, the filter eventorganiser_stripe_create_charge will no longer be used. Instead, you should use the filter eventorganiser_stripe_create_payment_intent which passed the payment intent array and the EO_Booking instance.

For instance, currently you might use the filter as shown:

add_filter('eventorganiser_stripe_create_charge', function($charge, $booking_id){
    $event_id = eo_get_booking_meta( $booking_id, 'event_id', true );
    $charge['metadata'] = isset($charge['metadata']) ? $charge['metadata'] : array();

    $charge['metadata']['eventname'] = get_the_title($event_id);
    $charge['metadata']['bookee_fname'] = eo_get_booking_meta( $booking_id, 'bookee_first_name', true );
    $charge['metadata']['bookee_lname'] = eo_get_booking_meta( $booking_id, 'bookee_last_name', true );

    return $charge;
}, 10, 2 );

To make this compatible for Pro 3 then you should add:

add_filter('eventorganiser_stripe_create_payment_intent', function($intent, $booking){
    $bookee = $booking->get_bookee();
    $bookable = $booking->get_bookable();
    $event_id = (int) $bookable->get_event_id();

    $intent['metadata']['eventname'] = get_the_title($event_id);
    $intent['metadata']['bookee_fname'] = $bookee->get_first_name();
    $intent['metadata']['bookee_lname'] = $bookee->get_last_name();

    return $intent;
}, 10, 2 );

Although this relates to a change in the Stripe extension, it is only required when updating to Event Organiser Pro 3.

Minor interface changes

No action required unless you have custom code

EO_Money

• EO_Money::get_amount_in_base_unit has been renamed to to EO_Money::get_amount_in_fractional_unit

Registering currencies

When registering an new currency, you should provide the fractional_units_in_standard property. This specifies the number of fractional currency units make up the standard unit (e.g. there are 100 cents in a dollar). For zero-decimal currencies such as the South Korean Won, these number would be 1.

add_filter( 'eventorganiser_currencies', function($currencies){
    $currencies['KRW'] = array(
        'name' => 'KRW - South Korean Won',
        'symbol' => '₩',
        'symbol_html' => '₩',
        'fractional_units_in_standard' => 1,
    );
    return $currencies;
 });

Supplying this is optional, but ensures that amounts are formatted correctly, and is necessary when using some payment gateways such as Stripe.