[somatic]

I do all my own coding, so I’ll be okay 😉 just need a little pointer in the right direction in regards to where the queries are built for this particular listing, so I can hook/modify it and filter out the child events (I’m aware that I can select for those which have a post_parent value). I’ve been digging through all the source code for events calendar trying to track it down, and I’m at a loss. There’s really quite a few query loops that get fired on the primary /events/ listing page, as I’ve seen when hooking the pre_get_posts action…

So I’m still asking how to specifically target the queries that populate the List and Map views, while allowing the Month views to show all the recurring children (because it’s a helpful visualization on a calendar). Yes, I’ve found the templates in /src/views/list/, and I could override all that output and create my own from scratch — but I’d rather just tweak the query that feeds those loops — while ( have_posts() ) : the_post();

Yes, I can halt ticket sales, but that doesn’t prevent the child events from showing up in the listings past the end date, which is the problem. Honestly I find the whole idea of recurring events (a single event series with multiple, separate dates) where someone can purchase the same ticket for just the last two events in a series of five — as if they had purchased in the beginning, a little confusing. If each event is independently purchasable, it doesn’t make sense to combine them in a “recurring” series. I really think recurring series should be treated as a single entity (that simply contains multiple non-contiguous dates). Offering purchases while the series is already underway, or populating lists with identical-looking entries is pretty confusing.

[somatic]

I guess I should clarify that it is useful to see *all* the events in a series when browsing in “Month” view, but not when in List or Map view — so whatever solution for filtering out the recurring sub-events needs to be able to target those specifically.

[somatic]

Those would seem to be the appropriate steps, yes — so if you’re not getting the same results then I’m going to have to dig deeper… was simply a guess that account creation at checkout would be the cause.

I managed to code a workaround to accomplish the same goal of fetching all the events a user has registered for, not sure if I’ve got the time to troubleshoot the cause of _tribe_tickets_attendee_user_id = 0

// get this customer's orders newest > oldest
$customer_orders = get_posts( array(
	'numberposts' => -1,
	'meta_key'    => '_customer_user',
	'meta_value'  => get_current_user_id(),
	'post_type'   => wc_get_order_types( 'view-orders' ),
	'post_status' => array_keys( wc_get_order_statuses() ),
	'orderby'	  => 'date',
	'order'       => 'DESC',
	'fields'	  => 'ids'
) );

// event container
$my_events = array();

foreach ( $customer_orders as $customer_order ) {
	// lookup order
	$order = new WC_Order( $customer_order );
	// check each product in this order to see if it's an event ticket, if so, return the event's Post Object
	foreach ( $order->get_items() as $key => $lineItem ) {
		$maybe = tribe_events_get_ticket_event( $lineItem['product_id'] );
		if ( !empty( $maybe ) ) {
			$my_events[] = $maybe->ID;
		}
	}
}

return $my_events;

that tribe_events_get_ticket_event() function is handy for scanning orders for tickets, as it returns the Event the ticket is for, otherwise false.

[somatic]

I found another forum thread that appears related — I didn’t even know the shortcode [tribe-user-event-confirmations] existed!

But the shortcode is not working for me either, and I’m betting it’s because it builds its results using an SQL query that calls the same _tribe_tickets_attendee_user_id meta_key (which is set to zero)

I even used the handy code provided by Nico in that same thread, to get a handle on what the shortcode is doing, but it’s depending on that same meta_key which is useless if the customer *was not logged in when they purchased*, even if they have an account as a result of the purchase.

[somatic]

well, with the skyverge solution, I don’t need to make the tickets “downloadable” – just “virtual” , so i’m avoiding the language. But yes, you could hunt down all the various places that download language gets added to order confirmation pages, emails, etc, but I found that route not so simple…

[somatic]

So after getting really annoyed with all the additional language that woocommerce tacks on when a product is also “downloadable”, I revisited the skyverge.com code, and realized I was probably adding the filter too late. I’m using a child theme, and I needed to add the filter within the “after_setup_theme” hook in order for it to take effect. It works brilliantly, even with the clunky old paypal standard payments…

[somatic]

tried that code from skyverge. Didn’t work for me at all, even stripping out most of it and simply *always* changing status to completed (since I’m only selling tickets). Only thing that works is checking “virtual” AND “downloadable” — which has the annoying effect of including a mention of downloadable files in the order email 😛

[Author]

Posts