Max qty per person per ticket
WordPress Event Management, Calendars & Registration › Forums › Request A Feature › Max qty per person per ticket
This topic contains 5 replies, has 2 voices, and was last updated by Stephen Harris 10 years, 1 month ago.
-
AuthorPosts
-
November 3, 2014 at 8:00 am #13347
Hi again Stephen!
I’m using Event Organiser Pro and wordpress as backend for a SPA. I’m requesting a counter on each ticket in the create event area for setting the max quantity allowed per ticket per person. I wan’t to be able to for example set a ticket type for a member and a ticket for non-members. In that case I want to be able to set a max qty on 1 for members and 4 for non-members.
Maybe you’re not going to implement it, but somehow there would be great if there was an easy way to hook into the add-ticket area. I think that there may be interest to add checkboxes and other meta-data information on a per-ticket basis.
Best regards,
HenningHenning AlesundNovember 6, 2014 at 11:12 pm #13420Hello Henning,
I’m sorry I haven’t replied this thread sooner. To confirm you want to be able to limit the number of tickets of a particular type that someone can purchase in a booking. (E.g. each booking can contain at most 1 member ticket and 4 non-member tickets)?
It is possible to add additionally fields to the ticket admin (and I’ll follow up in a day or two with the appropriate code to do that) but this probably won’t be a feature built into core as it will appeal would be quite limited.
Alternatively if all the tickets were going to be “member” or “non-member” then it would be possible to limit the number of tickets in a booking based on the name of the ticket – if that would be suitable and easier for you?
Stephen HarrisNovember 7, 2014 at 7:21 am #13422Hi!
Yes, exaclty. It’s about limit the ticket quantity each registered user are allowed to buy. In fact, it would be as great to be able to add extra custom input fields on each new ticket. It would be great with an example on the ticket admin code if you have time!
And I have thought about setting limit in the name, but it is always nicer to be able to build robust code and let the editors chose their preferred name on the ticket. I could of course add extra info on the name and then strip it on next load, but that is a last resort.
Best regards,
HenningHenning AlesundNovember 9, 2014 at 1:14 am #13440Hi Henning,
Yes I agree – avoiding using the name is best, particularly as it protects from incorrectly spelt ticket names.
To add an additional field to the ticket edit metabox is not entirely straightforward, but I outline this below. The following is not well documented as it’s early in development and may change.
1. First register the ticket ‘property’
When a ticket is updated/created it’s properties are ‘white listed’, so any added data would be lost unless you do the following.function my_add_key_to_ticket( $ticket, $event_id, $_ticket ){ $ticket['is_member'] = $_ticket['is_member']; return $ticket; } add_filter( 'eventorganiser_update_event_ticket', 'my_add_key_to_ticket', 10, 3 ); add_filter( 'eventorganiser_insert_event_ticket', 'my_add_key_to_ticket', 10, 3 );
2. Enqueue your script on the event edit page
The ticket metabox itself is powered by underscore. As such the majority of the work lives in a javascript file which you’ll need to create and enqueue with the following:function my_ticket_field_enqueue_script(){ $screen = get_current_screen(); if( $screen->id != 'event' ){ return; } wp_enqueue_script( 'my_ticket_script', '... url to javascript ...' ); } add_action( 'admin_footer', 'my_add_key_to_ticket' );
3. Add the field to the ticket row (backbone) template
function my_is_membership_ticket_field(){ ?> <tr data-eo-ticket-option="is-member"> <th> <?php esc_html_e('Is memberiship ticket:', 'eventorganiserp' );?> </th> <td class="is-member"> <input type="checkbox" value="1" name="eventorganiser_pro[ticket][<%- cid %>][is_member] <% if( is_member ){ %>checked="checked"<% } %>/> </td> </tr> <?php } add_action( 'eventorganiser_ticket_options_after', 'my_is_membership_ticket_field', 15 );
This basically creates the HTML mark-up for each row, with placeholders in a couple of places which are populated by Backbone. In particular:
<%- cid %>
is the unique client-side ID of the ticket.<% if( is_member ){ %>...
– checks if the ticket is a membership ticket. The value ofis_member
is set appropriately, but will be updated by our script whenver the user changes it (see ticket below). Please note that the variable nameis_member
also appears as in the name field of our<input>
and is also the ‘key’ we registered earlier in step 1.
4. The JavaScript file
This is fairly simple – the all the script needs to do is to listen to when the checkbox is clicked and update the ticket as appropriate.
(function($) { var ticketManager = eo.tm || {}; //When the checkbox is checked, update ticket model var ticketViewEvents = ticketManager.View.EOTicketView.prototype.events; ticketManager.View.EOTicketView = ticketManager.View.EOTicketView.extend({ events: function(){ return _.extend({},ticketViewEvents,{ 'change .is-member input': 'updateTicketIsMember', }); }, updateTicketIsMember: function( ev ){ $( ev.target ).prop('checked') ? this.model.set( 'is_member', 1 ) : this.model.set( 'is_member', 0 ); }, }); })(jQuery);
Stephen HarrisNovember 10, 2014 at 7:36 am #13450Thank you for the wonderful support! I will implement it in the next few weeks and report back to you if I get any trouble!
Henning AlesundNovember 10, 2014 at 11:54 am #13459You’re welcome. The above code is altered from a membership integration extension (with Restrict Content Pro) which is currently in development. So the above hasn’t been tested, but is based on code which is ‘working’.
You may be interested in it (the aim is the extension will be able to integrate with a number of popular membership plug-ins) but as of yet there is no time frame for its release.
Stephen Harris -
AuthorPosts