Script Resources

My Tickets enqueues a small number of useful scripts you can take advantage of in your theme or custom extension to My Tickets. One that’s particular useful if you’re writing a custom payment gateway is jQuery Payments, the jQuery plug-in by Stripe for validating and handling credit card payment information.

Additionally, the AJAX actions used by My Tickets to add, remove, and update the shopping cart have hooks usable to handle custom actions during shopping cart updates. See the filters and actions reference for more assistance with My Tickets’ filters and actions.

Custom CSS

My Tickets provides relatively sparse default styles. These styles are intended to do the minimum necessary to make My Tickets usable, and reasonably attractive as long as the theme doesn’t impose too many changes.

My Tickets is intended to be customized. You can add your own styles through your theme, but it’s also very easy to override all of My Tickets default CSS. If you add a stylesheet called ‘mt-cart.css’ into a directory in your theme called ‘css’, that stylesheet will be used in place of the default My Tickets stylesheet.

Because the CSS used by My Tickets is designed to be overridden, there’s a very good chance that much of the styles will be overridden by various characteristics of your theme. This is intentional, to keep My Tickets light-weight and easy to modify, but does have consequences if you don’t have the knowledge or experience to customize stylesheets.

Customizing CSS is outside what is provided as support for My Tickets, but if you need assistance, you can submit a support request to hire Joe Dolson Accessible Web Design for customization tasks or to point you towards a developer who can help you.

Custom Field API

If you’re selling tickets, it’s not uncommon that you’ll need to gather some form of custom information. Do you need your customers to check a box verifying that they’re over 18? Do you need to get a phone number for each event? Find out which meal a customer would prefer for lunch?

My Tickets supports a custom field API that can add a custom field into the “Add to Cart” form. What it does is largely up to you; but it’s very easy to write a basic extension to collect custom data for an event.

Custom fields are added using the filter ‘mt_custom_fields‘.

In the filter, all you need to do is add an array of data to the custom fields array that passes the label for your custom field, a sanitization callback function, a display callback function, an input type, a set of values to choose from, and a context.

Any of these values can be omitted except for the label.

If you only provide a label, you will create a text input field with no default value. It’ll be sanitized using esc_sql and strip_tags. The display callback will call esc_attr and stripslashes on the value for display. When you create a callback, your callback gets two arguments: the data value itself, and the context it’s shown in. That will either by ‘cart’, for the shopping cart or add to cart context, or ‘payment’, if it’s being shown in the admin.

Supported input types include all the basic inputs, but do not currently include an upload field or other media selection method.

The context for the field defaults to ‘global’, but you can also pass a specific event ID or an array of event IDs. This rule defines where the custom field will show up – with ‘global’, it’ll show up on all add to cart forms. To create custom rules for displaying custom fields, use the ‘mt_apply_custom_field_rules‘ filter.

Example Implementation

add_filter( 'mt_custom_fields', 'create_custom_fields', 10, 1 );
function create_custom_fields( $array ) {
	// Other fields: sanitize callback; input type; input values; display_callback
	$array['test_event_data'] = array( 
		'title'=>"Meal preference", 
		'sanitize_callback'=>'sanitize_callback', 
		'display_callback'=>'display_callback',
		'input_type'=>'select',
		'input_values'=>array( 'Chicken', 'Salad', 'Doughnut' ),
		'context'=> 'global'
	);
	return $array;
}

/* Display callback formats the saved data. $context is 'payment' or 'cart', depending on whether it appears in an admin payment or the user's shopping cart. */
function display_callback( $data, $context='payment' ) {
	return urldecode( $data );
}

/* Sanitize callback cleans the data before saving to the DB */
function sanitize_callback( $data ) {
	return esc_sql( $data );
}

Adding a custom field will also automatically add this data into the Payments reports and will create a template tag so you can use the custom field in your automatic response emails.

Will-call lists

If you’re selling tickets by multiple methods, or you like to offer the option to your attendees to simply be checked off on a list or pick up their tickets at the event, then you’ll find a will-call list to be valuable.

My Tickets can produce two different types of will-call lists, both produced by the My Tickets “Reports” screen. The first list is a list of ticket purchasers. This list shows each person who has purchased tickets, along with the types and number of tickets they purchased. If they purchased two different types of tickets (Adult and Child, for example), then they will appear on the list twice, once for each type of ticket.

The second type of will-call list is a list of tickets. This list will show all tickets registered for this event, with the purchaser name, purchase ID, ticket type and ticket price. In this case, the purchaser’s name will appear on the list as many times as the number of tickets they purchased – if they purchased 8 tickets, they will appear on the list 8 times.

Which list is best for you really depends on how your purchasers tend to buy tickets, and which type of event you run.

Printable and E-tickets

A printable ticket

Printable and E-tickets are fundamentally the same, but the templates are substantially different; e-tickets are designed for use on a mobile device, in particular. Both types of tickets use QR codes for validation, and you can use any QR scanning device (mobile phone app, iPad, etc.) to scan the QR code and go to the validation URL for that ticket.

If you want the ticket to be marked internally as used, you’ll need to be logged in within your QR scanning device. Many QR code scanning applications provide the ability to open the scanned URL in a browser of your choice, but this is not available in all applications. I’ve had success using the Scan.me app for iOS and Android.

Ticket verified on a mobile device.The validation URL for the ticket will show the name, date, and time of the event, so you can verify that the ticket is for the current event. It will also indicate whether the ticket is verified; if it is, it will show a message saying “Ticket Verified“.

If the ticket is a valid ticket, but has already been checked by a ticket taker who is logged-in to the site and has the ‘mt-verify-ticket’ capability, the message will also indicate that the ticket has been used. Tickets are only registered as having been used if the ticket taker is logged-into your web site and has the correct permissions. By default, only administrators have the capability, but you can assign it to any user.

You can assign capabilities on a user-by-user basis in their user profiles. Only administrators can assign capabilities.

If the ticket ID was not valid, the message displayed will be “Not a valid ticket ID“.

You can customize the tickets using standard WordPress templating methods. My Tickets load a template called ‘tickets.php’ for use as the tickets template; if you place a file by that name in your theme directory, that template will be used in place of My Ticket’s default template.

Payments List

The payments list (WordPress Dashboard > Payments) is a pretty straightforward custom post type screen with a few key changes.

First, the screen includes the status of the payment, the total value of that shopping cart, and the receipt ID for the cart. Receipt IDs are generated very early on in the process, so even unsubmitted carts will have a receipt ID assigned already.

Carts that have been created but not submitted for payment will be labeled as “Active Cart” in the list. These will usually linger until they’re completed; My Tickets doesn’t currently automatically clear out old data. However, all active carts also have the “draft” post status, so you can view a list of all active carts by viewing the draft payments.

Display of payments screen.

Payments can have one of four statuses: Completed, for payments that are paid and processed; Pending, for payments still awaiting payment, Failed for any payments where the payment was attempted, but failed, and Refunded, if you’ve refunded the payment.

You can filter the screen to show only payments with one of these statuses, for easier navigation. If you have a large volume of pending payments to mark as completed, you can do that as a bulk action.

Mass Email purchasers

It’s sometimes necessary to send an email to everybody who’s purchased a ticket for a particular event. Maybe it’s because there’s a last minute venue change, a cancellation, or a time change – whatever the reason, it’s valuable to be able to send a quick message to everybody coming to an event.

Send Mass Email form

For the most reliable delivery, you should generally use a mailing service like MailChimp or My Emma, but My Tickets will do the job for reasonable numbers of purchasers.

The interface for mass emailing purchasers can be found on the Reports screen in your WordPress dashboard. By default, the message will be sent in HTML format, so you can use HTML in your message.

My Tickets doesn’t provide a direct mechanism to add a header or footer to your message, but it does provide a filter (mt_modify_email_body) that you can use to mass modify all email messages sent by My Tickets. This filter is applied to all email messages sent in any context by My Tickets, so you should take that into consideration when you write filters for these messages. The filter does receive one argument other than the message body, which is a variable indicating whether the message is sent to an admin or a purchaser.

Reporting

My Tickets offers a variety of basic reports. You can generate reports of sales by date, retrieving all sales occurring between the two selected dates or reports of sales by event, retrieving all sales on that event.

Forms to select available reports.

Additionally, you can generate a list of tickets sold for an event. This is different from the list of purchases, in that it will list all of the ticket IDs that are valid for a given event, with the name of the purchaser, purchase ID, and ticket price. In the HTML view, it will provide a link to edit the associated purchase record, as well.

By default, when you enter the reporting page, it’ll show you a list of all sales within the last 7 days. If you’re running a high volume ticketing site, where this is too long of a list for comfort, you can use the filter ‘mt_default_report_start_date’ to pass a custom string formatted date argument and change the amount of data shown.

You can either view reports as HTML on your screen or export them as CSV formatted files. The two reports are fundamentally identical, except that the CSV formatted export splits the purchaser’s name into separate first and last name fields, for easier sorting.

The payment report includes first name, last name, ticket type purchased (e.g., Adult, Child, etc.), the number of tickets purchased, the price per ticket, the total amount paid for those tickets, the current payment status, the purchase date, and the purchase time.

For any purchaser who purchased more than one type of ticket – for example, a purchaser who bought tickets for two adults and one child, their name will appear on the list twice, once for each type of ticket purchased.

Editing payments

All payments can be edited after purchase. Not all fields are editable; you can’t change the tickets purchased, total cost, or transaction data, although you can add internal notes if you need to have a record of some issue handled in the purchase. Internal notes are never used on the front-end by My Tickets, and shouldn’t ever be displayed by any custom add-ons you use.

The most common reason for editing payments may be in handling Pending payments where payment has been received; if you’re tracking specific transaction IDs such as check numbers (If you’re tracking credit card numbers, you should stop immediately – this is a major security problem!), you’ll need to edit each payment individually, but if all you really need to do is mark a bunch of pending posts as completed, you can bulk edit payments to adjust this.

bulk-edit

If a user doesn’t receive their email notification, you can re-send it by checking the box labeled “Re-send Email Notification”.

Additionally, you can send specific purchasers a personal email from their payments page. Some venues will probably rarely need this, but for events that need to verify information with the purchaser, this can be very useful.

editing-payment

If you need to mass email all the purchasers of tickets for a particular event (for example, if the event had to be cancelled or delayed), you can do the from the Reports screen.