Event Organiser Pro 1.6 has just been released. It contains a few major feature enhancements, as well as fixes for a number of minor bugs. Here’s a breakdown of this latest release:
Booking Status API
With 1.6 you can now create custom booking statuses to allow you to better organise or track the progress of your bookings. For example, you may wish to create a booking status to indicate that a confirmed booking has had its tickets dispatched to the bookee’s address, or that an unconfirmed booking has had a reminder sent.
The booking status API allows you to register addition booking statuses, and indicate whether bookings of that status should have tickets reserved and whether the booking should be deemed ‘confirmed’.
add_action( 'init', 'my_custom_booking_status_register', 500 );
function my_custom_booking_status_register(){
eo_register_booking_status( 'deposit-paid', array(
'label' => 'Deposit paid',
'reserve_spaces' => true,
'include_in_confirmed' => false,
));
eo_register_booking_status( 'tickets-sent', array(
'label' => 'Tickets sent',
'reserve_spaces' => true,
'include_in_confirmed' => true,
'show_in_admin_status_list' => true,
'show_in_admin_all_list' => true,
));
}Documentation for the eo_register_booking_status() function can be found here.
What’s the difference between ‘reserved’ and ‘confirmed’ bookings?
The difference is mainly semantic: both reserved and confirmed bookings effectively reduce the number of tickets available to prevent over-booking. But ‘confirmed’ usually indicates payment has been made, while ‘reserved’ indicates that the booking is awaiting payment or might possibly be withdrawn. The plug-in treats them differently in two ways: e-mails are only sent out once bookings have been confirmed. In the bookings admin screen and the admin calendar you can view the number of confirmed attendees – this doesn’t not count reserved bookings.
Cancelled bookings can be retrieved
From 1.6 onwards, cancelling a booking no longer permanently deletes it, and the booking can be restored to its previous status. To view any cancelled bookings click the ‘cancelled’ filter at the top of the bookings page. To restore them click the appropriate bookings and select ‘Restore bookings’ from the bulk actions menu.
Cancelled bookings are not automatically deleted. Bookings where the user aborts payment at the checkout are not set as cancelled, but will remain as pending.
Booking CSV export options
Additional options setting the delimiters used in the CSV file have been added. The aim here is to provide a greater degree of flexibility in the format the file takes, making compatibility with various CSV readers much easier.
Javascript checkout API improved
This change is almost entirely under the hood, and won’t be noticeable. But with recent extensions such as VAT and discount codes, this API overhaul aims to make extending booking form interaction a lot easier. There are some exiting plans for seat allocation extension which will integrate with Seats.io.
This latest update is still compatible with the VAT and discount codes extensions
Improving ticket selection
For recurring events, when selling tickets ‘by date’, the user has to select which occurrence they wish to purchase tickets for. Inconveniently, however, the date picker used for this opened on the current day’s date irrespective of the event’s dates. In 1.6 the datepicker opens on the next available date of the occurrence, and automatically pre-selects this date.
With the new ‘checkout API’ you can change the pre-selected date. In the example below it is set to the occurrence with ID given by the url (e.g. mysite.com/events/event/my-event?oid=[occurrence ID]):
function my_preselect_date_script(){
$occurrence_id = !empty( $_GET['oid'] ) ? (int) $_GET['oid'] : false;
if( $occurrence_id ){
?>
<script>
jQuery(document).ready(function($) {
var occurrence_id = parseInt( <?php echo $occurrence_id; ?>, 10 );
eventorganiserpro.eoCart.get('event').set_occurrence( occurrence_id );
});
</script>
<?php
}
}
add_action('wp_footer', 'my_preselect_date_script', 500 ); However, if an event has only a few, widely spaced dates – a datepicker can still be slightly inconvenient to use. For this reason, 1.6 adds an option to switch from a datepicker to a standard select box. You can toggle this by clicking the “Ticket picker” and selecting “Use drop-down list”:
Minor tweaks to the booking form styling
There’s been a few alterations to the styling applied to the booking form. These all very minor, including fixing some conflicts which may occur with themes using a common ‘reset’ styling (used to remove default styling applied by browsers). The labels of booking forms have also been given display:block and the <br> tags removed.
In the unlikely event that this disrupts the layout of the form you may wish to try adding the following to your theme’s style.css (note, not all attributes may be required):
.eo-booking-label{
display:block;
float:none;
clear:both;
width: 100%;
}Improved performance
The front-end stylesheet has been linted, condensed and then the compressed version used for live sites. It’s a minor change, but a very welcome one! The original (uncompressed) CSS file is included for ease of development.
As with Event Organiser, uncompressed scripts and stylesheets are used when SCRIPT_DEBUG or WP_DEBUG is set to true, to aid with debugging.
“No gateway enabled” error message
Currently if you create an event with some non-free tickets, but neglect to enable any of the payment gateways the booking form does not appear. In 1.6 admins will see an error message where the form would appear explaining this. The error does not appear to non-admins.
Of course, if your tickets are free you do not need to enable any gateway.
Form details included in admin notification emails
The “Bookings” options for Event Organiser Pro allow you to opt-in to e-mail notifications when a booking is made or confirmed (or both). That e-mail now contains a table with all the data collected from the booking form, including any custom fields added.
This table is the same table that is produced in emails to the bookee when you use the %form_submission% tag (since 1.5).
Fieldsets
1.6 brings with it an additional booking form component: the fieldset. Fieldsets are used to group form elements together, and you can optionally provide a label for that group. They can be added like any other form component, and the fieldset wraps around all the following form components before the next fieldset component (or to the end of the form if it is the last one).
Here’s an example of a booking form using fieldsets (form customiser and front-end view) and the TwentyThirteen theme:
Unit Tests
1.6 marks the largest number of unit tests added to Pro since unit tests were initially added. While these tests are not distributed with the plug-in, they help to keep each release as stable as possible. They even helped identify a couple of existing (and fairly obscure) bugs which were subsequently fixed for this released.
Various bug fixes
Various minor bugs have been addressed in this update. Including a bug with the postcode and state components of the ‘address’ form field remaining visible regardless of form field options. Other fixes included:
- conflicts with the TwentyFourteen theme
- ‘from’ addresses on emails sent to bookees
- a bug with event/venue proximity queries on installs with the non-default database prefix.