The various quirks of The Events Calendar by Modern Tribe

Let’s start this off by saying: this plugin made me curse…a lot. I don’t know who made certain decisions from a development standpoint, but there are some incredibly questionable ones that I ran into. I’m documenting them here in case others have to develop any integrations for this.

I’ll also say: I actually do really like the plugin and believe it’s incredibly useful as a front-end calendar display. It does what it says out of the box, and most people won’t run into the issues I did because they aren’t WP plugin developers.

One of my clients threw a pretty simple task at me this week: import events from an API (referred to as API throughout this post) and bring them into Modern Tribe’s “The Events Calendar” plugin. The API is dead-simple, so the biggest part was how to actually save things as part of the calendar ecosystem.

Let’s start with tribe_create_event($args). This function should be treated like wp_insert_post but with a bunch of extra meta for events. This means you need to pass things like post_title, post_status, etc.
The following formats worked for me for the following calendar meta values:
"EventStartDate" => date('Y-m-d', $start),
"EventStartHour" => date('H', $start),
"EventStartMinute" => date('i', $start),
The Start values above work for end values, too. Their docs don’t actually specify a format for dates, so there you go.

Here is quirk number one: EventHideFromUpcoming is listed as a bool in the docs, but if you set it to false, none of the events that you create will show up on the calendar display.

Why is that? When calendar events are queried, they aren’t looking for EventHideFromUpcoming to be true; they are looking for the post meta key to not exist at all. In my not-so-humble opinion, this would indicate that the docs are incorrect; if you aren’t checking for a boolean value, you can’t say it’s a boolean. The way to get around this is to not pass EventHideFromUpcoming in the $args at all.

That’s annoying, but simple enough to work around.

The API has IDs for events, so I wanted to make sure to store those as part of the post meta so I could query them later and see if an event exists already.

Here is quirk number two: any query for the tribe_events post type is hijacked by the plugin to override start_date values and add a meta_query that ensured I wouldn’t find events from before today’s date. While I will admit that this isn’t exactly a problem if I’m only importing future events, this will be used by front-end users who may want to import any and all events they have.

The solution here is annoying:

// Create a function to modify the event query since we have to steal it back from the TEC plugin
$fix_event_query = function ($query) use ($event) {
	// Set the meta_query to what it *should* be, not what it would be forcefully changed to
	$query->set('meta_query', array(
		array(
			'key' => 'my_id_meta_key',
			'value' => $event->id
		)
	));
	// I decided to use Jan 1 1970, but you can use whatever date you want to go back to
	$query->set('start_date', date('Y-m-d', strtotime('1970-01-01')));
};
// Hook our function in *after* the TEC query to bring it back to what it should be
add_action( 'pre_get_posts', $fix_event_query, 99 );
$event_args = array(
	'post_type' => 'tribe_events'
);
// Do the query
$event_exists_query = new WP_Query( $event_args );
// Remove the hook
remove_action( 'pre_get_posts', $fix_event_query, 99 );

I had to hook into the post query, tell it what it should do, and then do the query. It is convoluted and shouldn’t happen, but I’m sure somebody somewhere had a reason for hijacking the query.

Now I can check for existing events. Spectacular! I’m also creating venues and organizers on the fly, so I had to query for those as well and make sure to create them or grab an ID if we already have one. The API doesn’t have a unique ID for venues, so I had to check for existing venues by title.

Here’s quirk number three: the TEC plugin completely overwrites any query for venues by post_title to return all venues. I couldn’t even use the solution from quirk 2 to override this; it seemed to completely ignore any and all attempts to do so.

To solve it, I had to do something I dislike doing if I can avoid it:

$venues = $wpdb->query(
		$wpdb->prepare("SELECT ID from $wpdb->posts WHERE post_type = 'tribe_venue' AND post_title = '%s' AND post_status = 'publish'", [$venue_name])
	);

I don’t like writing SQL queries in WP because there are so many functions that obfuscate it well, but whatever. Sometimes you gotta do what you gotta do. This worked and got me the results I needed.

Interestingly, nothing seems to hijack queries for tribe_organizer, so I didn’t have to jump through any weird hoops to see if organizers exist or not.

These are currently all of the quirks I ran into developing the integration with the TEC plugin. I’ll make sure to update the post with more, if I find them.