Extending [event_embed] with custom parameters

The [event_embed] shortcode already understands a host of different parameters, but even so it can be useful at times to extend it with new parameters to cover special cases. In this short tutorial we look at the process for doing just that, based on a request by @tballiance to be able to include events that have been hidden from event listings.


Events can be hidden from event listings? Yes they can! In the event editor, the event options meta box provides a couple of options:

Screenshot of the event options meta box

The result of this is that they will disappear from the main events listings. Consequently, they are also absent from straightforward usages[1] of the [event_embed] shortcode.

The proposal

While we might sometimes want to force the inclusion of these hidden events, we probably don’t always want to do this. The best way forward, then, is to add a new shortcode parameter to make this optional.

Here’s what I’m envisioning – a new hidden parameter that can be used as follows:

[event_embed hidden="include"]

The solution

There are essentially two parts to the solution:

  • We need to hook into Event Rocket in order to listen out for and set things up when the new hidden parameter is set
  • We also need to hook into The Events Calendar to modify the actual query

Luckily, both plugins ship with hooks a plenty:

  • The eventrocket_embed_event_args filter hook will allow us to interface with the [event_embed] shortcode
  • The tribe_events_pre_get_posts action hook provides a convenient way to change the actual query

The code

Here is some basic code achieving this goal. It can be added to a theme’s functions.php file, as is often done, though a custom plugin or mu-plugin file may be a tidier way to go 🙂

What are we doing here? In the extend_event_embed_hidden_events() function we check to see if hidden=”include” is set. If it is, extend_event_embed_include_hidden() rolls into action[2].

Under the hood, The Events Calendar excludes the hidden events by setting a post__not_in query var – our second function tests to see if it has been populated and then wipes it if so.

Now, the thoughtful hacker may wonder: what if post__not_in was already set, independently of anything to do with hiding upcoming events? This is indeed a risk in a few (probably uncommon) special cases but it is certainly possible to introduce more logic to handle this sort of scenario (though it goes beyond the scope of this post to cover that).

  1. A “straightforward usage” in this case means you are not specifying start or end dates and have not specified specific event IDs/slugs
  2. Note also how we instantly unhook it – this is needed to avoid interfering in subsequent event queries
  3. Originally this was going to be a 2-part tut where we continued to look at improved handling of the post__not_in parameter, however in the end I think this is something best left to the individual developer so they can tailor things to meet the actual scenario in front of them

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s