Event Organiser Pro allows you to add additional fields to your booking form. You can use this to collect additional information about the bookee.
Sometimes you’ll want to display this information in the confirmation e-mail (or indeed or other e-mails to the bookee). Event Organiser allows you to use the %form_submission% tag in e-mail messages (see e-mailing bookees, and confirmation e-mail option) to list the additional information collected from the user when they placed their booking.
Sometimes however, you may wish to use this information inside the body of text. It would be convenient if, for instance, the tag %booking_field id=12% were recognised by the plug-in and replaced by the information entered by the user (for the form field with ID 12). This is what the snippet below does.
//Register the placeholder
EO_Email_Template_Tag_Registry::register( 'booking_field', 'booking_field_placeholder_callack' );
//Define the callback for this placeholder
function booking_field_placeholder_callack( $tag, $atts, $context ){
//$tag is 'booking_field'
//$atts is an array of attributes used with the tag, e.g. id
//$context is an array indexed by 'booking_id', 'event_id', 'occurrence_id' etc. with
//appropriate values for the context of the e-mail.
$custom_field_id = $atts['id'];
$value = eo_get_booking_meta( $context['booking_id'], 'meta_'.$custom_field_id, true );
return $value;
}
Why is this not in core?
While this is can be very useful for some, it’s not the most practical solution: If you have a development, staging and production environments it’s possible that the ID of the fields may be different in each one. As a result, you would need to change the ID given in %booking_field id=X% appropriately in each environment – not exactly ideal.
Worse still, if you are building a site for a client, you need to tell that client not to remove the field. If they remove the field with ID 12, then %booking_field id=12% would have to be removed/updated as well. If the client isn’t aware of these things, or not comfortable making any such changes, then you may end up creating work for yourself.
In short the reason this isn’t in core is because we’re holding out for something better, and more user (and developer) friendly (and we’re looking at options). But for the time being, you are more than welcome to make use of the above snippet.
As with all snippets on this site, the best place to use it is in a site utility plug-in (although it will work in functions.php as well). See Where should I put code from the tutorials?.