Month: February 2018

So I’ve ended up the administrator of a WordPress site and I’m going to have to write some custom code. This is a problem because:

1. This is the first WordPress site I’ve ever touched.
2. I’ve never programmed PHP.

But hey, I have enough experience with OO programing to fake it, right? Well maybe I do.

To start, let me explain that we have two plugins: WooCommerce, the most popular WordPress plugin for online commerce, and The Events Calendar, a plugin that gives you nice calendars in WordPress. The glue between the two is Event Tickets Plus, which allows you to sell tickets to your Calendar events and process them through WooCommerce to collect the money. The problem is that the integration isn’t very thorough.

When you create a type of ticket for an event, it creates an equivalent product in WooCommerce that is closely tied to the ticket. The name you give to the ticket, say, “one balcony seat”, becomes the name of a hidden product in WooCommerce. The name and price are copied over from the ticket to the product, but that’s about it. So far as Event Tickets Plus is concerned, if you want any additional data to be associated with the product then you should go find it in WooCommerce and edit it there.

This makes for some awkwardness on the WooCommerce end. For starters, when your customers look in their basket or on their receipt, all they will see is “one balcony seat” with no further details. If they put multiple tickets with the same name in their basket, then they will have no idea which is which. When you as the administrator look at the back end, all you will see is “one balcony seat” until you click through some links to find the associated event. If all your events have “one balcony seat” as a ticket option and you have, say, one thousand events, then you might have to do a lot of clicking to find the right one.

This issue is a problem for enough users that there are two code snippets in the knowledge base for Event Tickets Plus that are aimed at partially resolving it. The first is an attempt to add the event name to the product while viewing it in the shopping basket. This is a step in the right direction, but we often have repeat events so it would be nice to have the event date as well. So I started by adding that to the snippet.

add_filter( 'woocommerce_cart_item_name', 'woocommerce_cart_item_name_event_title', 10, 3 );function woocommerce_cart_item_name_event_title( $title, $values, $cart_item_key ) {        $ticket_meta = get_post_meta( $values['product_id'] );        $event_id = absint( $ticket_meta['_tribe_wooticket_for_event'][0] );        if ( $event_id ) {                $title = sprintf( '%s for <a href="%s" target="_blank"><strong>%s</strong></a> on %s', $title, get_permalink( $event_id ), get_the_title( $event_id ), tribe_get_start_date( $event_id ) );        }        return $title;}

The other snippet that is available adds the date to the ticket information in the emailed receipt. We may have multiple events on the same day. So, I modified it to include the title of the event as well.
​

function tribe_add_date_to_order_title( $title, $item ) {    $event = tribe_events_get_ticket_event( $item['product_id'] );    if ( $event !== false ) {        $title .= ' for ' . get_the_title( $event) . ' on ' . tribe_get_start_date( $event );    }    return $title;} add_filter( 'woocommerce_order_item_name', 'tribe_add_date_to_order_title', 100, 2 );

This is a good start, but it doesn’t solve my backend problem. In the admin portion of WooCommerce I still have a long list of products with identical titles. So the first thought I had was to scour the code for where the product is created from the ticket type and have it write all of the information right into the product title. That would eliminate the need for the above two snippets.

To do this, I have to find if and where the authors of Event Tickets Plus put a hook to which I can attach my code. In the snippets above, you can see that the new functions are attached to the code using the “add_filter” function and a string associated with the base code. Those strings, ‘woocommerce_cart_item_name’ and ‘woocommerce_order_item_name’ were written into the base code by the authors of WooCommerce so others could modify the behavior of WooCommerce without editing the code itself. This reduces the chance that an update to WooCommerce will overwrite the changes or break them. I have to say that both WordPress and the writers of its plugins have done a great job of making their code extensible. Hooks for additional code are just about everywhere.

So I don’t have to search too long before I find the appropriate tag at the end of the ticket-creation code. I add a little bit of code to change the name of the WooCommerce product that is created to back the ticket so that it includes the name of the event as well as the ticket type and… unexpected behavior ensues. In particular, changing the WooCommerce product’s name changes the Event Tickets Plus ticket name to match. Either there is code elsewhere that keeps the two in sync or, quite possibly, the ticket and the event are the same object (that is, the same ‘post’ in the database) and there is no way to disentangle them enough to have different names.

Since the name collision problem only annoys the administrator of the site, and not the end user, I think this is all the effort I’m going to put into this. If you happen to know how any of this works, by all means comment so, but I may not put much more effort into this unless someone starts paying me. 😉